Uyumluluk ve arşivleme

Factur-X ve ZUGFeRD PDF/A-3b için E-Invoice API'si

Public gPdf e-invoice endpoint üzerinden gömülü EN 16931 CII XML içeren Factur-X ve ZUGFeRD PDF/A-3b e-invoice dosyaları oluşturun.

ANA API E-Invoice Render
ENDPOINT /api/v1/e-invoice/render
SİSTEMLER ERP / finans backend'i / alacak hesapları sistemi / uyumluluk iş akışı
Çözülecek iş

İnsan tarafından okunabilir bir fatura PDF'ini ve çağıran sistemin sağladığı EN 16931 CII XML'i, dış PDF/A ve e-invoice referans motorlarıyla doğrulanabilecek Factur-X veya ZUGFeRD PDF/A-3b e-fatura paketine dönüştürmek.

Bu API ne zaman kullanılır

  • Yalnızca sıradan bir fatura PDF'i değil, Factur-X veya ZUGFeRD çıktısına ihtiyacınız var.
  • Sisteminiz fatura için doğru EN 16931 CII XML sağlayabiliyor.
  • PDF/A-3b paketleme, attachment metadata ve e-invoice XMP bağlaması gerekiyor.
  • Desteklenen standartları ve profilleri doğrulamak için public capabilities endpoint'i kullanmak istiyorsunuz.

Neyin yerine geçmez

  • Yalnızca sıradan müşteri fatura PDF'ine ihtiyacınız var. JSON Render veya Template Render kullanın.
  • OpenAPI listelemeden önce native XRechnung, FatturaPA, KSeF, Peppol, ZATCA, NF-e veya GST çıktısı bekliyorsunuz.
  • gPdf'in eksik iş verisinden hukuken doğru fatura XML'i oluşturmasını bekliyorsunuz.

Hangi endpoint çağrılır

ANA

/api/v1/e-invoice/render

E-Invoice Render bu iş akışı için varsayılan yoldur.

İKİNCİL 1

/api/v1/e-invoice/capabilities

İş akışı ilgili API yoluna, template sözleşmesine veya capability sorgusuna ihtiyaç duyduğunda kullanın.

Minimum request

POST /api/v1/e-invoice/render - minimal Factur-X PDF/A-3b isteği.

{
  "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 neyi üstlenir

  • POST /api/v1/e-invoice/render üzerinden Factur-X veya ZUGFeRD PDF/A-3b paketleme.
  • Çağıran sistemin sağladığı EN 16931 CII XML'in ilişkili dosya olarak gömülmesi.
  • PDF/A-3b sarmalayıcı metadata ve standarda özel e-invoice XMP bağlaması.
  • GET /api/v1/e-invoice/capabilities üzerinden yetenek keşfi.

Sisteminiz neyi yönetir

  • Fatura iş semantiği, vergi kuralları, alıcı/satıcı tanımlayıcıları ve EN 16931 XML doğruluğu.
  • Factur-X veya ZUGFeRD'in alıcı iş akışı için uygun olup olmadığını seçmek.
  • Alıcı, AP automation sistemi veya yerel uyumluluk süreci ile dış kabul testi.

Production kontrol listesi

  1. Bir standart veya profil varsaymadan önce /api/v1/e-invoice/capabilities çağırın.
  2. EN 16931 CII XML'i gömmeden önce doğrulayın.
  3. Çıktıyı /validator/ veya kendi referans motoru hattınızdan geçirin.
  4. Sıradan fatura PDF'i oluşturma ile legal e-invoice paketleme kodunu ayrı tutun.
  5. Request ID, standart, profil, XML kaynak versiyonu ve doğrulama kanıtı kaydedin.

İddia sınırları

  • Native public e-invoice çıktısı EN 16931 CII XML ile Factur-X / ZUGFeRD'dir.
  • OpenAPI desteklenen standart olarak listelemedikçe diğer ulusal e-invoice adları yalnızca pazar bağlamıdır.
  • gPdf çağıran sistemin sağladığı XML'i paketler; XML iş doğruluğu sizin sisteminizde kalır.

E-fatura paketi için tek endpoint

E-invoice endpoint vardır çünkü bu iş akışı yalnızca “fatura PDF’i render et” değildir. Çağıran sistemin sağladığı EN 16931 CII XML’i gömerken doğru ilişkili dosya metadata’sı ve standarda özel XMP ile PDF/A-3b sarmalayıcı üretmesi gerekir.

Gerekli çıktı Factur-X veya ZUGFeRD olduğunda POST /api/v1/e-invoice/render çağırın. Entegrasyonunuz işi göndermeden önce desteklenen standartları, profilleri, document type değerlerini ve XML formatlarını doğrulamak istiyorsa GET /api/v1/e-invoice/capabilities kullanın.

gPdf dışında kalanlar

XML semantiği sizin sorumluluğunuzda kalır. gPdf bir fatura numarasının hukuken geçerli olup olmadığını, vergi tutarının doğru olup olmadığını, alıcı tanımlayıcısının ticari taraf ile eşleşip eşleşmediğini veya belirli bir alıcının iş süreci varyantını kabul edip etmeyeceğini bilemez. XML’i önceki sistem üretip doğrulayın, ardından PDF/A-3b paketleme ve render işlemi için gPdf kullanın.

Roadmap terimlerini yerel destek iddialarından ayrı tutun

XRechnung, FatturaPA, KSeF, Peppol, ZATCA, NF-e veya GST adlarını pazar bağlamı olarak tartışmak geçerlidir. OpenAPI capabilities sözleşmesi bunları listelemedikçe bu adları native public renderer çıktısı gibi sunmayın.

SSS

Bugün native public çıktı hangi e-invoice standartlarını destekliyor?
Public native çıktı, gömülü EN 16931 CII XML içeren Factur-X ve ZUGFeRD PDF/A-3b'dir. Güncel sözleşme için /api/v1/e-invoice/capabilities kontrol edin.
gPdf EN 16931 XML'i benim için üretir mi?
Hayır. XML içeriğini sizin sisteminiz sağlar. gPdf onu gerekli attachment metadata ile PDF/A-3b e-invoice sarmalayıcıya paketler.
settings.e_invoice değerini JSON Render'a gönderebilir miyim?
Hayır. E-invoice paketleme POST /api/v1/e-invoice/render üzerindedir. Public dokümanlar settings.e_invoice alanının route-specific olduğunu belirtir.
Çıktıyı nasıl doğrulamalıyım?
Hem PDF/A katmanını hem de gömülü e-fatura XML'i katmanını kontrol etmek için gPdf validator veya kendi referans motoru iş akışınızı kullanın.