กฎการออกใบแจ้งหนี้อิเล็กทรอนิกส์ (e-invoice) ปี 2026 ของโครเอเชีย บีบให้เหล่านักพัฒนา PHP ต้องสร้างระบบตรวจสอบใหม่ – ไฟล์ Schematron ของหน่วยงานสรรพากรต้องพึ่งพา XSLT 2.0 แต่เอนจิน XSLT หลักใน PHP รองรับเพียง XSLT 1.0 เท่านั้น ผลลัพธ์คือ แอปพลิเคชันบัญชีส่วนใหญ่ไม่สามารถรันการตรวจสอบกฎทางธุรกิจที่บังคับใช้ทั้ง 62 ข้อได้หากไม่มีวิธีแก้ปัญหาเฉพาะหน้า และใบแจ้งหนี้ที่ถูกปฏิเสธอาจทำให้กระแสเงินสดแบบ B2B หยุดชะงัก

ทำไมอุปสรรคทางเทคนิคนี้จึงสำคัญ

ตั้งแต่วันที่ 1 มกราคม 2026 ทุกธุรกรรมแบบ B2B ในโครเอเชียจะต้องแลกเปลี่ยนในรูปแบบ e-Račun ที่สอดคล้องกับกฎการตรวจสอบเฉพาะเจาะจง 62 ข้อ หน่วยงานสรรพากรได้เผยแพร่กฎเหล่านั้นในรูปแบบไฟล์ Schematron ซึ่งโดยพื้นฐานแล้วคือสไตล์ชีต (stylesheet) แบบ XSLT 2.0 ที่ทำหน้าที่ระบุการละเมิดกฎ ทว่าไลบรารี libxslt ที่ติดตั้งมาพร้อมกับ PHP ซึ่งเป็นขุมพลังของ xsltproc ยอดนิยมและแพ็กเกจส่วนใหญ่ใน Composer นั้นรองรับเพียง XSLT 1.0 เท่านั้น หากไม่มีการรองรับ XSLT 2.0 ก็จะไม่สามารถนำ Schematron มาใช้ได้ ซึ่งหมายความว่าระบบออกใบแจ้งหนี้ที่ใช้ PHP จะต้องเผชิญกับทางเลือกระหว่างการสร้างใบแจ้งหนี้ที่พอร์ทัลภาษีปฏิเสธ หรือต้องเรียกใช้ภาษาอื่นหรือบริการอื่นแทน

3 แนวทางที่นักพัฒนาสามารถเลือกใช้ได้

ทางเลือก รายละเอียด ข้อเสียในทางปฏิบัติ
ส่วนขยาย SaxonC PECL ติดตั้งตัวประมวลผล Saxon-C เป็นส่วนขยาย PHP แบบเนทีฟ แล้วเรียกใช้ Schematron โดยตรง ส่วนขยายนี้ไม่ได้เป็นส่วนหนึ่งของเวิร์กโฟลว์ Composer ปกติ การสร้างและติดตั้งไบนารีแบบเนทีฟบนเซิร์ฟเวอร์ที่แตกต่างกันจะเพิ่มความซับซ้อน
บริการตรวจสอบจากภายนอก ส่ง XML ไปยังเว็บเซอร์วิสที่จะรัน Schematron แทนคุณ ใบแจ้งหนี้ทุกใบจะต้องขึ้นอยู่กับความหน่วงของเครือข่ายและความพร้อมใช้งานของบริการ หากบริการขัดข้องชั่วคราวอาจทำให้การออกใบแจ้งหนี้หยุดชะงักทั้งหมด
เขียนกฎขึ้นมาใหม่ด้วย PHP แปลงข้อกำหนด (assertions) ทั้ง 62 ข้อของ Schematron ให้เป็นโค้ด PHP แบบเนทีฟ ต้องใช้ความพยายามในช่วงเริ่มต้น แต่เมื่อเขียนโค้ดเสร็จแล้ว ตัวตรวจสอบจะทำงานแบบโลคัล สามารถรวมเข้ากับ PHP stack ใดๆ ได้อย่างราบรื่น และช่วยลดการพึ่งพาปัจจัยภายนอก

ตรรกะที่ซ่อนอยู่ซึ่งทำให้การเขียนโปรแกรมแบบง่ายๆ พลาดได้

การแปล Schematron แบบผิวเผินอาจทำให้พลาดความหมายที่ละเอียดอ่อนได้ ตัวอย่างเช่น กฎ HR-BR-4: "ต้องมีวันครบกำหนดชำระ หากยอดเงินที่ต้องชำระมากกว่าศูนย์" ใน Schematron มีการกำหนดตัวแปรที่จะนำยอดเงินในใบแจ้งหนี้ไปคูณด้วย –1 สำหรับใบลดหนี้ (credit notes) ในไฟล์ XML ดิบ ใบลดหนี้จะแสดงยอดเงินเป็นบวก แต่ตัวแปรจะเปลี่ยนค่าให้เป็นลบ ดังนั้นเงื่อนไข "มากกว่าศูนย์" จึงเป็นเท็จ หากตัวตรวจสอบอ่านเพียงแค่ข้อความของเงื่อนไข (assertion text) มันจะปฏิเสธใบลดหนี้ทุกใบ

บทเรียนนี้ชัดเจนมาก: จงอ่านการกำหนดค่าตัวแปร ใน Schematron ก่อนที่จะเขียนเงื่อนไข PHP ที่เกี่ยวข้อง รูปแบบเดียวกันนี้ยังปรากฏในกฎอื่นๆ อีกหลายข้อ ที่มีการคำนวณทางคณิตศาสตร์หรือการจัดการสตริงซ่อนอยู่เบื้องหลังตัวแปร $

