Перейти к содержимому
NextPDF

Счета и электронное выставление счетов

Spec: EN 16931-1:2026, BT-24 Spec: Factur-X 1.08 Spec: ISO 32000-2:2020, §14.13 Evidence: Mixed evidence

Коротко о главном

Заголовок раздела «Коротко о главном»

Современный счёт — это два документа в одном файле: страница для человека и машиночитаемая полезная нагрузка XML для налоговой системы. Эта страница разбирает сценарий гибридного счёта от обязательства до результата: что требуют ZUGFeRD и Factur-X, как NextPDF присоединяет и проверяет структурированную полезную нагрузку и где соответствие перестаёт быть задачей движка и становится вашей.

Почему это важно

Заголовок раздела «Почему это важно»

В нескольких юрисдикциях структурированные счета уже обязательны для расчётов между компаниями или между компанией и государством. Ловушка в том, что гибридный счёт может выглядеть на экране безупречно и всё равно быть отклонён. Причина отклонения — встроенный XML, а не пиксели. Если в структурированной полезной нагрузке отсутствует идентификатор спецификации, объявлен неверный профиль или она присоединена с неверной связью, принимающая платформа отклонит счёт. С вашей стороны сбой часто выглядит незаметным, проявляется через несколько дней и задерживает платёж.

Сделать это правильно один раз — на том уровне, где создаётся файл, — гораздо дешевле, чем разбираться с каждым уже отправленным счётом отдельно.

Краткая версия

Заголовок раздела «Краткая версия»
  • Соответствующий требованиям гибридный счёт — это носитель PDF/A с соответствующей полезной нагрузкой XML, встроенной как ассоциированный файл. Метаданные носителя должны объявлять профиль.
  • Поле, которое чаще всего решает вопрос приёма, — это BT-24, идентификатор спецификации. Бизнес-правило BR-1 стандарта EN 16931 требует, чтобы оно было в каждом счёте. Значение — это URN, который указывает точный профиль; например, для профиля EN 16931 (COMFORT) — urn:cen.eu:en16931:2017.
  • Задача NextPDF — это встраивание и структурная проверка XML, предоставленного вызывающей стороной. Он не создаёт содержимое счёта и не является валидатором налогового органа.
  • Эмитент по-прежнему отвечает за юридическую и фискальную корректность. Чистый результат проверки — это один из входных данных для такого решения, а не сертификат.

Как NextPDF подходит к этому

Заголовок раздела «Как NextPDF подходит к этому»

NextPDF рассматривает структурированный счёт как межуровневый контракт, а не как отдельную функцию. Базовый движок определяет интерфейсы — встраиватель, дескриптор профиля, валидатор, — а уровень Premium предоставляет реализации. Это разделение сделано намеренно. Публичная поверхность зафиксирована в ядре, поэтому места вызова и тесты обращаются к профилю и результату одинаково, независимо от уровня, который стоит за ними.

Поток состоит из четырёх этапов, и порядок важен, потому что каждый этап зависит от предыдущего.

  1. Author the invoice XML You (or your ERP) produce a UN/CEFACT CII or Peppol UBL payload. NextPDF never synthesizes invoice content.
  2. Produce the PDF/A carrier A PDF/A-3 or PDF/A-4f document is the human-readable face and the conformant container the standard requires.
  3. Embed the payload The embedder attaches the XML as an associated file with the correct AFRelationship, and injects the Factur-X XMP profile declaration.
  4. Validate, then ship A structural pass checks the root, the required sections, and BT-24 against the declared profile before the file leaves your system.
Сценарий гибридного электронного счёта от начала до конца: вы создаёте XML и отвечаете за его юридическую корректность; NextPDF переносит его и структурно проверяет; принимающая платформа принимает окончательное решение о приёме.

Контракт встраивателя работает по принципу «байты на входе — байты на выходе»: на вход поступают носитель PDF/A и полезная нагрузка XML, а на выходе получаются байты гибридного PDF. До присоединения XML разбирается через усиленный защитный слой, который отклоняет DOCTYPE, ограничивает размер входных данных и отказывает в обработке управляющих символов, запрещённых в XML 1.0. Это конструктивно устраняет атаки XML External Entity и Billion-Laughs, потому что XML счёта регулярно приходит извне вашей границы доверия.

