ใบแจ้งหนี้

ภาพรวมโดยสังเขป

NextPDF Enterprise สร้างใบแจ้งหนี้แบบไฮบริดที่มีโครงสร้าง ZUGFeRD / Factur-X / Peppol-UBL และตรวจสอบ XML ของใบแจ้งหนี้กับโมเดลข้อมูล EN 16931 และชุดกฎ Schematron มันสร้างใบแจ้งหนี้แบบมีโครงสร้างที่สอดคล้องกับโมเดลข้อมูลที่กำหนดไว้ใน EN 16931 มันไม่ใช่ตัวตรวจสอบของหน่วยงานภาษีและไม่ได้รับรองเอกสารใด ๆ

ความพร้อมใช้งานและการอนุญาต

ความสามารถนี้จัดส่งใน NextPDF Enterprise (nextpdf/enterprise) และเปิดใช้งานด้วยซองใบอนุญาตระดับ Enterprise การปรับใช้ที่ไม่มีสิทธิ์นั้นจะไม่โหลดคลาสของความสามารถนี้ เปรียบเทียบรุ่นและรับใบอนุญาต

การติดตั้ง

composer require nextpdf/enterprise:^3

เอนจิน Schematron ใช้ส่วนขยาย PHP ext-xsl ติดตั้งและเปิดใช้งานก่อนรันการตรวจสอบ Schematron

ภาพรวมเชิงแนวคิด

โมดูล Invoice มีพื้นผิวอิสระสามด้าน ได้แก่ การ embedding ใบแจ้งหนี้แบบมีโครงสร้าง การ ตรวจสอบ XML ตาม EN 16931 และการรันกฎ Schematron

Embedding ZugferdEmbedder แนบ payload XML ของ ZUGFeRD 2.4 / Factur-X 1.08 UN/CEFACT CII ที่ผู้เรียกใช้จัดหามาเข้ากับตัวพา PDF/A เพื่อสร้างใบแจ้งหนี้แบบไฮบริด รองรับรูปแบบตัวพาสองแบบ ได้แก่ PDF/A-4f (ISO 19005-4:2020) ซึ่งเป็นตัวพาสมัยใหม่ที่เป็นที่นิยม และ PDF/A-3b (ISO 19005-3:2012) เพื่อความเข้ากันได้แบบย้อนหลัง ZugferdXmpSchema ฉีดการประกาศ extension-schema ของ Factur-X XMP ที่ตัวพาต้องการ PeppolEmbedder ทำหน้าที่เดียวกันสำหรับ XML ใบแจ้งหนี้หรือใบลดหนี้ Peppol BIS Billing 3.0 UBL 2.1 ที่ผู้เรียกใช้จัดหามา โดยแนบด้วยความสัมพันธ์ของไฟล์ที่เกี่ยวข้องและชนิด MIME ที่ถูกต้อง NextPDF ไม่ได้สังเคราะห์ XML ของใบแจ้งหนี้ ผู้เรียกใช้เป็นผู้จัดหา XML ที่ถูกต้องและยังคงเป็นผู้ออกใบแจ้งหนี้

Validation InvoiceXmlValidator ตรวจสอบ XML ของใบแจ้งหนี้กับโมเดลข้อมูลเชิงความหมาย EN 16931 และความคาดหวังของตัวพา ZUGFeRD / Factur-X รวมถึง specification identifier BT-24 ที่กฎทางธุรกิจ BR-1 ของ EN 16931 บังคับไว้ มันทำงานในหนึ่งจากสองโหมด ได้แก่ COMPAT (ค่าเริ่มต้น โดยข้อค้นพบเรื่อง cardinality ของ EN 16931 ที่อยู่กึ่งกลางจะถูกรายงานเป็นคำเตือนเพื่อรักษาความเข้ากันได้แบบย้อนหลังสำหรับ fixture ที่มีอยู่) และ STRICT (cardinality ของ BT-24 เป็นข้อผิดพลาดที่เข้มงวด สะท้อนความหมายของตัวตรวจสอบภายนอก) โหมดสามารถเลือกได้ต่อการเรียกใช้ โดยการแทนที่ผ่านสภาพแวดล้อม หรือโดยนโยบายความสอดคล้อง

