ما معايير الفواتير الإلكترونية التي تنتجها الواجهة العامة أصليًا اليوم؟

المخرجات الأصلية العامة هي Factur-X و ZUGFeRD PDF/A-3b مع XML EN 16931 CII مضمّن. افحص /api/v1/e-invoice/capabilities لمعرفة العقد الحالي.

هل ينشئ gPdf XML EN 16931 نيابة عني؟

لا. يقدّم نظامك محتوى XML. يغلفه gPdf داخل غلاف الفاتورة الإلكترونية PDF/A-3b مع بيانات المرفق المطلوبة.

هل يمكنني إرسال settings.e_invoice إلى JSON Render؟

لا. تغليف الفاتورة الإلكترونية ينتمي إلى POST /api/v1/e-invoice/render. توضّح الوثائق العامة أن settings.e_invoice خاص بالمسار.

كيف يجب أن أتحقق من المخرجات؟

استخدم validator في gPdf أو سير محركاتك المرجعية للتحقق من طبقة PDF/A وطبقة XML الفاتورة الإلكترونية المضمّنة.

الامتثال والأرشفة

API الفواتير الإلكترونية لـ Factur-X و ZUGFeRD PDF/A-3b

أنشئ فواتير إلكترونية Factur-X و ZUGFeRD بصيغة PDF/A-3b مع XML EN 16931 CII مضمّن عبر مسار API العام للفواتير الإلكترونية في gPdf.

API الرئيسي E-Invoice Render

مسار API /api/v1/e-invoice/render

الأنظمة ERP / خادم خلفي مالي / نظام حسابات مدينة / سير عمل امتثال

جرّب في Playground اقرأ الوثائق

المهمة المطلوبة

تغليف PDF فاتورة قابل للقراءة مع XML EN 16931 CII يقدمه المتصل داخل فاتورة إلكترونية Factur-X أو ZUGFeRD بصيغة PDF/A-3b يمكن التحقق منها عبر محركات مرجعية خارجية لـ PDF/A والفواتير الإلكترونية.

متى تستخدم هذه API

تحتاج إلى مخرجات Factur-X أو ZUGFeRD، وليس مجرد PDF فاتورة عادي.
يستطيع نظامك تقديم XML EN 16931 CII صحيح للفاتورة.
تحتاج إلى تغليف PDF/A-3b وبيانات مرفقات وتعريفات XMP خاصة بالفاتورة الإلكترونية.
تريد أن يؤكد مسار القدرات العام المعايير والملفات المدعومة.

ما الذي لا تستبدله

تحتاج فقط إلى PDF فاتورة عميل عادي. استخدم JSON Render أو Template Render.
تحتاج إلى مخرجات أصلية لـ XRechnung أو FatturaPA أو KSeF أو Peppol أو ZATCA أو NF-e أو GST قبل أن يدرجها OpenAPI.
تتوقع من gPdf إنشاء XML فاتورة صحيح قانونيًا من بيانات أعمال ناقصة.

أي مسار API يجب استدعاؤه

الرئيسي

/api/v1/e-invoice/render

E-Invoice Render هو المسار الافتراضي لسير العمل هذا.

ثانوي 1

/api/v1/e-invoice/capabilities

استخدمه عندما يحتاج سير العمل إلى مسار API مرتبط، أو عقد قالب، أو استعلام capabilities.

طلب مختصر

POST /api/v1/e-invoice/render - طلب Factur-X PDF/A-3b بسيط.

{
  "settings": {
    "profile": "pdfa-3b",
    "e_invoice": {
      "standard": "factur_x",
      "profile": "en16931",
      "document_type": "invoice",
      "xml": {
        "format": "cii",
        "encoding": "utf8",
        "content": "<?xml version=\"1.0\" encoding=\"UTF-8\"?><rsm:CrossIndustryInvoice>...</rsm:CrossIndustryInvoice>"
      }
    }
  },
  "pages": [
    {
      "size": "a4",
      "elements": [
        {
          "type": "text",
          "x": 20,
          "y": 24,
          "content": "Invoice INV-1007",
          "style": { "font_size": 16, "font_family": "NotoSans-Regular" }
        }
      ]
    }
  ]
}

ما يتولاه gPdf

