วันนี้ native public output ของ e-invoice รองรับมาตรฐานใด

public native output คือ Factur-X และ ZUGFeRD PDF/A-3b พร้อม EN 16931 CII XML ที่ฝังอยู่ ตรวจ /api/v1/e-invoice/capabilities สำหรับ contract ปัจจุบัน

gPdf สร้าง EN 16931 XML ให้หรือไม่

ไม่ ระบบของคุณส่ง XML content มาให้ gPdf package ลงใน PDF/A-3b e-invoice wrapper พร้อม attachment metadata ที่จำเป็น

ส่ง settings.e_invoice ไปที่ JSON Render ได้หรือไม่

ไม่ได้ e-invoice packaging อยู่ที่ POST /api/v1/e-invoice/render public docs ระบุว่า settings.e_invoice เป็น route-specific

ควร validate output อย่างไร

ใช้ gPdf validator หรือ reference-engine workflow ของคุณเองเพื่อตรวจทั้ง layer PDF/A และ layer XML ของ e-invoice ที่ฝังอยู่

Compliance และการเก็บถาวร

E-Invoice API สำหรับ Factur-X และ ZUGFeRD PDF/A-3b

สร้าง e-invoice แบบ Factur-X และ ZUGFeRD PDF/A-3b พร้อม EN 16931 CII XML ที่ฝังอยู่ ผ่าน public gPdf e-invoice endpoint

PRIMARY API E-Invoice Render

ENDPOINT /api/v1/e-invoice/render

SYSTEMS ERP / finance backend / accounts receivable system / compliance workflow

ลองใน Playground อ่านเอกสาร

งานที่ต้องทำให้เสร็จ

บรรจุ invoice PDF ที่มนุษย์อ่านได้และ EN 16931 CII XML ที่ caller จัดเตรียม ให้เป็น e-invoice แบบ Factur-X หรือ ZUGFeRD PDF/A-3b ซึ่งสามารถตรวจด้วย external PDF/A และ e-invoice reference engines ได้

ควรใช้ API นี้เมื่อใด

คุณต้องการ output แบบ Factur-X หรือ ZUGFeRD ไม่ใช่แค่ invoice PDF ทั่วไป
ระบบของคุณจัดเตรียม EN 16931 CII XML ที่ถูกต้องสำหรับ invoice ได้
คุณต้องการ PDF/A-3b packaging, attachment metadata และการ wiring XMP สำหรับ e-invoice
คุณต้องการให้ capabilities endpoint ยืนยัน standards และ profiles ที่รองรับ

สิ่งที่ไม่ได้ทดแทน

คุณต้องการเพียง ordinary customer invoice PDF ให้ใช้ JSON Render หรือ Template Render
คุณต้องการ output native XRechnung, FatturaPA, KSeF, Peppol, ZATCA, NF-e หรือ GST ก่อนที่ OpenAPI จะระบุไว้
คุณคาดหวังให้ gPdf สร้าง invoice XML ที่ถูกต้องตามกฎหมายจาก business data ที่ไม่ครบ

ควรเรียก endpoint ใด

PRIMARY

/api/v1/e-invoice/render

E-Invoice Render คือ path หลักสำหรับเวิร์กโฟลว์นี้.

SECONDARY 1

/api/v1/e-invoice/capabilities

ใช้เมื่อเวิร์กโฟลว์ต้องการ API path ที่เกี่ยวข้อง สัญญาเทมเพลต หรือการค้นหา capability.

Minimal request

POST /api/v1/e-invoice/render - request 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 packaging ผ่าน POST /api/v1/e-invoice/render
การฝัง EN 16931 CII XML ที่ caller จัดเตรียมเป็น associated file
metadata ของ PDF/A-3b wrapper และการ wiring XMP สำหรับมาตรฐาน e-invoice
การค้นหา capabilities ผ่าน GET /api/v1/e-invoice/capabilities

ระบบของคุณรับผิดชอบอะไร