Schematron SchematronValidator รันชุดกฎ Schematron ที่คอมไพล์ไว้ล่วงหน้า (กฎ .sch ของ CEN EN 16931 ที่คอมไพล์เป็น XSLT ในเวลาบิลด์) กับ XML ของใบแจ้งหนี้โดยใช้ตัวประมวลผล PHP XSLT ในกระบวนการ และแยกวิเคราะห์รายงาน SVRL ให้เป็นข้อค้นพบแบบมีโครงสร้าง enum ZugferdProfile จำลองโปรไฟล์ความสอดคล้อง ได้แก่ MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED และ XRechnung B2G CIUS ของเยอรมันบน EN 16931

โมดูลนี้อ้างและไม่อ้างอะไร

โมดูลนี้สร้างและตรวจสอบข้อมูลใบแจ้งหนี้แบบมีโครงสร้าง มัน ไม่ ยืนยันว่าเอกสารใดเป็นใบแจ้งหนี้ที่เป็นไปตามกฎหมาย ว่าได้รับการอนุมัติจากหน่วยงานภาษี หรือว่ารับประกันว่าจะได้รับการยอมรับจากหน่วยงานใด

• ตัวตรวจสอบตรวจสอบโมเดลเชิงความหมาย EN 16931 และตัวพา ZUGFeRD / Factur-X / UBL เท่านั้น มัน ไม่ใช่ตัวตรวจสอบของหน่วยงานภาษี ส่วนขยายระดับชาติและแพลตฟอร์มการอนุมัติ เช่น Italian SDI, French Chorus Pro, German XRechnung transport อยู่นอกขอบเขตในระดับการขนส่ง
• ตามที่ EN 16931-1 เองระบุไว้ โมเดลเชิงความหมายหลักบรรจุข้อมูลที่จำเป็นซึ่งใบแจ้งหนี้อิเล็กทรอนิกส์ต้องใช้เพื่อรองรับการปฏิบัติตามกฎหมายและภาษี ผู้ออกใบแจ้งหนี้มีหน้าที่รับผิดชอบในการปฏิบัติตามกฎของกฎหมายที่เกี่ยวข้อง นี่ไม่ใช่ตัวตรวจสอบของหน่วยงานภาษี
• การรองรับมาตรฐานไม่เหมือนกับความสอดคล้องกับมาตรฐานนั้น โปรดปรึกษาที่ปรึกษาด้านภาษีและการปฏิบัติตามกฎของคุณเพื่อตัดสินความเพียงพอตามกฎระเบียบในเขตอำนาจของคุณ

เหตุผลที่ทำงานเช่นนี้

โมดูลนี้จงใจไม่สังเคราะห์ XML ของใบแจ้งหนี้เลย การ embedding การตรวจสอบ EN 16931 และการรัน Schematron เป็นพื้นผิวอิสระสามด้านเหนือ XML ที่ผู้เรียกใช้จัดหาและเป็นเจ้าของ สิ่งนี้ทำให้ NextPDF เป็นผู้ผลิตและผู้ตรวจสอบ ไม่เคยเป็นผู้ออก เพราะความรับผิดชอบทางกฎหมายไม่สามารถมอบหมายให้ไลบรารีได้ การตรวจสอบมีค่าเริ่มต้นเป็น COMPAT ดังนั้นข้อค้นพบเรื่อง cardinality ที่อยู่กึ่งกลางจึงเป็นคำเตือนแทนที่จะเป็นการถดถอย STRICT เป็นการเลือกเปิดใช้เมื่อคุณต้องการความหมายของตัวตรวจสอบภายนอก ผลลัพธ์คือการแยกที่ชัดเจน คือ NextPDF รายงานสิ่งที่สังเกตได้ และผู้ออกเป็นผู้ตัดสินว่าเอกสารเป็นไปตามกฎหมายหรือไม่ ภูมิหลังการออกแบบ Invoices and e-invoicing

พื้นผิว API

Class	Responsibility
ZugferdEmbedder	แนบ XML ZUGFeRD / Factur-X CII เข้ากับตัวพา PDF/A-4f หรือ PDF/A-3b
ZugferdXmpSchema	ฉีดการประกาศ extension-schema ของ Factur-X XMP
ZugferdProfile	enum โปรไฟล์ความสอดคล้อง (MINIMUM … EXTENDED, XRECHNUNG)
PeppolEmbedder	แนบ XML ใบแจ้งหนี้ / ใบลดหนี้ Peppol BIS 3.0 UBL เข้ากับตัวพา PDF/A
InvoiceXmlValidator	ตรวจสอบ XML กับโมเดลข้อมูล EN 16931 โหมด COMPAT หรือ STRICT
InvoiceValidatorMode	enum โหมดการตรวจสอบ ได้แก่ COMPAT (ค่าเริ่มต้น) หรือ STRICT
SchematronValidator	รันชุดกฎ Schematron ที่คอมไพล์ไว้ล่วงหน้า แยกวิเคราะห์ข้อค้นพบ SVRL
InvoiceValidationResult / SchematronResult	ผลลัพธ์แบบมีโครงสร้าง ได้แก่ โปรไฟล์ ข้อค้นพบ ระดับความรุนแรง