تغليف Factur-X أو ZUGFeRD PDF/A-3b عبر POST /api/v1/e-invoice/render.
تضمين XML EN 16931 CII الذي يقدمه المتصل كملف مرتبط.
بيانات غلاف PDF/A-3b وتعريفات XMP الخاصة بالمعيار.
اكتشاف القدرات عبر GET /api/v1/e-invoice/capabilities.

ما يبقى ضمن مسؤولية نظامك

معنى الفاتورة التجاري، وقواعد الضرائب، ومعرّفات البائع والمشتري، وصحة XML EN 16931.
اختيار ما إذا كان Factur-X أو ZUGFeRD مناسبًا لسير عمل المستلم.
اختبار القبول الخارجي مع المستلم أو نظام أتمتة الحسابات الدائنة أو مسار الامتثال المحلي لديك.

قائمة فحص الإنتاج

استدع /api/v1/e-invoice/capabilities قبل افتراض أي معيار أو ملف.
تحقق من XML EN 16931 CII قبل تضمينه.
مرر المخرجات عبر /validator/ أو عبر خط محركاتك المرجعية.
افصل في الكود بين إنشاء PDF الفاتورة العادي والتغليف القانوني للفاتورة الإلكترونية.
سجّل معرّفات الطلب، والمعيار، والملف، وإصدار مصدر XML، وأدلة التحقق.

حدود الادعاءات

المخرجات الأصلية العامة للفواتير الإلكترونية هي Factur-X / ZUGFeRD مع XML EN 16931 CII.
أسماء الفواتير الإلكترونية الوطنية الأخرى هي سياق سوقي ما لم يدرجها OpenAPI كمعايير مدعومة.
يغلف gPdf XML الذي يقدمه المتصل؛ ويبقى نظامك مسؤولًا عن صحة XML من حيث الأعمال.

Endpoint واحد لحزمة الفاتورة الإلكترونية

يوجد مسار API الفاتورة الإلكترونية لأن هذا السير ليس مجرد “عرض PDF فاتورة”. يجب أن ينتج غلاف PDF/A-3b ببيانات الملف المرتبط الصحيحة وXMP الخاص بالمعيار، مع تضمين XML EN 16931 CII الذي يقدمه المتصل.

استدع POST /api/v1/e-invoice/render عندما تكون المخرجات المطلوبة Factur-X أو ZUGFeRD. واستخدم GET /api/v1/e-invoice/capabilities عندما يريد تكاملك تأكيد المعايير والملفات وأنواع المستندات وصيغ XML المدعومة قبل إرسال العمل.

ما يبقى خارج gPdf

تبقى دلالات XML مسؤوليتك. لا يستطيع gPdf معرفة ما إذا كان رقم الفاتورة قانونيًا، أو مبلغ الضريبة صحيحًا، أو معرّف المشتري يطابق شريك التداول، أو ما إذا كان مستلم معين سيقبل متغيرًا محددًا من سير العمل التجاري. أنشئ XML وتحقق منه في المنبع، ثم استخدم gPdf لتغليف PDF/A-3b وعرضه.

أبق مصطلحات خارطة الطريق خارج ادعاءات الدعم الأصلي

يمكن مناقشة XRechnung أو FatturaPA أو KSeF أو Peppol أو ZATCA أو NF-e أو GST كسياق سوقي. لا تعرض هذه الأسماء على أنها مخرجات أصلية للمحرك العام إلا إذا كان عقد قدرات OpenAPI يدرجها.

الأسئلة الشائعة

ما معايير الفواتير الإلكترونية التي تنتجها الواجهة العامة أصليًا اليوم؟: المخرجات الأصلية العامة هي Factur-X و ZUGFeRD PDF/A-3b مع XML EN 16931 CII مضمّن. افحص /api/v1/e-invoice/capabilities لمعرفة العقد الحالي.
هل ينشئ gPdf XML EN 16931 نيابة عني؟: لا. يقدّم نظامك محتوى XML. يغلفه gPdf داخل غلاف الفاتورة الإلكترونية PDF/A-3b مع بيانات المرفق المطلوبة.
هل يمكنني إرسال settings.e_invoice إلى JSON Render؟: لا. تغليف الفاتورة الإلكترونية ينتمي إلى POST /api/v1/e-invoice/render. توضّح الوثائق العامة أن settings.e_invoice خاص بالمسار.
كيف يجب أن أتحقق من المخرجات؟: استخدم validator في gPdf أو سير محركاتك المرجعية للتحقق من طبقة PDF/A وطبقة XML الفاتورة الإلكترونية المضمّنة.