Правило електронного інвойсування Хорватії 2026 року змушує PHP-розробників заново створювати механізми валідації — файл Schematron податкової служби базується на XSLT 2.0, проте домінуючий XSLT-рушій PHP підтримує лише XSLT 1.0. Результат: більшість бухгалтерських застосунків не можуть виконати 62 обов'язкові перевірки бізнес-правил без обхідних шляхів, а відхилений інвойс може зупинити B2B-грошові потоки.

Чому ця технічна перешкода має значення

З 1 січня 2026 року кожна B2B-транзакція в Хорватії має здійснюватися у форматі e-Račun, що відповідає 62 специфічним правилам валідації. Податкова адміністрація публікує ці правила у вигляді файлу Schematron — по суті, це таблиця стилів XSLT 2.0, яка фіксує порушення. Вбудована бібліотека PHP libxslt, яка лежить в основі популярного xsltproc та більшості пакетів Composer, реалізує лише XSLT 1.0. Без підтримки XSLT 2.0 Schematron неможливо застосувати, а це означає, що система виставлення рахунків на базі PHP або створюватиме інвойси, які відхилить податковий портал, або потребуватиме звернення до іншої мови програмування чи сервісу.

Три шляхи, які можуть обрати розробники

Варіант Що це передбачає Практичні недоліки
Розширення SaxonC PECL Встановити процесор Saxon-C як нативне розширення PHP, а потім викликати Schematron безпосередньо. Розширення не є частиною типового робочого процесу Composer; збірка та розгортання нативних бінарних файлів на різних серверах додає складності.
Зовнішній сервіс валідації Надсилати XML на вебсервіс, який виконує Schematron від вашого імені. Кожен інвойс тепер залежить від затримки мережі та доступності сервісу; тимчасовий збій може повністю заблокувати виставлення рахунків.
Реалізувати правила заново на PHP Перекласти 62 твердження Schematron у нативний код PHP. Потребує попередніх зусиль, але після написання коду валідатор працює локально, легко інтегрується з будь-яким PHP-стеком і усуває зовнішні залежності.

Прихована логіка, яка підводить прості реалізації

Наївний переклад Schematron все одно може пропустити тонкі семантичні нюанси. Візьмемо правило HR-BR-4: «Термін оплати має бути вказаний, якщо сума до сплати більша за нуль». Schematron визначає змінну, яка множить суму інвойсу на –1 для кредитних нот (credit notes). У сирому XML кредитна нота відображається з позитивною сумою, але змінна робить її від'ємною, тому умова «більше нуля» стає хибною. Якщо валідатор зчитує лише текст твердження, він відхилить кожну кредитну ноту.

Урок очевидний: читайте визначення змінних у Schematron перед написанням відповідної умови на PHP. Така ж модель зустрічається в кількох інших правилах, де арифметичні операції або маніпуляції з рядками приховані за змінною $.

Поширені причини відхилення

Навіть із правильно написаними правилами розробники часто ігнорують елементи інвойсу, які податкова система розцінює як критичні помилки:

  • Відсутність даних оператора — кожен інвойс повинен містити повне ім'я оператора та OIB (хорватський персональний ідентифікаційний номер). Залишення будь-якого з цих полів порожнім призводить до негайного відхилення.
  • Порожні XML-теги — такі теги, як <cbc:Note></cbc:Note>, призводять до збою валідатора. Видалення порожніх елементів або заповнення їх рядком-заповнювачем (placeholder) вирішує проблему.
  • Неправильні коди KPD — код Klasifikacija proizvoda i usluga (KPD) має складатися щонайменше з шести цифр. Короткі коди позначаються як некоректні.
  • Недійсні дати — будь-який інвойс, датований раніше 1 січня 2026 року, не відповідає правилу обов'язкової дати, незалежно від інших параметрів правильності.

Пастки тестування

Податкова адміністрація публікує зразки файлів e-Račun для розробників. Ці приклади все ще містять дати 2025 року та OIB, які не пройдуть перевірку за набором правил 2026 року. Використання їх як єдиного джерела істини створює хибне відчуття відповідності вимогам. Ставтеся до офіційних зразків лише як до перевірки коректності роботи парсера, а потім запускайте власний набір перевірок правил на реалістичних даних, згенерованих вашим застосунком.

Рішення суто на PHP, яке вже існує

Один розробник довів шлях повторної реалізації правил до кінця, упакувавши всі 62 правила валідації в бібліотеку, яку можна встановити через Composer для проєктів на Laravel. Бібліотека обробляє арифметику, область видимості змінних та перевірки граничних випадків, які приховані в Schematron, що дозволяє валідувати інвойси повністю в середовищі виконання PHP. Усуваючи потребу в XSLT 2.0 та зовнішніх викликах, цей пакет пропонує детермінований шлях до відповідності вимогам із низькою затримкою.

Вихідний код та посібник із використання доступні у публічному репозиторії автора (посилання надано в оригінальному дописі).

За чим стежити далі

  • PHP-валідатори, що створюються спільнотою — оскільки все більше розробників обирають підхід із повторної реалізації, варто очікувати на появу форків та розширень, які додаватимуть фікстури для юніт-тестів, підтримку інших фреймворків або оптимізацію продуктивності.

Підсумок

Вимога Хорватії щодо електронних інвойсів, що вступає в силу у 2026 році, змушує PHP-розробників зіткнутися з невідповідністю між сучасним Schematron XSLT 2.0 та застарілим рушієм XSLT 1.0 мови. Переклад 62 бізнес-правил на нативний PHP, відстеження логіки прихованих змінних та уникнення типових пасток XML дозволяють здійснювати виставлення рахунків локально, допомагають уникнути збоїв, пов'язаних із мережею, і готують бухгалтерське програмне забезпечення до плавного та відповідного нормам впровадження, коли настане встановлений термін.