ตัวอย่างโค้ด — เริ่มต้นใช้งานอย่างรวดเร็ว

use NextPDF\Enterprise\Invoice\ZugferdEmbedder;
use NextPDF\Enterprise\Invoice\ZugferdProfile;

$pdf = ZugferdEmbedder::basic($pdfAManager, $fileAttachment, $ciiXml)
    ->embed(ZugferdProfile::EN16931);

ตัวอย่างโค้ด — การใช้งานจริง

use NextPDF\Enterprise\Invoice\InvoiceXmlValidator;
use NextPDF\Enterprise\Invoice\InvoiceValidatorMode;

$result = $validator->validate($ciiXml, InvoiceValidatorMode::STRICT);

foreach ($result->findings as $finding) {
    $logger->warning('invoice.finding', [
        'rule'     => $finding->ruleId,
        'severity' => $finding->severity->value,
    ]);
}
// A clean result is one input to your decision, not a compliance verdict.
// The invoice issuer remains responsible for relevant legislation.

กรณีขอบและข้อควรระวัง

• PDF ที่มีรูปแบบถูกต้องแต่ไม่มี payload ใบแจ้งหนี้ที่จดจำได้จะให้ผลลัพธ์ “not an invoice” แทนที่จะ throw
• COMPAT เป็นโหมดการตรวจสอบค่าเริ่มต้น คือ specification identifier BT-24 ที่ขาดหายไปจะถูกรายงานเป็น คำเตือน เพื่อให้จุดเรียกใช้ที่ตัดสินจากแฟล็กความถูกต้องแบบบูลีนไม่ถดถอย ใช้ STRICT เพื่อทำให้ BT-24 เป็นข้อผิดพลาดที่เข้มงวดซึ่งตรงกับความหมายของ KoSIT / Mustang ภายนอก
• ผู้เรียกใช้เป็นผู้จัดหา XML ของใบแจ้งหนี้ NextPDF ไม่ได้สร้างหรือแก้ไขมัน รายการข้อค้นพบที่ว่างเปล่าไม่ได้ทำให้ payload ที่ไม่สอดคล้องกลายเป็นสอดคล้อง
• เอนจิน Schematron ต้องใช้ ext-xsl ชุดกฎถูกคอมไพล์ในเวลาบิลด์ ส่วนรันไทม์เรียกใช้ XSLT ที่คอมไพล์ไว้ล่วงหน้าเท่านั้น

ประสิทธิภาพ

ต้นทุนการตรวจสอบขยายตามขนาด XML ที่ฝังและจำนวนกฎ Schematron ต้นทุนการ embedding ขยายตามขนาดตัวพาและถูกครอบงำโดยการ serialize PDF/A งบประมาณประสิทธิภาพของหน้าสะท้อนการเรนเดอร์เอกสารประกอบ ไม่ใช่ throughput ของใบแจ้งหนี้

บันทึกด้านความปลอดภัย

การแยกวิเคราะห์ XML ทั้งหมดส่งผ่าน XML guard ที่เสริมความแข็งแกร่ง คือ การ resolve external-entity ถูกปิดใช้งาน (ปลอดภัยจาก XXE) DOCTYPE ถูกปฏิเสธ และการคลายการบีบอัดมีขอบเขต ตัวประมวลผล XSLT รันโดยปิดการโหลดทรัพยากรเครือข่ายและระบบไฟล์ และไม่เคยลงทะเบียนฟังก์ชัน PHP ดังนั้น document(), xsl:include, xsl:import และ result-document จึงไม่สามารถเข้าถึงเครือข่ายหรือดิสก์ได้ ให้ปฏิบัติต่อ XML ของใบแจ้งหนี้จากแหล่งที่ไม่น่าเชื่อถือเสมือนเป็นภัยคุกคาม

Data residency และการลดผลกระทบ PII

XML ของใบแจ้งหนี้อาจมีข้อมูลส่วนบุคคล ข้อมูลเชิงพาณิชย์ และข้อมูลการเงิน การประมวลผลทำในกระบวนการและในเครื่อง โมดูลไม่ได้เรียกเครือข่ายขาออกระหว่างการ embedding หรือการตรวจสอบ ให้ใช้การควบคุมการเก็บรักษาและการลดข้อมูลให้น้อยที่สุดของคุณเองกับ XML และข้อค้นพบที่สกัดออกมา

