Новые правила электронного выставления счетов в Хорватии с 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 для кредитных нот. В исходном 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-валидаторы, развиваемые сообществом — по мере того как всё больше разработчиков переходят к подходу с повторной реализацией, стоит ожидать появления форков и расширений, добавляющих фикстуры для юнит-тестов, поддержку других фреймворков или оптимизацию производительности.

Итог

Требование Хорватии по внедрению электронных счетов-фактур в 2026 году заставляет PHP-разработчиков столкнуться с несоответствием между современным Schematron на базе XSLT 2.0 и устаревшим движком XSLT 1.0 самого языка. Перенос 62 бизнес-правил на нативный PHP, контроль логики скрытых переменных и избегание типичных ловушек XML позволяют обрабатывать счета внутри системы, минимизировать риск сетевых сбоев и подготовить бухгалтерское ПО к плавному и соответствующему всем нормам запуску к установленному сроку.