สาเหตุทั่วไปที่ทำให้ใบแจ้งหนี้ถูกปฏิเสธ

แม้จะเขียนกฎได้อย่างถูกต้อง แต่นักพัฒนามักมองข้ามองค์ประกอบของใบแจ้งหนี้ที่ระบบภาษีถือว่าเป็นข้อผิดพลาดร้ายแรง:

  • ข้อมูลผู้ประกอบการไม่ครบถ้วน – ใบแจ้งหนี้ทุกใบต้องมีชื่อเต็มของผู้ประกอบการและหมายเลข OIB (หมายเลขประจำตัวบุคคลของโครเอเชีย) หากปล่อยช่องใดช่องหนึ่งว่างไว้ จะถูกปฏิเสธทันที
  • แท็ก XML ว่างเปล่า – แท็กอย่างเช่น <cbc:Note></cbc:Note> อาจทำให้ตัวตรวจสอบล่ม (crash) การลบองค์ประกอบที่ว่างเปล่าออกหรือการใส่ข้อความสำรอง (placeholder) ลงไปจะช่วยแก้ปัญหานี้ได้
  • รหัส KPD ไม่ถูกต้อง – รหัส Klasifikacija proizvoda i usluga (KPD) ต้องมีอย่างน้อยหกหลัก หากรหัสสั้นเกินไปจะถูกระบุว่ารูปแบบไม่ถูกต้อง
  • วันที่ไม่ถูกต้อง – ใบแจ้งหนี้ใดๆ ที่ลงวันที่ก่อนวันที่ 1 มกราคม 2026 จะไม่ผ่านกฎเรื่องวันที่บังคับ โดยไม่คำนึงถึงความถูกต้องในส่วนอื่นๆ

ข้อควรระวังในการทดสอบ

หน่วยงานสรรพากรได้เผยแพร่ไฟล์ตัวอย่าง e-Račun สำหรับนักพัฒนา แต่ตัวอย่างเหล่านั้นยังคงใช้ปี 2025 และหมายเลข OIB ที่ไม่ผ่านชุดกฎของปี 2026 การใช้ตัวอย่างเหล่านี้เป็นแหล่งอ้างอิงเพียงอย่างเดียวจะทำให้เข้าใจผิดว่าระบบสอดคล้องกับกฎแล้ว ให้ถือว่าตัวอย่างอย่างเป็นทางการเป็นเพียงการตรวจสอบความถูกต้องเบื้องต้นของตัวแยกส่วน (parser sanity check) จากนั้นจึงรันชุดทดสอบการบังคับใช้กฎของคุณเองกับข้อมูลจริงที่สร้างขึ้นจากแอปพลิเคชันของคุณ

โซลูชัน PHP เพียวๆ ที่มีให้ใช้งานแล้ว

นักพัฒนาคนหนึ่งได้เลือกเส้นทางการเขียนกฎขึ้นมาใหม่จนสำเร็จ โดยการแพ็กกฎการตรวจสอบทั้ง 62 ข้อเป็นไลบรารีที่ติดตั้งผ่าน Composer ได้สำหรับโปรเจกต์ Laravel ไลบรารีนี้จัดการทั้งการคำนวณ การกำหนดขอบเขตตัวแปร (variable scoping) และการตรวจสอบกรณีขอบเขต (edge-case) ที่ Schematron ซ่อนไว้ ทำให้สามารถตรวจสอบใบแจ้งหนี้ได้ภายใน PHP runtime ทั้งหมด การตัดความจำเป็นในการใช้ XSLT 2.0 และการเรียกใช้บริการภายนอกออกไป ทำให้แพ็กเกจนี้เป็นเส้นทางสู่การปฏิบัติตามกฎที่คาดการณ์ผลลัพธ์ได้แน่นอนและมีความหน่วงต่ำ

ซอร์สโค้ดและคู่มือการใช้งานมีอยู่ในคลังเก็บโค้ดสาธารณะ (public repository) ของผู้เขียน (ลิงก์อยู่ในโพสต์ต้นฉบับ)

สิ่งที่ควรติดตามต่อไป

  • ตัวตรวจสอบ PHP ที่ขับเคลื่อนโดยชุมชน – เมื่อนักพัฒนาหันมาใช้แนวทางการเขียนขึ้นใหม่ (re-implementation) มากขึ้น ให้คาดหวังว่าจะมีการแยกสาขา (forks) และส่วนขยาย (extensions) ที่เพิ่มชุดข้อมูลสำหรับ unit-test (fixtures), การรองรับเฟรมเวิร์กอื่นๆ หรือการปรับแต่งประสิทธิภาพ

บทสรุป

ข้อบังคับการออกใบแจ้งหนี้อิเล็กทรอนิกส์ (e-invoice) ของโครเอเชียในปี 2026 บีบให้นักพัฒนา PHP ต้องเผชิญกับความไม่สอดคล้องกันระหว่าง Schematron แบบ XSLT 2.0 ที่ทันสมัย กับ engine XSLT 1.0 แบบดั้งเดิมของภาษา การแปลงกฎทางธุรกิจทั้ง 62 ข้อให้เป็น PHP แบบ native การเฝ้าระวังตรรกะของตัวแปรที่ซ่อนอยู่ และการหลีกเลี่ยงข้อผิดพลาดทั่วไปของ XML จะช่วยให้การออกใบแจ้งหนี้สามารถจัดการได้ภายในองค์กร หลีกเลี่ยงความล้มเหลวที่เกี่ยวข้องกับเครือข่าย และเตรียมความพร้อมให้ซอฟต์แวร์บัญชีสำหรับการเปิดใช้งานที่ราบรื่นและเป็นไปตามข้อกำหนดเมื่อถึงกำหนดเส้นตาย