การวัดและส่งข้อมูลที่ปลอดภัยและการขัดล้างบันทึก

ข้อค้นพบและบันทึกการตรวจสอบอาจรวมตัวระบุกฎและค่าแท็ก แต่ไม่รวม payload ใบแจ้งหนี้ทั้งหมด ให้ขัดล้างหรือกลบค่าฟิลด์ก่อนส่งต่อบันทึกไปยัง sink ที่ใช้ร่วมกันหากค่าเหล่านั้นเป็นข้อมูลอ่อนไหว

ความสอดคล้อง

Behavior	Reference	Status
โมเดลเชิงความหมายหลักของใบแจ้งหนี้	EN 16931-1:2026 §4	สร้างขึ้นตาม ผู้ออกยังคงรับผิดชอบกฎหมายที่เกี่ยวข้อง
Specification identifier (BT-24)	EN 16931-1:2026 BR-1	ตรวจสอบแล้ว (คำเตือนใน COMPAT ข้อผิดพลาดใน STRICT)
UN/CEFACT CII syntax binding	CEN/TS 16931-3-3:2020	รองรับการ embed
UBL 2.1 syntax binding	CEN/TS 16931-3-2:2020	รองรับการ embed
PDF/A-3 associated file	ISO 19005-3:2012 §6.7.8	รองรับตัวพา
PDF/A-4f embedded file	ISO 19005-4:2020 Annex A	รองรับตัวพา

ตารางนี้บันทึกข้อกำหนดที่ NextPDF Enterprise สร้างขึ้นตามและสิ่งที่ตรวจสอบ มันไม่ใช่คำแถลงเรื่องการรับรอง การอนุมัติจากหน่วยงานภาษี หรือความเพียงพอตามกฎระเบียบ ผู้ออกใบแจ้งหนี้มีหน้าที่รับผิดชอบในการปฏิบัติตามกฎของกฎหมายที่เกี่ยวข้อง นี่ไม่ใช่ตัวตรวจสอบของหน่วยงานภาษี

พฤติกรรมในโหมด FIPS

โมดูลนี้ไม่ได้ทำการลงนามทางการเข้ารหัส การลงนามใบแจ้งหนี้แบบไฮบริดและการเก็บรักษาคีย์ในโหมด FIPS อยู่นอกขอบเขตที่นี่ ดูโมดูล Signature

แบบจำลองภัยคุกคาม

XML ใบแจ้งหนี้ที่ไม่น่าเชื่อถือเป็นอินพุตหลัก การลดผลกระทบ ได้แก่ การแยกวิเคราะห์ที่ปลอดภัยจาก XXE การปฏิเสธ DOCTYPE การคลายการบีบอัดที่มีขอบเขต ตัวประมวลผล XSLT ที่ปิดการโหลดทรัพยากรเครือข่ายและไฟล์ และการไม่สังเคราะห์ข้ออ้าง — ผู้เรียกใช้จัดหาและเป็นเจ้าของเนื้อหาใบแจ้งหนี้

สัญญาด้านพฤติกรรม

• ZugferdEmbedder / PeppolEmbedder แนบ XML ใบแจ้งหนี้ที่ผู้เรียกใช้จัดหามาเข้ากับตัวพา PDF/A-4f หรือ PDF/A-3b NextPDF ไม่เคยสังเคราะห์ XML ของใบแจ้งหนี้
• InvoiceXmlValidator รันในโหมด COMPAT (ค่าเริ่มต้น cardinality ของ EN 16931 ที่อยู่กึ่งกลางเป็นคำเตือน) หรือ STRICT (cardinality ของ BT-24 เป็นข้อผิดพลาดที่เข้มงวด)
• SchematronValidator รันชุดกฎที่คอมไพล์ไว้ล่วงหน้าผ่านตัวประมวลผล XSLT ในกระบวนการและแยกวิเคราะห์ข้อค้นพบ SVRL รายการข้อค้นพบที่ว่างเปล่าไม่ได้ทำให้ payload ที่ไม่สอดคล้องกลายเป็นสอดคล้อง
• การแยกวิเคราะห์ XML ทั้งหมดปลอดภัยจาก XXE คือ การ resolve external-entity ถูกปิดใช้งาน DOCTYPE ถูกปฏิเสธ และการคลายการบีบอัดมีขอบเขต

