Quy định hóa đơn điện tử năm 2026 của Croatia buộc các nhà phát triển PHP phải tái thiết lập quy trình xác thực – tệp Schematron của cơ quan thuế dựa trên XSLT 2.0, trong khi công cụ XSLT phổ biến nhất của PHP chỉ hỗ trợ XSLT 1.0. Kết quả là: hầu hết các ứng dụng kế toán không thể thực hiện 62 kiểm tra quy tắc kinh doanh bắt buộc nếu không có giải pháp thay thế, và một hóa đơn bị từ chối có thể làm gián đoạn dòng tiền B2B.
Tại sao rào cản kỹ thuật này lại quan trọng
Từ ngày 1 tháng 1 năm 2026, mọi giao dịch B2B tại Croatia phải được trao đổi dưới dạng e-Račun tuân thủ 62 quy tắc xác thực cụ thể. Cơ quan Thuế công bố các quy tắc đó dưới dạng tệp Schematron – về bản chất là một stylesheet XSLT 2.0 dùng để đánh dấu các vi phạm. Thư viện libxslt tích hợp sẵn của PHP, vốn là nền tảng cho xsltproc phổ biến và hầu hết các gói Composer, chỉ triển khai XSLT 1.0. Nếu không có hỗ trợ XSLT 2.0, Schematron không thể được áp dụng, điều này có nghĩa là một hệ thống lập hóa đơn dựa trên PHP sẽ hoặc là tạo ra các hóa đơn bị cổng thông tin thuế từ chối, hoặc sẽ phải gọi đến một ngôn ngữ hoặc dịch vụ khác.
Ba hướng đi mà các nhà phát triển có thể lựa chọn
| Lựa chọn | Nội dung thực hiện | Nhược điểm thực tế |
|---|---|---|
| Tiện ích mở rộng SaxonC PECL | Cài đặt bộ xử lý Saxon-C dưới dạng một tiện ích mở rộng PHP gốc, sau đó gọi Schematron trực tiếp. | Tiện ích mở rộng này không nằm trong quy trình làm việc thông thường của Composer; việc xây dựng và triển khai các tệp nhị phân gốc trên các máy chủ khác nhau làm tăng thêm sự phức tạp. |
| Dịch vụ xác thực bên ngoài | Gửi tệp XML đến một dịch vụ web để chạy Schematron thay cho bạn. | Mọi hóa đơn giờ đây đều phụ thuộc vào độ trễ mạng và tính khả dụng của dịch vụ; một sự cố tạm thời có thể làm gián đoạn hoàn toàn việc lập hóa đơn. |
| Tái triển khai các quy tắc bằng PHP | Chuyển đổi 62 khẳng định (assertions) của Schematron thành mã PHP gốc. | Đòi hỏi nỗ lực ban đầu, nhưng một khi đã lập trình xong, bộ xác thực sẽ chạy cục bộ, tích hợp mượt mà với bất kỳ ngăn xếp (stack) PHP nào và loại bỏ các phụ thuộc bên ngoài. |
Logic ẩn giấu khiến các triển khai đơn giản gặp lỗi
Một bản dịch Schematron ngây thơ vẫn có thể bỏ lỡ các ngữ nghĩa tinh tế. Hãy lấy ví dụ quy tắc HR-BR-4: “Ngày đến hạn phải tồn tại nếu số tiền phải trả lớn hơn không.” Schematron định nghĩa một biến nhân số tiền hóa đơn với –1 đối với các chứng từ giảm trừ (credit notes). Trong XML thô, một chứng từ giảm trừ hiển thị số tiền dương, nhưng biến này sẽ đảo ngược nó thành số âm, do đó điều kiện “lớn hơn không” sẽ sai. Nếu bộ xác thực chỉ đọc văn bản khẳng định, nó sẽ từ chối mọi chứng từ giảm trừ.
Bài học rất rõ ràng: hãy đọc các định nghĩa biến trong Schematron trước khi lập trình điều kiện PHP tương ứng. Mô hình tương tự cũng xuất hiện trong một số quy tắc khác, nơi các phép tính số học hoặc thao tác chuỗi được ẩn giấu đằng sau một biến $.
Các tác nhân gây từ chối phổ biến
Ngay cả khi các quy tắc được lập trình chính xác, các nhà phát triển thường bỏ qua các thành phần hóa đơn mà hệ thống thuế coi là lỗi nghiêm trọng:
- Thiếu chi tiết về đơn vị vận hành – mỗi hóa đơn phải chứa tên đầy đủ và OIB (mã số định danh cá nhân của Croatia) của đơn vị vận hành. Việc để trống bất kỳ trường nào cũng sẽ dẫn đến việc bị từ chối ngay lập tức.
- Thẻ XML trống – các thẻ như
<cbc:Note></cbc:Note>khiến bộ xác thực bị lỗi (crash). Việc loại bỏ các phần tử trống hoặc điền chúng bằng một chuỗi giữ chỗ (placeholder) sẽ giải quyết được vấn đề. - Mã KPD không chính xác – mã Klasifikacija proizvoda i usluga (KPD) phải có ít nhất sáu chữ số. Các mã ngắn hơn sẽ bị đánh dấu là sai định dạng.
- Ngày tháng không hợp lệ – bất kỳ hóa đơn nào có ngày trước ngày 1 tháng 1 năm 2026 đều vi phạm quy tắc về ngày bắt buộc, bất kể các yếu tố chính xác khác.
Những cạm bẫy khi kiểm thử
Cơ quan Thuế công bố các tệp e-Račun mẫu cho các nhà phát triển. Những ví dụ đó vẫn chứa các ngày của năm 2025 và các mã OIB không vượt qua được bộ quy tắc năm 2026. Việc sử dụng chúng làm nguồn sự thật duy nhất sẽ tạo ra cảm giác tuân thủ sai lầm. Hãy coi các mẫu chính thức như một bước kiểm tra tính hợp lý của bộ phân tích cú pháp (parser sanity check), sau đó chạy bộ thực thi quy tắc của riêng bạn với dữ liệu thực tế được tạo ra bởi ứng dụng của bạn.
Giải pháp chỉ dành cho PHP đã có sẵn trên thị trường
Một nhà phát triển đã hoàn tất lộ trình tái triển khai, đóng gói tất cả 62 quy tắc xác thực thành một thư viện có thể cài đặt qua Composer cho các dự án Laravel. Thư viện này xử lý các phép tính số học, phạm vi biến (variable scoping) và các kiểm tra trường hợp biên (edge-case) mà Schematron ẩn giấu, cho phép các hóa đơn được xác thực hoàn toàn trong môi trường thực thi (runtime) của PHP. Bằng cách loại bỏ XSLT 2.0 và các lệnh gọi bên ngoài, gói này cung cấp một lộ trình tuân thủ có tính xác định và độ trễ thấp.
Mã nguồn và hướng dẫn sử dụng có sẵn tại kho lưu trữ công khai của tác giả (liên kết được cung cấp trong bài đăng gốc).
Những điều cần theo dõi tiếp theo
- Các bộ kiểm tra PHP do cộng đồng phát triển – khi ngày càng nhiều nhà phát triển áp dụng phương pháp tái triển khai, hãy mong đợi các bản nhánh (forks) và phần mở rộng bổ sung các bộ dữ liệu mẫu cho unit-test, hỗ trợ các framework khác hoặc các tinh chỉnh về hiệu suất.
Kết luận
Quy định về hóa đơn điện tử năm 2026 của Croatia buộc các nhà phát triển PHP phải đối mặt với sự không tương thích giữa Schematron XSLT 2.0 hiện đại và công cụ XSLT 1.0 cũ của ngôn ngữ này. Việc chuyển đổi 62 quy tắc nghiệp vụ sang PHP thuần, theo dõi logic biến ẩn và tránh các lỗi XML thường gặp sẽ giúp việc lập hóa đơn được thực hiện nội bộ, tránh được các lỗi liên quan đến mạng, đồng thời chuẩn bị cho phần mềm kế toán một quá trình triển khai mượt mà và tuân thủ khi thời hạn đến gần.