Standard e-invoice mana yang menjadi output native publik saat ini?

Output native publik adalah PDF/A-3b Factur-X dan ZUGFeRD dengan EN 16931 CII XML tertanam. Periksa /api/v1/e-invoice/capabilities untuk kontrak saat ini.

Apakah gPdf membuat EN 16931 XML untuk saya?

Tidak. Sistem Anda menyediakan konten XML. gPdf memaketkannya ke wrapper e-invoice PDF/A-3b dengan metadata attachment yang diperlukan.

Bisakah saya mengirim settings.e_invoice ke JSON Render?

Tidak. Packaging e-invoice berada di POST /api/v1/e-invoice/render. Docs publik menyatakan settings.e_invoice bersifat route-specific.

Bagaimana saya sebaiknya memvalidasi output?

Gunakan validator gPdf atau workflow reference-engine Anda sendiri untuk memeriksa lapisan PDF/A dan lapisan XML e-invoice tertanam.

Kepatuhan dan arsip

E-Invoice API untuk Factur-X dan ZUGFeRD PDF/A-3b

Generate e-invoice PDF/A-3b Factur-X dan ZUGFeRD dengan EN 16931 CII XML tertanam melalui endpoint e-invoice publik gPdf.

API UTAMA E-Invoice Render

ENDPOINT /api/v1/e-invoice/render

SISTEM ERP / backend finance / sistem accounts receivable / workflow kepatuhan

Coba di Playground Baca dokumentasi

Pekerjaan yang diselesaikan

Memaketkan PDF invoice yang dapat dibaca manusia dan EN 16931 CII XML yang disediakan caller menjadi e-invoice PDF/A-3b Factur-X atau ZUGFeRD yang dapat divalidasi oleh engine referensi PDF/A dan e-invoice eksternal.

Kapan memakai API ini

Anda membutuhkan output Factur-X atau ZUGFeRD, bukan hanya PDF invoice biasa.
Sistem Anda dapat menyediakan EN 16931 CII XML yang benar untuk invoice.
Anda membutuhkan packaging PDF/A-3b, metadata attachment, dan wiring XMP e-invoice.
Anda ingin endpoint capabilities publik mengonfirmasi standar dan profil yang didukung.

Apa yang tidak digantikan

Anda hanya membutuhkan PDF invoice pelanggan biasa. Gunakan JSON Render atau Template Render.
Anda membutuhkan output native XRechnung, FatturaPA, KSeF, Peppol, ZATCA, NF-e, atau GST sebelum OpenAPI mencantumkannya.
Anda mengharapkan gPdf membuat XML invoice yang benar secara legal dari data bisnis yang belum lengkap.

Endpoint yang dipanggil

UTAMA

/api/v1/e-invoice/render

E-Invoice Render adalah jalur default untuk workflow ini.

SEKUNDER 1

/api/v1/e-invoice/capabilities

Gunakan saat workflow butuh jalur API terkait, kontrak template, atau capability lookup.

Request minimal

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

{
  "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" }
        }
      ]
    }
  ]
}

Yang ditangani gPdf

Packaging PDF/A-3b Factur-X atau ZUGFeRD melalui POST /api/v1/e-invoice/render.
Menanamkan EN 16931 CII XML yang disediakan caller sebagai associated file.
Metadata wrapper PDF/A-3b dan wiring XMP e-invoice spesifik standar.
Discovery capabilities melalui GET /api/v1/e-invoice/capabilities.

Yang dikelola sistem Anda

Semantik bisnis invoice, aturan pajak, identifier buyer/seller, dan kebenaran XML EN 16931.
Memilih apakah Factur-X atau ZUGFeRD sesuai untuk workflow penerima.
Acceptance testing eksternal dengan penerima, sistem AP automation, atau proses kepatuhan setempat.

Checklist produksi

Panggil /api/v1/e-invoice/capabilities sebelum mengasumsikan standar atau profil.
Validasi EN 16931 CII XML sebelum menanamkannya.
Jalankan output melalui /validator/ atau pipeline reference-engine Anda sendiri.
Pisahkan pembuatan PDF invoice biasa dan packaging e-invoice legal di kode.
Log request ID, standar, profil, versi source XML, dan bukti validasi.

Batas klaim

Output e-invoice native publik adalah Factur-X / ZUGFeRD dengan EN 16931 CII XML.
Nama e-invoice nasional lain adalah konteks pasar kecuali OpenAPI mencantumkannya sebagai standar yang didukung.
gPdf memaketkan XML yang disediakan caller; sistem Anda tetap bertanggung jawab atas kebenaran bisnis XML.

Satu endpoint untuk paket e-invoice

Endpoint e-invoice ada karena workflow ini bukan sekadar “render PDF invoice”. Endpoint harus menghasilkan wrapper PDF/A-3b dengan metadata associated file yang benar dan XMP spesifik standar, sambil menanamkan EN 16931 CII XML yang disediakan caller.

Panggil POST /api/v1/e-invoice/render ketika output yang dibutuhkan adalah Factur-X atau ZUGFeRD. Gunakan GET /api/v1/e-invoice/capabilities saat integrasi Anda ingin mengonfirmasi standar, profil, jenis dokumen, dan format XML yang didukung sebelum mengirim pekerjaan.

Apa yang tetap berada di luar gPdf

Semantik XML tetap menjadi tanggung jawab Anda. gPdf tidak dapat mengetahui apakah nomor invoice legal, nilai pajak benar, identifier buyer cocok dengan trading partner, atau penerima tertentu akan menerima varian proses bisnis. Generate dan validasi XML upstream, lalu gunakan gPdf untuk packaging PDF/A-3b dan rendering.

Jaga istilah roadmap di luar klaim dukungan native

Membahas XRechnung, FatturaPA, KSeF, Peppol, ZATCA, NF-e, atau GST sebagai konteks pasar itu valid. Jangan menyajikan nama tersebut sebagai output native renderer publik kecuali kontrak capabilities OpenAPI mencantumkannya.

FAQ

Standard e-invoice mana yang menjadi output native publik saat ini?: Output native publik adalah PDF/A-3b Factur-X dan ZUGFeRD dengan EN 16931 CII XML tertanam. Periksa /api/v1/e-invoice/capabilities untuk kontrak saat ini.
Apakah gPdf membuat EN 16931 XML untuk saya?: Tidak. Sistem Anda menyediakan konten XML. gPdf memaketkannya ke wrapper e-invoice PDF/A-3b dengan metadata attachment yang diperlukan.
Bisakah saya mengirim settings.e_invoice ke JSON Render?: Tidak. Packaging e-invoice berada di POST /api/v1/e-invoice/render. Docs publik menyatakan settings.e_invoice bersifat route-specific.
Bagaimana saya sebaiknya memvalidasi output?: Gunakan validator gPdf atau workflow reference-engine Anda sendiri untuk memeriksa lapisan PDF/A dan lapisan XML e-invoice tertanam.