ขอบเขตการเผยแพร่

หน้านี้อธิบายเฉพาะพฤติกรรมที่สังเกตได้จากภายนอกและพื้นผิว API สาธารณะที่รองรับเท่านั้น เส้นทาง namespace ภายใน คลาสตัวช่วย ตารางกลไก ชื่อไฟล์ runbook และคำนำหน้า ticket อยู่นอกขอบเขต

การถอยกลับไปใช้ Core

NextPDF Core ไม่ได้สร้างหรือตรวจสอบใบแจ้งหนี้แบบมีโครงสร้าง การปรับใช้แบบ Core เท่านั้นสามารถสร้าง PDF ได้ แต่ไม่มีการ embed ZUGFeRD / Factur-X / Peppol ไม่มีตัวตรวจสอบ EN 16931 และไม่มีเอนจิน Schematron

การถอยกลับไปใช้ Pro

ในการปรับใช้แบบ Pro เท่านั้น พื้นผิวที่รองรับคือการ ตรวจจับและตรวจสอบ e-invoice ระดับ Pro ของ payload Factur-X / ZUGFeRD Pro ไม่ได้ สร้างตัวพาแบบไฮบริด ZUGFeRD / Factur-X หรือ Peppol-UBL ไม่ได้เพิ่มโปรไฟล์ XRechnung CIUS และไม่ได้รันเอนจิน Schematron ในกระบวนการ การกำหนดค่าที่ร้องขอการสร้าง โปรไฟล์ XRechnung CIUS หรือ Schematron ในการปรับใช้แบบ Pro เท่านั้นจะไม่มีส่วนประกอบ Enterprise มาตอบสนอง ดู Pro Compliance สำหรับพื้นผิวการตรวจจับและการตรวจสอบของ Pro

บันทึกขอบเขตของ Enterprise

รายละเอียดกลไกภายในยังคงอยู่ในเอกสารภายในของ source repository และอยู่นอกขอบเขตของคู่มือนี้

ขอบเขตการปรับใช้

เอนจิน Schematron ต้องใช้ส่วนขยาย PHP ext-xsl การจัดเตรียมและเปิดใช้งานมันเป็นความรับผิดชอบของผู้ดำเนินการ การประมวลผลทำในกระบวนการและในเครื่อง โมดูลไม่ได้เรียกเครือข่ายขาออกระหว่างการ embedding หรือการตรวจสอบ การขนส่ง e-invoicing ระดับชาติ แพลตฟอร์มการอนุมัติ และระบบการเก็บถาวรอยู่ภายนอกโมดูลนี้และเป็นความรับผิดชอบของผู้ดำเนินการ

ขอบเขตการปฏิบัติตามกฎหมาย

NextPDF สร้างใบแจ้งหนี้แบบมีโครงสร้างที่สอดคล้องกับโมเดลข้อมูลที่กำหนดไว้ใน EN 16931 และรายงานข้อค้นพบของกฎ มัน ไม่ได้ สร้าง “ใบแจ้งหนี้ที่เป็นไปตามกฎหมาย” ไม่ได้จัดหาผลลัพธ์ที่ “ได้รับการอนุมัติจากหน่วยงานภาษี” และไม่ได้รับประกันว่าใบแจ้งหนี้ใดจะได้รับการยอมรับจากหน่วยงานภาษี ศาล หรือทะเบียน ผู้ออกใบแจ้งหนี้มีหน้าที่รับผิดชอบในการปฏิบัติตามกฎของกฎหมายที่เกี่ยวข้อง นี่ไม่ใช่ตัวตรวจสอบของหน่วยงานภาษี แพลตฟอร์ม e-invoicing ระดับชาติ โมเดลการอนุมัติ ข้อบังคับการเก็บถาวร และข้อกำหนดลายเซ็นดิจิทัลแตกต่างกันไปตามเขตอำนาจและเป็นความรับผิดชอบของผู้ออก โปรดปรึกษาที่ปรึกษาด้านภาษีและกฎหมายของคุณ

ดูเพิ่มเติม

• Invoice reference — เอกสารอ้างอิงระดับ API สำหรับตัว embedder ตัวตรวจสอบ และเอนจิน Schematron
• Pro Compliance — การตรวจจับและตรวจสอบ e-invoice ระดับ Pro
• Document E-Filing — การปรับให้เหมาะสมสำหรับการส่งมอบต่อศาล/ทะเบียน
• Enterprise overview
• Core vs Pro vs Enterprise feature matrix