PDF/A-3b เป็น e-invoice เสมอหรือไม่

ไม่ PDF/A-3b คือ archival PDF profile ส่วน Factur-X และ ZUGFeRD e-invoices ใช้ PDF/A-3b เป็น wrapper สำหรับ EN 16931 XML ที่ฝังอยู่

endpoint ใดสร้าง PDF/A-3b

ใช้ POST /api/v1/pdf/render พร้อม settings.profile สำหรับ ordinary PDF/A-3b ใช้ POST /api/v1/e-invoice/render เมื่อ output ต้องเป็น Factur-X หรือ ZUGFeRD e-invoice

แนบ arbitrary files ผ่านหน้านี้ได้หรือไม่

อย่า assume ว่ารองรับ arbitrary attachment เว้นแต่ public API docs จะระบุ workflow นั้น หน้านี้เน้น PDF/A-3b และ e-invoice use ที่ documented

ตรวจสอบ PDF/A output อย่างไร

ใช้ /validator/ หรือ reference-engine pipeline ของคุณเอง สำหรับ e-invoices ให้ validate ทั้ง layer PDF/A และ layer XML ที่ฝังอยู่

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

PDF/A-3b API สำหรับ archival และ e-invoice workflows

สร้าง output PDF/A-3b ด้วย gPdf และแยกให้ชัดว่าเมื่อใด PDF/A-3b เป็นเพียง archival profile และเมื่อใดเป็น wrapper ของ e-invoice

PRIMARY API JSON Render

ENDPOINT /api/v1/pdf/render

SYSTEMS compliance backend / finance system / legal archive / audit workflow

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

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

สร้างเอกสาร PDF/A-3b สำหรับ archival workflows และเลือก e-invoice endpoint เมื่อ PDF/A-3b ต้องบรรจุ Factur-X หรือ ZUGFeRD EN 16931 XML ที่ฝังอยู่

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

คุณต้องการ PDF/A-3b archival profile สำหรับเอกสารที่เรนเดอร์แล้ว
คุณต้องการอธิบาย boundary ระหว่าง ordinary PDF/A และ e-invoice packaging
compliance workflow ของคุณ validate PDF ที่สร้างขึ้นด้วย veraPDF หรือ reference engine อื่น
คุณต้องการ public page เพื่อนำ search intent ของ PDF/A-3b ไปยัง endpoint ที่ถูกต้อง

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

คุณต้องการ arbitrary file-attachment workflows ที่ไม่ได้ documented ใน public API
คุณต้องการ Factur-X หรือ ZUGFeRD e-invoices ผ่าน JSON Render ให้ใช้ E-Invoice Render
คุณต้องการ validator API พื้นผิว validator สาธารณะปัจจุบันคือหน้า /validator/

ควรเรียก endpoint ใด

PRIMARY

/api/v1/pdf/render

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

SECONDARY 1

/api/v1/e-invoice/render

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

Minimal request

POST /api/v1/pdf/render - ขอ output PDF/A-3b สำหรับเอกสารที่เรนเดอร์

{
  "settings": {
    "profile": "pdfa-3b"
  },
  "pages": [
    {
      "size": "a4",
      "elements": [
        {
          "type": "text",
          "x": 20,
          "y": 24,
          "content": "Archive copy",
          "style": { "font_size": 16, "font_family": "NotoSans-Regular" }
        }
      ]
    }
  ]
}

gPdf จัดการอะไร

การเลือก PDF/A profile ผ่าน settings ของ JSON Render
PDF/A-3b e-invoice packaging เมื่อใช้ POST /api/v1/e-invoice/render
output PDF ที่เรนเดอร์ได้และเหมาะกับ external reference-engine validation
การแยกชัดเจนระหว่าง archival profile และ legal e-invoice workflow

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

retention policy และเหตุผลที่ต้องใช้ PDF/A-3b
business data, XML semantics และ external compliance acceptance criteria ใด ๆ
validation evidence, audit records และ long-term storage หลัง rendering

Production checklist

เลือก JSON Render สำหรับ ordinary PDF/A-3b output
เลือก E-Invoice Render เมื่อจำเป็นต้องฝัง EN 16931 XML
validate PDF/A output ด้วย /validator/ หรือ veraPDF workflow ของคุณเอง
บันทึก profile ที่ request และ request ID คู่กับเอกสารที่จัดเก็บ
หลีกเลี่ยงการอ้างรองรับ arbitrary attachments เว้นแต่ public docs จะระบุไว้

ขอบเขตของ claim

PDF/A-3b คือ archival profile; e-invoice packaging เป็น workflow ที่แคบกว่าอยู่บน profile นี้
อย่าสื่อว่า embedded-file workflow แบบ arbitrary ทุกแบบได้รับการรองรับ
ต้องใช้ e-invoice route สำหรับแพ็กเกจ Factur-X และ ZUGFeRD PDF/A-3b

PDF/A-3b คือ wrapper ไม่ใช่ workflow ทั้งหมด

PDF/A-3b คือ PDF archival profile มีความสำคัญเพราะสามารถทำหน้าที่เป็น wrapper สำหรับ hybrid e-invoices ได้ แต่ profile เพียงอย่างเดียวไม่ได้ทำให้เอกสารเป็น legal e-invoice ordinary archived document สามารถใช้ PDF/A-3b ได้โดยไม่มี invoice XML ฝังอยู่

สำหรับ Factur-X และ ZUGFeRD ให้ใช้ POST /api/v1/e-invoice/render endpoint นั้นรับผิดชอบ metadata เฉพาะ e-invoice และ associated-file wiring

เลือก endpoint ตาม intent

ใช้ JSON Render เมื่อเป้าหมายคือ “เรนเดอร์เอกสารนี้เป็น PDF/A-3b” ใช้ E-Invoice Render เมื่อเป้าหมายคือ “package invoice นี้เป็น Factur-X หรือ ZUGFeRD พร้อม EN 16931 CII XML” การแยกนี้ทำให้โค้ดชัดและป้องกันไม่ให้ archival jobs ทั่วไปพก assumption ของ e-invoice โดยไม่ตั้งใจ

Validate ภายนอก

PDF/A ควรถูกตรวจด้วย reference engine ไม่ใช่ marketing claim ใช้ public validator หรือ validation pipeline ของคุณเองและจัดเก็บ report ไว้กับ audit evidence

FAQ

PDF/A-3b เป็น e-invoice เสมอหรือไม่: ไม่ PDF/A-3b คือ archival PDF profile ส่วน Factur-X และ ZUGFeRD e-invoices ใช้ PDF/A-3b เป็น wrapper สำหรับ EN 16931 XML ที่ฝังอยู่
endpoint ใดสร้าง PDF/A-3b: ใช้ POST /api/v1/pdf/render พร้อม settings.profile สำหรับ ordinary PDF/A-3b ใช้ POST /api/v1/e-invoice/render เมื่อ output ต้องเป็น Factur-X หรือ ZUGFeRD e-invoice
แนบ arbitrary files ผ่านหน้านี้ได้หรือไม่: อย่า assume ว่ารองรับ arbitrary attachment เว้นแต่ public API docs จะระบุ workflow นั้น หน้านี้เน้น PDF/A-3b และ e-invoice use ที่ documented
ตรวจสอบ PDF/A output อย่างไร: ใช้ /validator/ หรือ reference-engine pipeline ของคุณเอง สำหรับ e-invoices ให้ validate ทั้ง layer PDF/A และ layer XML ที่ฝังอยู่