Дескриптор профиля отвечает на четыре вопроса, которые задаёт нижестоящая система: канонический URN профиля, значение BT-24, которое нужно подтвердить, стабильное имя для журналов и не зависящий от уровня дискриминант, чтобы тесты паритета могли группировать результаты. Дескриптор явно показывает пробелы. Профиль ZUGFeRD MINIMUM не несёт идентификатора спецификации BT-24, и дескриптор возвращает для него null вместо того чтобы выдумывать его. Поэтому же MINIMUM и BASIC WL не соответствуют EN 16931. Движок кодирует реальную область применимости наборов данных, а не скрывает её.

Что говорят свидетельства

Заголовок раздела «Что говорят свидетельства»

Описанное выше поведение закреплено в трёх местах, и у каждого свой тип свидетельства.

Сам стандарт задаёт обязательство. Spec: EN 16931-1:2026, BR-1 делает идентификатор спецификации обязательным для каждого счёта. Технический аппендикс Factur-X фиксирует значения URN для каждого профиля, включая EN 16931 профиля urn:cen.eu:en16931:2017. Сам носитель — это вопрос PDF: Spec: ISO 32000-2:2020, §9 отмечает, что наиболее предсказуемая и надёжная отрисовка достигается, когда все шрифты встроены, — что напрямую относится к делу, потому что счёт, который должен оставаться читаемым через десять лет, не может зависеть от шрифтового окружения читателя.

Сам код содержит контракт. Evidence: Code-backed Базовые EmbedderInterface, ProfileInterface и ValidatorInterface — это реальные, не зависящие от уровня интерфейсы. ProfileType::isEn16931Conformant() кодирует исключение MINIMUM / BASIC WL в системе типов. ValidationResult — это неизменяемый DTO, где isValid означает одновременно «нет находки-ошибки» и «нет фатального нарушения правила».

Само поведение задокументировано на уровне возможностей для уровня Premium: Evidence: Standard-backed встраиватель присоединяет предоставленный вызывающей стороной ZUGFeRD 2.4 / Factur-X 1.08 CII или Peppol UBL XML к носителю PDF/A-4f или PDF/A-3b с правильной связью ассоциированного файла. Валидатор проверяет семантическую модель EN 16931 и идентификатор BT-24. Этап Schematron запускает наборы правил CEN, скомпилированные в XSLT. Ничто из этого не создаёт и не исправляет содержимое счёта.

Практический пример

Заголовок раздела «Практический пример»

Приведённая ниже форма показывает место стыка, но не является готовой к копированию интеграцией. Построение носителя и встраиватель берутся с уровня Premium, а XML — ваш.

<?php


declare(strict_types=1);


use NextPDF\Contracts\EInvoice\ProfileType;
use NextPDF\Contracts\EInvoice\ValidatorContext;
use NextPDF\Contracts\EInvoice\ValidatorInterface;
use NextPDF\Contracts\EInvoice\EmbedderInterface;
use NextPDF\Contracts\EInvoice\EmbedderOptions;
use Psr\Log\LoggerInterface;


/**
 * Validate first, embed second, never ship an invalid payload.
 *
 * @param non-empty-string $carrierPdf  PDF/A-3 or PDF/A-4f carrier bytes
 * @param non-empty-string $ciiXml      Caller-authored UN/CEFACT CII XML
 *
 * @return non-empty-string Hybrid invoice bytes, ready to deliver
 */
function buildHybridInvoice(
    ValidatorInterface $validator,
    EmbedderInterface $embedder,
    LoggerInterface $logger,
    string $carrierPdf,
    string $ciiXml,
): string {
    // STRICT mode: a missing BT-24 is a hard error, not a warning.
    $context = new ValidatorContext(
        profile: ProfileType::EN16931,
        strictMode: true,
    );


    $result = $validator->validate($ciiXml, $context);


    if (!$result->isValid) {
        foreach ($result->getErrors() as $finding) {
            $logger->error('invoice.structural_finding', [
                'message' => $finding->message,
            ]);
        }


        // A failed structural check is your signal to stop, not to ship.
        throw new \RuntimeException('Invoice XML failed structural validation.');
    }


    $options = new EmbedderOptions(profile: ProfileType::EN16931);


    return $embedder->embed($carrierPdf, $ciiXml, $options);
}

Здесь важен именно порядок. Проверка обходится дёшево по сравнению с отклонённым счётом и задержанным платежом, поэтому она выполняется до того, как полезная нагрузка вообще будет присоединена.

Распространённое заблуждение

Заголовок раздела «Распространённое заблуждение»