ความหมายทางธุรกิจของ invoice, กฎภาษี, identifier ของ buyer/seller และความถูกต้องของ EN 16931 XML
การเลือกว่า Factur-X หรือ ZUGFeRD เหมาะกับ workflow ของผู้รับหรือไม่
การทดสอบ acceptance ภายนอกกับ receiver, AP automation system หรือ local compliance process

Production checklist

เรียก /api/v1/e-invoice/capabilities ก่อน assume standard หรือ profile
ตรวจสอบ EN 16931 CII XML ก่อนฝัง
นำ output ผ่าน /validator/ หรือ reference-engine pipeline ของคุณเอง
แยก ordinary invoice PDF generation ออกจาก legal e-invoice packaging ในโค้ด
บันทึก request IDs, standard, profile, XML source version และ validation evidence

ขอบเขตของ claim

native public e-invoice output คือ Factur-X / ZUGFeRD พร้อม EN 16931 CII XML
ชื่อ e-invoice ระดับประเทศอื่น ๆ เป็น market context เว้นแต่ OpenAPI จะระบุว่าเป็น supported standards
gPdf package XML ที่ caller จัดเตรียม ระบบของคุณยังรับผิดชอบความถูกต้องเชิงธุรกิจของ XML

endpoint เดียวสำหรับแพ็กเกจ e-invoice

e-invoice endpoint มีอยู่เพราะ workflow นี้ไม่ใช่แค่ “เรนเดอร์ invoice PDF” เท่านั้น แต่ต้องสร้าง PDF/A-3b wrapper พร้อม associated file metadata และ XMP เฉพาะมาตรฐานให้ถูกต้อง ขณะเดียวกันก็ฝัง EN 16931 CII XML ที่ caller จัดเตรียม

เรียก POST /api/v1/e-invoice/render เมื่อ output ที่ต้องการคือ Factur-X หรือ ZUGFeRD ใช้ GET /api/v1/e-invoice/capabilities เมื่อ integration ของคุณต้องยืนยัน standards, profiles, document types และ XML formats ที่รองรับก่อนส่งงาน

สิ่งที่ยังอยู่นอก gPdf

ความหมายของ XML ยังเป็นความรับผิดชอบของคุณ gPdf ไม่สามารถรู้ได้ว่า invoice number ถูกต้องตามกฎหมายหรือไม่ ยอดภาษีถูกต้องหรือไม่ buyer identifier ตรงกับ trading partner หรือไม่ หรือ receiver เฉพาะรายจะยอมรับ business process variant นั้นหรือไม่ สร้างและ validate XML upstream แล้วใช้ gPdf สำหรับ PDF/A-3b packaging และ rendering

อย่านำคำใน roadmap มาอ้างเป็น native support

การพูดถึง XRechnung, FatturaPA, KSeF, Peppol, ZATCA, NF-e หรือ GST ในฐานะ market context ทำได้ แต่อย่านำชื่อเหล่านั้นไปนำเสนอว่าเป็น native public renderer output เว้นแต่ OpenAPI capabilities contract จะระบุไว้

FAQ

วันนี้ native public output ของ e-invoice รองรับมาตรฐานใด: public native output คือ Factur-X และ ZUGFeRD PDF/A-3b พร้อม EN 16931 CII XML ที่ฝังอยู่ ตรวจ /api/v1/e-invoice/capabilities สำหรับ contract ปัจจุบัน
gPdf สร้าง EN 16931 XML ให้หรือไม่: ไม่ ระบบของคุณส่ง XML content มาให้ gPdf package ลงใน PDF/A-3b e-invoice wrapper พร้อม attachment metadata ที่จำเป็น
ส่ง settings.e_invoice ไปที่ JSON Render ได้หรือไม่: ไม่ได้ e-invoice packaging อยู่ที่ POST /api/v1/e-invoice/render public docs ระบุว่า settings.e_invoice เป็น route-specific
ควร validate output อย่างไร: ใช้ gPdf validator หรือ reference-engine workflow ของคุณเองเพื่อตรวจทั้ง layer PDF/A และ layer XML ของ e-invoice ที่ฝังอยู่