Самое дорогое заблуждение — «NextPDF делает мои счета соответствующими требованиям.» Это не так. Эта страница прямо об этом говорит. Движок встраивает и структурно проверяет XML, который создаёте вы. Пройденная структурная проверка означает, что полезная нагрузка имеет форму, которую ожидает EN 16931, и объявляет запрошенный вами профиль. Она не означает, что счёт юридически достаточен, одобрен налоговым органом или гарантированно будет принят какой-либо платформой клиринга. Национальные расширения и транспорты клиринга находятся вне области применения на уровне движка. Как формулирует это сам EN 16931-1, базовая модель несёт информацию, необходимую для поддержки соответствия. Эмитент отвечает за соблюдение соответствующего законодательства.

Вторая, более тихая ловушка: поддержка стандарта — это не соответствие ему. Соответствие — это свойство итогового файла вместе с валидатором, а не свойство библиотеки, которая его создала.

Ограничения и границы

Заголовок раздела «Ограничения и границы»
  • NextPDF не создаёт и не исправляет содержимое счёта. Вызывающая сторона предоставляет корректный XML и остаётся эмитентом счёта. Пустой список находок не делает несоответствующую полезную нагрузку соответствующей.
  • Структурированное встраивание и проверка Schematron — это возможности уровня Premium. Ядро определяет контракты; реализации требуют коммерческого пакета. См. границу ниже.
  • Валидатор проверяет только семантическую модель EN 16931 и контейнер ZUGFeRD / Factur-X / UBL. Он не является валидатором налогового органа. Транспорт SDI, Chorus Pro и XRechnung находятся вне области применения на транспортном уровне.
  • Профили MINIMUM и BASIC WL не соответствуют EN 16931 и не несут идентификатора спецификации BT-24 — это сделано намеренно и отражает область применимости наборов данных стандарта, а не ограничение движка.
  • Движку Schematron нужен ext-xsl. Наборы правил компилируются на этапе сборки. Среда выполнения исполняет только заранее скомпилированный XSLT, при этом загрузка сетевых и файловых ресурсов отключена.
  • Эта страница описывает поведение на уровне возможностей. Она не утверждает приём каким-либо конкретным органом или платформой.
Встраивание и проверка структурированных электронных счетов — edition availability
Edition Availability
Core

Ядро определяет межуровневые контракты (EmbedderInterface, ProfileInterface, ValidatorInterface), но не поставляет реализацию структурированного счёта. Простой носитель PDF без структурированной полезной нагрузки — это результат, доступный только в Core.
Pro

Доступны встраивание CII Factur-X 1.08 в носитель PDF/A и дескрипторы профиля EN 16931 .
Enterprise

Добавляет встраивание UBL Peppol BIS 3.0, XRechnung B2G CIUS, проверку XML в режимах COMPAT/STRICT и внутрипроцессный движок правил Schematron.

Связанные документы

Заголовок раздела «Связанные документы»
  • Архивация и PDF/A — почему носителем счёта является файл PDF/A и что это гарантирует для долговременной читаемости.
  • Руководство по выбору интеграции — какой пакет экосистемы подходит для конвейера выставления счетов (генерация через очередь, мост к фреймворку или Connect).
  • Эксплуатация NextPDF в production — как наблюдать за находками и сбоями проверки, когда счета идут потоком в большом объёме.

Глоссарий

Заголовок раздела «Глоссарий»
  • Гибридный счёт — единый файл PDF, который одновременно является читаемой человеком страницей и машиночитаемой встроенной полезной нагрузкой счёта XML.
  • ZUGFeRD / Factur-X — немецкое и французское названия одного и того же подхода к гибридному счёту: полезная нагрузка XML UN/CEFACT Cross Industry Invoice (CII), встроенная в носитель PDF/A.
  • EN 16931 — европейский стандарт, определяющий семантическую модель данных базовых элементов электронного счёта.
  • BT-24 (идентификатор спецификации) — бизнес-термин EN 16931, значением которого является URN, называющий точный профиль, которому соответствует счёт. Требуется бизнес-правилом BR-1.
  • Профиль — также называется уровнем соответствия (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED, XRECHNUNG). Определяет, какие бизнес-термины должны быть в счёте.
  • Ассоциированный файл — файл, присоединённый внутри PDF с объявленной связью (AFRelationship), описывающей, как он относится к видимому документу; механизм, который переносит XML счёта.
  • Schematron — язык правил, используемый для выражения бизнес-правил EN 16931. NextPDF запускает наборы правил CEN, скомпилированные в XSLT.