7-PDF E-Invoice Validator проверяет электронные счета в PDF/ZUGFeRD и XML/XRechnung по правилам EN 16931, отдельно показывает состояние встроенного XML и соответствие PDF/A-3, открывает человекочитаемое представление реквизитов и формирует подробный протокол с ошибками. Файл можно перетащить в окно, выбрать кнопкой или передать через командную строку для автоматизированной проверки.

Главное окно построено вокруг одного задания: указать счет, запустить анализ и сопоставить три итоговых сигнала. В верхней части находятся поле пути, кнопка с многоточием и крупная команда проверки; ниже расположены отдельные строки для PDF/A-3, XML и общей рекомендации. После завершения становятся доступны просмотр счета и полный отчет, поэтому путь от получения файла до разбора ошибки не требует перехода между несколькими утилитами.

Программа полезна прежде всего там, где обычного визуального просмотра PDF недостаточно. Она извлекает машинно читаемую часть гибридного счета, применяет правила схемы и Schematron, проверяет обязательные элементы, взаимосвязи сумм и профиль документа, а для ZUGFeRD дополнительно оценивает контейнер PDF/A-3. Результаты нужно читать раздельно: корректный XML не устраняет дефект PDF для долговременного хранения, а красивое отображение счета не доказывает соответствие EN 16931.

Проверка счета в главном окне

Рабочая последовательность начинается с вкладки E-Invoice Validator. В блоке выбора указаны два допустимых расширения — PDF и XML. Файл можно перетащить прямо на окно; второй способ — нажать кнопку с многоточием и выбрать документ в стандартном диалоге Windows. После появления полного пути активируется команда Validate the E-Invoice now!. Такой порядок важен: валидатор не сканирует папку сам и не пытается угадать нужный документ среди вложений письма, поэтому перед запуском следует сохранить именно полученный счет, а не сопроводительное письмо, изображение или распечатанную копию.

Если выбран PDF, программа рассматривает его как возможный гибридный счет ZUGFeRD или Factur-X: внутри должен находиться XML, связанный с PDF по правилам стандарта. Если выбран XML, проверяется структурированный счет XRechnung, CII или UBL без визуальной PDF-оболочки. В обоих случаях запуск выполняется одной кнопкой, но набор итогов различается: для чистого XML оценка PDF/A-3 неприменима, тогда как для гибридного PDF она является самостоятельной частью результата.

Во время передачи нижняя строка состояния показывает этап обработки. На официальном кадре видны сообщения о загрузке PDF и индикатор прогресса. Если полоса не двигается, не следует сразу считать счет ошибочным: сначала нужно проверить доступ к сети, разрешение межсетевого экрана и согласие на обработку во вкладке конфиденциальности. Формальные ошибки счета появляются только после завершения обмена и формирования результата.

Как читать три итоговых поля

Первая строка отвечает за PDF/A-3. Для гибридного электронного счета этот тест проверяет контейнер долговременного хранения, а не арифметику и не реквизиты XML. Красный результат означает, что PDF не удовлетворяет выбранному уровню PDF/A-3-B или PDF/A-3-U либо нарушает требования к структуре и вложениям. Такой файл может открываться в обычном просмотрщике и выглядеть безупречно, но его нельзя автоматически считать подходящим для долговременного хранения и нормативного обмена.

Вторая строка показывает результат XML-валидации. Здесь применяются схема и правила EN 16931 для распознанного сценария: обязательные поля, допустимые коды, связи между суммами, налоговые категории, идентификаторы профиля и другие машинно проверяемые ограничения. Зеленый статус означает, что проверенный XML прошел примененный набор правил. Красный статус требует открыть отчет: цвет сам по себе не сообщает, какое бизнес-правило нарушено и в каком узле находится проблема.

Третья строка — итоговая рекомендация. Она объединяет технические сигналы и формулирует, можно ли принять счет с точки зрения выполненной формальной проверки. На реальном кадре XML проходит проверку, PDF/A-3 получает отрицательный результат, а сводка предупреждает, что счет соответствует проверенным требованиям к XML, несмотря на дефект PDF. Это хороший пример того, почему нельзя сводить ответ программы к одному слову валиден или невалиден.

Цветовые полосы помогают быстро отсортировать документы, но решение о приеме должно опираться на текст отчета и правила вашей организации. Зеленый XML не подтверждает подлинность поставщика, факт поставки, правильность банковского счета или отсутствие мошенничества. Желтая или смешанная сводка требует понять, какое именно условие не выполнено и допускает ли ваш получатель такой документ.

Что проверяется по EN 16931

Валидатор выполняет больше, чем простую проверку XML на синтаксическую корректность. Сначала документ должен быть хорошо сформирован: теги закрыты, пространства имен определены, кодировка читается, структура соответствует схеме. Затем применяются Schematron-правила EN 16931 и национального или профильного сценария. Они проверяют не только наличие узлов, но и смысловые зависимости между ними — например, допустимость сочетаний налоговой категории и ставки, согласованность итогов, наличие обязательных идентификаторов и корректность кодов из справочников.

Для пользователя это означает, что файл может открываться в XML-редакторе и даже проходить XSD, но все равно получить failed. Типичная причина — логически несовместимые значения: сумма строк не сходится с итогом, налог рассчитан по другой базе, обязательное поле отсутствует для выбранного профиля, код валюты или единицы измерения не входит в допустимый перечень. Полный отчет нужен именно для этой второй ступени проверки.

Программа не заменяет содержательную бухгалтерскую проверку. Она не знает, действительно ли товар поставлен, верна ли цена по договору, принадлежит ли IBAN контрагенту и имеет ли подписант полномочия. EN 16931 описывает семантическую модель электронного счета, а валидатор устанавливает соответствие формализованным правилам. Поэтому после зеленого протокола остаются обычные процедуры контроля: сопоставление с заказом, договором, приемкой, справочником контрагентов и антифрод-политикой.

Поддерживаемые форматы и сценарии

Входными файлами служат PDF и XML. Для XML программа распознает сценарии XRechnung на синтаксисах UBL и CII, а также связанные профили Peppol BIS. Для гибридного PDF она извлекает XML ZUGFeRD или Factur-X и одновременно проверяет PDF/A-3. В официальном перечне совместимости указаны XRechnung 3.0.2, Factur-X 1.0.07 Extended, Peppol BIS 3.0.18 и допустимые семейства ZUGFeRD 2.1.x и 2.2.x. Поддержка конкретного нового расширенного профиля должна подтверждаться фактическим отчетом, а не только названием файла.

Сценарий определяется по служебным идентификаторам внутри XML. Переименование обычного PDF в zugferd.pdf или XML в xrechnung.xml ничего не меняет. Если идентификатор спецификации отсутствует, устарел или не совпадает со структурой, отчет может сообщить, что подходящий сценарий проверки не найден. Исправлять в таком случае следует генератор счета либо исходные данные экспорта, а не имя файла.

Старые профили могут сознательно отклоняться. Это важно при проверке старых документов: документ, который считался допустимым в прежнем обмене, не обязательно пройдет набор правил, ориентированный на действующие налоговые и технические требования. При повторной проверке старого счета нужно отделять историческую действительность документа на дату выставления от совместимости с выбранным современным сценарием.

Вход	Что анализируется	Что смотреть в результате
PDF/ZUGFeRD	PDF/A-3, вложенный XML, EN 16931	Обе строки и сводку
XML/XRechnung UBL	Схема UBL и правила профиля	XML-отчет и сценарий
XML/XRechnung CII	UN/CEFACT CII и Schematron	Ошибки узлов и правил
Peppol BIS	Профиль и бизнес-правила BIS	Идентификаторы и коды

Проверка PDF/ZUGFeRD по шагам

Выбор правильного PDF

Для проверки нужно брать исходный электронный файл, полученный от системы выставления счетов. Скан бумажного документа, распечатанный и заново отсканированный счет, а также PDF, созданный функцией Печать в PDF из обычного просмотра, обычно не содержат структурированного XML. Валидатор может проверить только те данные, которые реально встроены в контейнер.

Извлечение вложенного XML

Наличие вложения, видимого в Adobe Acrobat Reader, еще не гарантирует корректную интеграцию. Для соответствующего сценария XML должен быть связан с документом через AFRelationship со значением Alternative и иметь подходящее описание. Если эти атрибуты отсутствуют, файл может отображаться в панели вложений, но валидатор не признает его нормативно встроенной машинно читаемой частью счета. В таком случае дальнейший отчет может не создаться, потому что программа не нашла корректный объект для проверки.

Раздельное исправление контейнера и данных

Если XML зеленый, а PDF/A-3 красный, не следует менять налоговые поля только ради получения общего зеленого результата. Нужно исправить способ формирования PDF/A-3: встроенные шрифты, метаданные, цветовые профили, структуру вложения или другие требования, перечисленные в отчете. Если PDF/A-3 проходит, а XML нет, проблема находится в электронных реквизитах или правилах профиля. Раздельные индикаторы позволяют направить задачу правильному специалисту — разработчику генератора PDF либо владельцу данных счета.

Проверка XML/XRechnung

Чистый XML выбирается тем же полем, что и PDF. Для XRechnung важно сохранить исходную кодировку и не редактировать документ в текстовом процессоре, который может заменить кавычки, добавить служебные символы или изменить переносы в значениях. Если счет пришел в ZIP-пакете или системе электронного документооборота, сначала извлеките именно XML-файл, а не HTML-представление и не печатную форму.

После запуска программа определяет синтаксис UBL или CII и ищет подходящий сценарий. Ошибка до появления бизнес-правил обычно означает, что XML плохо сформирован, пространство имен не соответствует ожидаемому или корневой элемент не распознан. Ошибки после выбора сценария относятся к схеме и Schematron. В отчете полезно сначала найти наиболее раннюю структурную ошибку: один неверный узел может вызвать десятки вторичных сообщений ниже по дереву.

При проверке XRechnung особенно важны идентификатор спецификации, профиль процесса, данные продавца и покупателя, номер и дата счета, валюта, сроки оплаты, налоговые сведения, суммы строк и итоговые суммы. Программа не предлагает форму для ручного заполнения этих полей; исправления вносятся в исходной учетной системе или генераторе XML, после чего файл экспортируется заново и повторно проверяется.

Встроенный просмотрщик счета

Кнопка Open E-Invoice in Viewer появляется в рабочем блоке рядом с доступом к отчету. Она нужна для визуальной сверки машинных данных без чтения XML-тегов. Просмотрщик показывает структурированное представление реквизитов, сумм, налоговых ставок, продавца и получателя. Это особенно полезно для чистой XRechnung, у которой нет привычной страницы PDF.

Человекочитаемое представление не является отдельной копией счета и не исправляет исходный XML. Если в просмотрщике поле выглядит пустым, нужно проверить отчет и исходный узел. Если данные отображаются убедительно, но XML получил failed, приоритет имеет формальная проверка: визуализация может показать значение, которое нарушает кодовый список, точность или правило взаимосвязи.

Флажок автоматического открытия позволяет сразу переходить к представлению после успешного запуска. Его удобно включать при ручной приемке небольшого числа счетов, когда оператор каждый раз сопоставляет поставщика, номер, дату, валюту и итог. Для массового процесса автоматическое окно мешает; там лучше использовать CLI, коды возврата и сохранение отчета.

Подробный отчет и поиск причины ошибки

Команда Show the validation report открывает полный протокол. В нем нужно различать уровень ошибки, идентификатор правила и путь к проблемному элементу. Сообщение XSD обычно указывает на недопустимый элемент, атрибут или тип значения. Schematron-сообщение с кодом бизнес-правила описывает условие, которое не выполнено. Практический порядок разбора: определить сценарий, найти первую критическую ошибку, сопоставить путь с исходным XML, исправить систему формирования данных и повторить проверку.

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

Флажок автоматического открытия отчета полезен во время настройки генератора. При стабильной эксплуатации его можно отключить, чтобы оператор сначала видел сводные цвета, а отчет открывал только для красных и смешанных результатов. В автоматизированном режиме параметр -report сохраняет HTML-отчет в заданный каталог без ручного нажатия.

Типовые сообщения и способы исправления

Нет подходящего сценария проверки

Сообщение о том, что действительный сценарий не найден, означает не просто неизвестный XML. Проверьте идентификатор спецификации, синтаксис UBL/CII, версию профиля и соответствие корневого элемента заявленному стандарту. Для гибридного PDF дополнительно проверьте, правильно ли встроен XML и распознается ли связь Alternative. Если счет создан старой учетной системой, надежнее обновить модуль экспорта, чем вручную подменять идентификатор.

Отчет не создается, хотя XML виден во вложениях

Откройте свойства вложения в инструменте, который умеет показывать структуру PDF. Для ZUGFeRD важны не только имя factur-x.xml или zugferd-invoice.xml, но и ассоциация AFRelationship, описание и корректная PDF/A-3-структура. Простое прикрепление файла к обычному PDF не превращает документ в гибридный электронный счет.

Не сходятся суммы

Сопоставьте сумму строк до налогов, скидки и надбавки, налоговую базу, налог по категориям, округление и итог к оплате. Исправление должно происходить в системе, которая рассчитывает счет. Ручное изменение одной итоговой цифры в XML может устранить конкретное правило, но создать несогласованность с печатной формой или учетной записью.

Неизвестный код

Проверьте валюту, страну, единицу измерения, налоговую категорию, тип платежного средства и идентификаторы схем. Валидатор применяет кодовые списки, поэтому понятное человеку сокращение не всегда допустимо. Используйте значение, которое формирует поддерживаемый экспортный модуль, и не переводите коды на русский или немецкий язык.

Красный PDF/A-3 при зеленом XML

Передайте отчет специалисту, отвечающему за PDF-генерацию. Возможны проблемы со шрифтами, метаданными, цветовыми профилями, уровнем PDF/A или способом вложения XML. Содержимое счета при этом может быть формально правильным; менять реквизиты не требуется, если XML-проверка не сообщает ошибок.

Вкладка конфиденциальности и передача файла

Проверка выполняется после передачи выбранного счета в сервис 7-PDF. На вкладке Privacy Policy находится флажок согласия, без которого отправка и обработка не должны запускаться. Текст интерфейса сообщает о шифрованной передаче SSL, обработке в течение проверки и удалении данных после завершения. Перед использованием в организации следует сопоставить этот процесс с внутренними правилами работы с персональными данными, коммерческой тайной и бухгалтерскими документами.

Сервис размещается в Германии и применяется для компонентов проверки, которые не устанавливаются вместе с клиентской частью. Поэтому доступ в интернет нужен не только для покупки или активации, но и для самой валидации. Изолированный компьютер без выхода в сеть сможет открыть интерфейс, однако не получит содержательный результат. Для закрытых контуров это принципиальное ограничение, которое нужно проверить до внедрения.

Удаление после обработки не отменяет необходимости провести оценку рисков. Счет содержит названия организаций, адреса, налоговые номера, банковские реквизиты, позиции поставки и суммы. Если политика запрещает передачу таких данных внешнему обработчику, следует выбрать решение, которое выполняет проверку внутри контролируемой инфраструктуры, например развертываемый валидатор с локальными правилами.

Сетевые ошибки, прокси и межсетевой экран

Если после запуска остается сообщение о загрузке, сначала проверьте обычный HTTPS-доступ с того же компьютера. Корпоративный прокси может требовать аутентификацию, подменять сертификаты или запрещать неизвестные домены. В таком случае интерфейс работает, но запрос к сервису не завершается. Разрешение должно быть выдано именно исполняемому файлу валидатора и адресу сервиса, а не только браузеру пользователя.

При ошибке TLS проверьте системные дату и время, доверенные корневые сертификаты и правила инспекции трафика. Не отключайте проверку сертификата ради одного счета: это лишает шифрованный канал защиты. Если антивирус помещает процесс в песочницу, добавляйте исключение только после проверки происхождения установщика и политики организации.

Повторный запуск имеет смысл после устранения сетевой причины. Не отправляйте один и тот же конфиденциальный документ десятки раз без необходимости. Для диагностики CLI используйте -logfile: код возврата 2 означает ошибку выполнения и требует чтения журнала, а не исправления XML наугад.

Командная строка 7-PDF E-Invoice Validator

Исполняемый файл для автоматизации называется SevenPDFValidator.exe. Обязательный параметр -mode принимает gui, console или hidden. Параметр -infile задает путь к PDF либо XML. Необязательный -logfile сохраняет текстовую диагностику, а -report указывает каталог для HTML-отчета. Пути с пробелами нужно заключать в двойные кавычки.

SevenPDFValidator.exe -mode "console" -infile "C:\Invoices\invoice.xml" -logfile "C:\Invoices\logs\invoice.txt" -report "C:\Invoices\reports"

Режим console показывает ход работы в окне терминала и удобен для первичной настройки. hidden не открывает графическое окно и подходит для задания планировщика или сценария обработки, но журнал и каталог отчета становятся особенно важными: без них оператор увидит только код завершения. gui сохраняет обычный интерфейс и полезен, когда команда запускается из контекстного меню или внешней учетной системы, а решение принимает человек.

Официальные коды возврата: 0 — счет прошел проверку; 1 — счет не прошел; 2 — ошибка выполнения; 3 — требуется лицензия. Скрипт должен обрабатывать каждый код отдельно. Нельзя объединять 1 и 2 в одно состояние плохой счет: при коде 1 нужно анализировать документ, при коде 2 — инфраструктуру и журнал, при коде 3 — условия использования.

Автоматизация одиночных и пакетных проверок

Программа принимает один входной путь за один запуск. Пакетная обработка строится внешним циклом: сценарий перечисляет PDF и XML в папке, для каждого вызывает валидатор, сохраняет отдельный лог и отчет, затем перемещает файл в каталог пройдено, ошибка документа или ошибка процесса. Такая схема прозрачнее, чем один общий журнал: имя результата можно связать с исходным счетом и повторить только неудачные операции.

Для имен отчетов используйте безопасный идентификатор, а не только исходное имя. Два поставщика могут прислать invoice.xml, и второй отчет перезапишет первый. Практичный шаблон включает дату приема, внутренний номер задания и хеш либо уникальный индекс. Исходный файл после проверки лучше не переименовывать до регистрации в системе документооборота, чтобы сохранить доказуемую связь с полученным объектом.

Автоматический процесс должен иметь тайм-аут и ограничение повторов. Сетевой сбой не должен приводить к бесконечной отправке одного счета, а код 1 не следует повторять без изменения документа или правил. После серии кодов 2 разумно остановить очередь и уведомить администратора: массовое продолжение создаст одинаковые бесполезные журналы и задержит обработку.

Лицензионные условия ограничивают сценарии интеграции. Командная строка предназначена для внутренних процессов обладателя лицензии; использование в портале, SaaS, управляемом сервисе или стороннем продукте требует отдельного согласования и может не допускаться обычной лицензией. Перед подключением к ERP нужно проверить не только технический вызов, но и разрешенный способ эксплуатации.

Журналы, HTML-отчеты и коды завершения

-logfile и -report решают разные задачи. Журнал фиксирует ход запуска и технические сообщения, поэтому помогает при коде 2, сетевой проблеме или неверном пути. HTML-отчет содержит результат проверки документа и правила, поэтому нужен при коде 1 и для аудита успешной проверки. Хранить только один из этих файлов недостаточно для воспроизводимой диагностики.

Каталоги следует создать заранее и выдать учетной записи процесса права на запись. Если входной счет доступен, но отчетный каталог защищен, проверка может завершиться ошибкой выполнения. В планировщике Windows процесс часто запускается под другой учетной записью, чем при ручном тесте; проверяйте доступ именно в этом контексте, включая сетевые диски и UNC-пути.

После успешного выполнения свяжите код 0 с конкретным отчетом. Отсутствие файла отчета при коде 0 может быть нормальным, если -report не задан, но для контролируемого процесса это слабая доказательная база. Лучше всегда сохранять отчет, дату, версию набора правил из протокола и идентификатор исходного файла.

Пробный лимит и активация

Пробный режим разрешает десять проверок. Счетчик виден внизу окна; каждый запуск валидации уменьшает остаток. Поэтому тестовый план лучше подготовить заранее: взять корректный ZUGFeRD, корректную XRechnung, документ с ошибкой XML, документ с дефектом PDF/A-3 и пример неподдерживаемого сценария. Бессистемное повторение одного файла быстро исчерпает лимит и не покажет, подходит ли программа реальному потоку.

Вкладка Register/Infos показывает состояние лицензии и кнопку ввода ключа. Активация выполняется через интернет. Если ключ принят, ограничение проверок снимается в рамках лицензированных пользователей. При ошибке активации проверьте сеть и межсетевой экран, затем точность вставки ключа; не редактируйте реестр вручную обычным ключом, если поддержка не предоставила специальный ключ для развертывания.

Код возврата 3 в CLI прямо указывает на лицензионное ограничение. Автоматический процесс должен остановиться и сообщить администратору, а не классифицировать входные счета как невалидные. При массовом развертывании учитывается модель Named User: наличие одного ключа не означает неограниченное использование всеми сотрудниками или внешними клиентами.

Развертывание в организации

Установщик поддерживает параметры /SILENT и /VERYSILENT. Первый уменьшает число диалогов, второй выполняет установку максимально скрыто. Перед централизованным развертыванием нужно испытать команду на тестовой машине, проверить каталог установки, ярлыки, правила межсетевого экрана и запуск CLI под учетной записью службы. Тихая установка не означает готовность сервиса проверки: согласие на передачу и сетевые политики остаются отдельными условиями.

Для автоматического распределения лицензии производитель описывает специальный ключ и ветвь реестра HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\7-PDF\Validator\RegCode. Обычный приобретенный ключ не предназначен для простого размещения в реестре в открытом виде. Для Citrix, терминальных серверов и большого числа ПК требуется согласованный специальный ключ; в небольшом окружении приложение можно запускать от администратора и вводить лицензию вручную на каждом сервере.

После установки проведите приемочный тест от имени обычного пользователя: открыть интерфейс, включить необходимое согласие, проверить PDF и XML, открыть просмотрщик и отчет, затем выполнить тот же файл через CLI. Такой тест обнаруживает различия прав, прокси и профиля пользователя, которые не видны при запуске администратором.

Совместимость и рабочее окружение

Для запуска заявлены Windows 10, Windows 11 и Windows Server 2016, 2019, 2022 и 2025. В списке нет macOS и Linux. На серверных системах особенно важны права записи для логов, интерактивные ограничения сеанса и политика доступа в интернет. Если проверка запускается на терминальном сервере, пользовательская лицензия и способ активации должны соответствовать фактическому числу пользователей.

Дополнительный Java-компонент на рабочем месте не требуется: правила и связанные компоненты выполняются сервисом. Это снижает число зависимостей, но делает сетевую доступность обязательной. В виртуальной среде следует проверить, не блокирует ли прокси исходящие запросы процесса и сохраняется ли согласие в профиле каждого пользователя.

Архитектура установщика на официальной странице отдельно не указана. Путь WOW6432Node в документации развертывания показывает использование 32-битной ветви реестра на 64-битной Windows, однако это не следует превращать в предположение о поддержке неподтвержденных платформ. Для контролируемого каталога корректнее помечать архитектуру как неизвестную до анализа бинарного файла.

Что валидатор не исправляет

Программа сообщает о несоответствиях, но не является редактором XRechnung или ZUGFeRD. В главном окне нет полей для изменения продавца, покупателя, строк, НДС и итогов. Кнопка просмотра не сохраняет исправленный документ, а отчет не применяет автоматические патчи. Исправление выполняется в учетной системе, генераторе электронных счетов или специализированном редакторе, после чего создается новый файл.

Она также не подписывает счет, не проверяет электронную подпись как доказательство личности и не подтверждает полномочия отправителя. Проверка банковских реквизитов на принадлежность, поиск дубликата счета в вашей бухгалтерии, сопоставление с заказом и контроль поставки находятся вне формальной EN 16931-валидации.

Отдельный риск — расхождение визуальной страницы PDF и встроенного XML. Просмотрщик помогает заметить часть расхождений, но ответственность за содержательную сверку остается у человека или учетной системы. Платежные решения должны использовать структурированные данные только после проверки поставщика, суммы, валюты, налогов и реквизитов по внутренним учетным данным.

Рабочий процесс для входящих счетов

1. Сохраните исходный PDF или XML без пересоздания и переименования расширения.
2. Зарегистрируйте дату получения и канал получения сообщения.
3. Запустите проверку и сохраните полный отчет.
4. При красном статусе отделите ошибку документа от ошибки выполнения.
5. Откройте человекочитаемое представление и сверьте ключевые реквизиты.
6. Сопоставьте счет с договором, заказом и приемкой.
7. Только после этого передавайте данные в бухгалтерский и платежный процесс.

Такой порядок предотвращает две распространенные ошибки. Первая — отказ от корректного XML из-за отдельного дефекта PDF/A-3 без анализа политики получателя. Вторая — автоматическое принятие зеленого XML без проверки поставщика и экономического содержания. Программа дает формальный технический сигнал, а организация добавляет собственные контрольные процедуры.

Для повторного файла сохраняйте хеш исходного объекта или другой надежный идентификатор. Имя invoice.pdf не позволяет доказать, что отчет относится к конкретному вложению. Если поставщик прислал исправленную версию, регистрируйте ее как новый объект и не перезаписывайте предыдущий отчет.

Рабочий процесс перед отправкой счета

Проверку лучше выполнять после окончательного экспорта, а не на промежуточном XML. Для ZUGFeRD нужен именно финальный PDF/A-3 с уже встроенным XML: последующая оптимизация, печать в другой PDF или добавление вложения может нарушить контейнер. Для XRechnung проверяется файл, который будет отправлен получателю, с окончательными идентификаторами и суммами.

Если отчет содержит ошибки обязательных полей, исправьте мастер-данные и шаблон экспорта. Ручная правка одного счета может помочь в срочном случае, но не устраняет причину. Повторяющаяся ошибка маршрутизации, налогового номера или округления должна быть исправлена в ERP, чтобы следующие документы формировались правильно.

После зеленого результата выполните визуальную сверку с учетными данными: номер, дата, продавец, покупатель, валюта, строки, НДС, итог и платежные реквизиты. Сохраните отчет вместе с отправленной копией. Если получатель затем отклонит счет, у вас будет исходный файл и протокол, позволяющие сравнить примененные правила и требования принимающей системы.

PDF/A-3 и долговременное хранение

PDF/A-3 допускает вложение файлов внутрь PDF, поэтому используется для гибридных счетов: человек видит страницу, система читает XML. Но само наличие XML не делает обычный PDF соответствующим PDF/A-3. Валидатор отдельно проверяет контейнер и показывает уровни PDF/A-3-B или PDF/A-3-U, заявленные производителем.

Для долговременного хранения важен исходный файл, а не скриншот отчета или распечатка. Сохраняйте PDF/ZUGFeRD без повторного сохранения просмотрщиком, потому что некоторые операции меняют метаданные или структуру вложений. HTML-отчет храните как сопроводительное доказательство проверки, но не как замену счету.

Если требуется глубокий разбор конкретного дефекта PDF/A, официальный материал рекомендует специализированный veraPDF. 7-PDF E-Invoice Validator удобен тем, что показывает общий сигнал рядом с XML-валидацией, однако детальный стандартный профиль PDF/A может потребовать отдельного отчета veraPDF для специалиста по генерации документов.

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

Поле пути в верхнем блоке выполняет не только роль подписи выбранного файла. По нему удобно сразу обнаружить две причины неудачного запуска: случайно выбранную копию из временной папки и путь, содержащий имя другого счета. Перед нажатием основной команды сравните имя с номером документа в письме или системе документооборота. Валидатор обрабатывает ровно тот объект, который указан в поле, поэтому сохраненный рядом исправленный вариант не подменяет ранее выбранный файл автоматически.

Кнопка с многоточием открывает системный выбор файла и снижает риск ошибки при длинном пути. Перетаскивание быстрее, когда счет уже виден в Проводнике, но у него есть практическое ограничение: пользователь может схватить ярлык, ZIP-пакет или вложение с похожим названием. После перетаскивания проверьте расширение в поле. Интерфейс рассчитан на PDF и XML; ZIP из почтового шлюза сначала нужно распаковать, а контейнер ASiC или иной транспортный пакет — извлечь средствами системы, которая его приняла.

Основная кнопка проверки запускает передачу и анализ, а нижняя строка состояния отделяет ожидание сервиса от сформированного результата. Пока отображается загрузка или обработка, кнопки просмотра и отчета могут оставаться недоступными. Повторное нажатие в этот момент не помогает и способно создать путаницу в журнале действий. При длительном ожидании зафиксируйте время, имя файла и сетевые условия, затем проверьте соединение; не делайте вывод о валидности документа до появления трех итоговых областей.

Флажки автоматического открытия просмотра и отчета следует настраивать под роль пользователя. Бухгалтеру, который вручную сверяет несколько счетов, удобно сразу видеть представление данных. Специалисту по интеграции полезнее автоматически открывать отчет, поскольку его интересуют коды правил и пути XML. На рабочем месте приемки с большим потоком оба флажка лучше отключить: оператор сначала классифицирует цветовой результат, а подробное окно открывает только для документов, требующих разбирательства.

Последовательность проверки внутри одного запуска

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

Для PDF затем определяется, содержит ли контейнер электронный счет и можно ли корректно извлечь машинную часть. Здесь проверяются связь вложения, его описание и структура PDF/A-3. Если XML физически присутствует, но не обозначен как альтернативное представление документа, дальнейший анализ может не получить ожидаемый сценарий. Поэтому проблема вложение видно, но валидатор его не принимает решается в генераторе PDF, а не переименованием attachment после экспорта.

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

Только после выбора сценария имеет смысл разбирать XSD и Schematron. XSD выявляет структурные нарушения: неожиданный элемент, неверный порядок, неподходящий тип значения. Schematron проверяет бизнес-условия, которые невозможно выразить одной схемой: взаимосвязь сумм, обязательность поля при определенной категории, допустимое сочетание кодов. В итоговой сводке эти уровни объединяются, но в рабочем журнале их лучше отмечать отдельно, поскольку исправляют их разные специалисты.

Разбор XML-отчета без чтения всего файла

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

Путь XML в сообщении следует читать как адрес проблемного значения. В UBL названия узлов и вложенность отличаются от CII, поэтому копировать исправление из примера другого синтаксиса опасно. Валидатор сообщает о фактической структуре загруженного документа; разработчику нужно передать именно этот путь, полный код правила и сам файл, а не пересказ не проходит XRechnung. Такой комплект позволяет воспроизвести ошибку без догадок.

Серьезность сообщения не следует определять только по длине текста. Короткое требование об обязательном идентификаторе может блокировать прием полностью, тогда как длинное предупреждение описывает рекомендацию или дополнительную совместимость. Ориентируйтесь на классификацию в отчете и итог проверки. Если организация различает ошибки и предупреждения собственными правилами, не меняйте вывод валидатора: сохраните исходный статус и добавьте отдельное внутреннее решение.

После исправления запускайте анализ нового экспортированного файла и сравнивайте отчеты. Не редактируйте сохраненный HTML-протокол и не считайте исчезновение одного сообщения достаточным, если появились другие. Надежный цикл состоит из четырех объектов: исходный проблемный счет, его отчет, заново сформированный счет и новый отчет. Имена должны позволять однозначно связать пары, например по номеру документа, времени экспорта и контрольной сумме.

Обязательные реквизиты и идентификаторы

При красном результате сначала проверяют идентификационные поля счета: номер, дату выпуска, тип документа, валюту и ссылку на применяемую спецификацию. Эти значения определяют базовый контекст последующих правил. Пустой номер или дата в неверном формате обычно требует исправления в учетной системе. Ручная вставка текста в XML может нарушить схему, кодировку или подпись транспортного пакета, поэтому валидатор должен проверять повторный штатный экспорт.

Данные продавца и покупателя проверяются как структурированные участники, а не как строка на визуальной странице. Наименование, адрес, страна, налоговые и регистрационные идентификаторы могут иметь разную обязательность в зависимости от профиля. Если в просмотрщике реквизит виден, но отчет указывает на отсутствующий обязательный узел, возможно, PDF-страница и XML сформированы разными подсистемами либо значение помещено в неподходящее поле.

Идентификатор покупателя, reference заказчика или routing ID особенно важен в автоматическом обмене. Получатель использует его для маршрутизации счета в подразделение или систему. Валидатор проверяет формальные требования примененного сценария, но не может знать, принадлежит ли код конкретному отделу вашей организации. После зеленого результата все равно сопоставьте этот идентификатор с договором, заказом или инструкцией получателя.

Платежные сведения нужно оценивать в двух плоскостях. Отчет выявляет структурные требования и допустимость кодов, а внутренний контроль подтверждает банковский счет и владельца. Зеленый IBAN в XML означает лишь прохождение применимых формальных правил, но не защищает от подмены реквизитов. Поэтому просмотрщик удобен для быстрой сверки, однако разрешение на платеж должно опираться на доверенный справочник контрагента и процедуру подтверждения изменений.

Строки счета, единицы и количества

Каждая строка связывает описание предмета расчета, количество, единицу измерения, цену и итог строки. Ошибка в одном значении способна повлиять на документные суммы и налоговую базу. Если отчет указывает на недопустимый код единицы, не заменяйте его произвольным сокращением из печатной формы. Электронный счет использует кодовый список; генератор должен передавать допустимое машинное значение, даже если пользователю показывается привычное шт. или ч.

Количество и цена должны иметь формат, ожидаемый схемой, и согласованную точность. Разделитель тысяч, символ валюты и локальная запятая относятся к визуальному представлению, а XML хранит числовые значения по техническим правилам. Вставка 1 234,50 € вместо числового значения приводит к структурной ошибке. Исправление выполняют в преобразовании данных, сохраняя форматированную строку только для PDF или пользовательского интерфейса.

Скидка или надбавка на строке должна быть связана с базой и причиной, если это требует выбранный профиль. Простое уменьшение итога без передачи составляющих может нарушить бизнес-правило, даже когда арифметика на бумаге кажется правильной. В отчете ищите сообщения рядом с allowance, charge, base amount и reason. Затем сопоставьте их с тем, как ERP рассчитывает скидку: процентом, фиксированной суммой или измененной ценой.

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

НДС, категории и расчет итогов

Налоговая проверка опирается на категорию, ставку, базу и сумму налога. Нулевая ставка, освобождение и операция вне объекта налогообложения — не взаимозаменяемые варианты. Если генератор передает нулевое число при категории, требующей объяснения освобождения, Schematron может выдать ошибку. Исправлять нужно код категории и связанные поля в соответствии с хозяйственной операцией, а не только менять процент.

Итог по каждой налоговой категории должен согласовываться со строками, скидками и надбавками, отнесенными к этой категории. Распространенная причина расхождения — документная скидка распределена в PDF, но не отражена в XML или отнесена к другому налоговому режиму. Отчет показывает формальное несоответствие; для поиска причины полезно пересчитать базу отдельно по каждой категории, а затем сравнить с агрегированным узлом.

Округление нужно выполнять последовательно на том уровне, который использует генератор. Если ERP округляет налог на каждой строке, а XML-агрегатор пересчитывает его от общей базы, разница в один цент может нарушить равенство. Не следует просто подменять итог к оплате. Сначала определите, где возникает разница: в цене, строке, базе, налоге, скидке или специальном поле округления. После изменения повторно сформируйте и PDF, и XML из одной версии данных.

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

Диагностика смешанных результатов PDF и XML

PDF/A-3	XML	Практическое действие
Пройден	Пройден	Сверить содержание, контрагента и платежные реквизиты; сохранить исходный файл и отчет.
Не пройден	Пройден	Исправлять контейнер PDF/A-3 и способ встраивания, не меняя корректные бизнес-данные без отдельной причины.
Пройден	Не пройден	Исправлять XML, профиль и бизнес-правила; корректный контейнер не компенсирует неверные данные.
Не пройден	Не пройден	Разделить дефекты на две задачи и после каждой правки повторно проверять финальный гибридный файл.
Нет результата	Нет результата	Проверить сеть, согласие, путь, права, доступность сервиса и лицензию до анализа счета.

Сочетание зеленого XML и красного PDF встречается, когда данные счета корректны, но оболочка PDF/A-3 сформирована с нарушением. В таком случае отправка одного извлеченного XML может быть допустима только в процессе, который принимает чистую XRechnung; для обмена ZUGFeRD нужен исправленный гибридный документ. Решение зависит от канала и требований получателя, а валидатор дает необходимые раздельные сигналы.

Красный XML при зеленом PDF означает обратное: контейнер технически аккуратен, но содержание не соответствует правилам. Нельзя принимать такой счет только потому, что он открывается и проходит PDF/A. Откройте HTML-отчет, найдите первую корневую ошибку и верните поставщику конкретный код правила. После получения исправления проверяйте новый файл, а не замененный XML внутри старого PDF вручную.

Если оба слоя красные, удобнее завести две категории дефектов. Разработчик генератора PDF исправляет профиль PDF/A-3 и связь вложения; специалист по ERP или формату исправляет значения XML. Однако финальная проверка всегда выполняется на одном заново экспортированном PDF, поскольку повторное встраивание XML может снова повлиять на PDF/A-структуру.

Сценарий подходящая конфигурация не найдена

Это сообщение следует рассматривать как отдельный класс, а не как обычную ошибку обязательного поля. Без выбранного сценария программа не может надежно применить полный набор национальных и профильных правил. Сначала определите, что загружено: чистый UBL, CII, гибридный PDF или файл другого назначения. Затем проверьте служебные идентификаторы спецификации и процесса в XML.

У старого счета причиной может быть профиль, который больше не входит в поддерживаемый набор. Для проверки старого документа это не доказывает, что документ был недействителен в момент обмена. Сохраните его исходный контекст и, если нужна историческая оценка, используйте правила соответствующего периода. Для нового обмена такой результат означает, что генератор должен быть настроен на требуемый получателем сценарий.

В гибридном PDF тот же текст может быть следствием неправильного встраивания. Прежде чем править идентификатор XML, убедитесь, что валидатор извлек именно нужное вложение. Несколько XML-файлов, нестандартное имя, отсутствующая связь Alternative или ошибочное описание создают неоднозначность. Генератор должен формировать контейнер предсказуемо; ручное удаление лишних вложений в обычном PDF-редакторе может нарушить PDF/A.

После исправления ожидайте не обязательно зеленый результат, а переход к содержательным правилам. Появление конкретных XSD или Schematron-сообщений означает, что сценарий наконец распознан. Устраняйте их последовательно. Не меняйте одновременно профиль и десятки бизнес-полей: иначе будет сложно понять, какое действие действительно восстановило совместимость.

Проверка PDF/A-3 по категориям дефектов

Красный статус PDF/A-3 может относиться к шрифтам, метаданным, цветовым пространствам, запрещенным объектам, ассоциации вложения или другим требованиям профиля PDF/A-3. Главное окно намеренно показывает общий итог рядом с XML, а подробности следует брать из отчета и при необходимости из специализированного PDF/A-анализатора. Не пытайтесь угадывать причину по внешнему виду страницы: большинство таких нарушений визуально незаметно.

Если проблема относится к шрифтам, повторная печать через виртуальный принтер не является надежным исправлением. Она может встроить гарнитуры, но одновременно удалить XML, изменить метаданные и разрушить гибридную структуру. Правильный путь — исправить настройки экспортера, который формирует PDF/A-3 и прикрепляет XML в одном контролируемом процессе, после чего заново проверить финальный объект.

При ошибке метаданных сравните заявленный уровень соответствия с фактическим содержимым. Название профиля в свойствах файла само по себе ничего не доказывает. При ошибке вложения проверьте имя, MIME-тип, описание и AFRelationship. Эти параметры относятся к структуре PDF и должны задаваться библиотекой генерации; изменение только визуальной страницы не влияет на них.

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

Командная строка в контролируемом процессе

Исполняемый файл SevenPDFValidator.exe принимает режим запуска и входной документ. Для фоновой интеграции используйте console или hidden в соответствии с тем, нужен ли видимый консольный вывод. Обязательным остается путь после -infile. Параметр -logfile направляет технический журнал в отдельный файл, а -report задает каталог для HTML-отчета. Путь с пробелами нужно заключать в кавычки.

SevenPDFValidator.exe -mode console -infile "C:\Invoices\incoming\INV-1042.xml" -logfile "C:\Invoices\logs\INV-1042.log" -report "C:\\Invoices\\reports"

Один вызов должен обрабатывать один счет. Пакетность организует внешний сценарий, который перечисляет файлы и запускает валидатор последовательно. Для каждого объекта создавайте уникальное имя журнала; общий перезаписываемый log лишает возможности связать ошибку с конкретным документом. Каталог отчетов также следует разделять по дате, поставщику или идентификатору задания.

Код 0 означает, что счет прошел проверку; код 1 — что анализ завершен, но документ не соответствует правилам; код 2 — ошибка выполнения; код 3 — необходимость лицензии. Автоматизация обязана обрабатывать все четыре варианта. Нельзя отправлять и код 1, и код 2 в одну папку ошибочные счета: в первом случае поставщику нужен отчет о документе, во втором сначала чинят инфраструктуру и повторяют тот же файл.

В hidden-режиме отсутствие окна повышает требования к журналированию. Записывайте начало и конец задания, полный путь, код процесса и наличие HTML-отчета. Если процесс вернул 0, но ожидаемый отчет не найден, пометьте запуск как технически неполный и проверьте права каталога. Если код 1 пришел без отчета, не составляйте причину вручную: сохраните log и повторите после устранения проблемы записи.

Пакетная обработка без потери документов

Входную папку лучше разделить на состояния: new, processing, valid, invalid и technical-error. Сценарий сначала атомарно перемещает файл из new в processing, затем запускает проверку. Код 0 отправляет объект и отчет в valid, код 1 — в invalid, а коды 2 и 3 — в technical-error. Такая схема предотвращает повторный запуск одного и того же счета параллельными заданиями.

Имя файла не должно быть единственным идентификатором. Два поставщика могут прислать invoice.xml, а исправленный счет — сохранить прежнее имя. Рассчитайте SHA-256 во внешнем процессе и храните его рядом с кодом возврата, временем и путем к отчету. Валидатор не создает такой реестр сам, но его однозначные коды и файлы отчета удобно включать в журнал обработки.

Повтор для технической ошибки должен быть ограничен. Бесконечный цикл при недоступном сервисе расходует ресурсы и усложняет аудит. После нескольких попыток переместите счет в technical-error и создайте уведомление. Код 1 повторять автоматически бессмысленно: содержимое документа не изменится, поэтому нужен исправленный файл или решение ответственного сотрудника.

При обслуживании нескольких организаций не смешивайте каталоги отчетов и учетные данные. В HTML могут присутствовать реквизиты счета, поэтому права доступа должны соответствовать исходному документу. Временные копии после передачи также нужно удалять по внутренней политике. Факт удаления на стороне сервиса не отменяет контроля локальных папок, резервных копий и систем мониторинга.

Матрица кодов завершения и действий

Код	Смысл	Следующий шаг
0	Формальная проверка пройдена	Выполнить содержательную сверку и сохранить отчет вместе с исходным счетом.
1	Счет не прошел правила	Открыть HTML-отчет, классифицировать корневую ошибку и запросить или сформировать исправление.
2	Ошибка выполнения	Проверить путь, права, сеть, прокси, согласие, сервис и запись журналов; затем повторить тот же файл.
3	Требуется лицензия	Проверить активацию и назначение лицензии; не считать документ невалидным.

Код процесса отражает результат запуска, но не заменяет файлы доказательств. Для кода 0 храните отчет, чтобы знать, какой набор правил применился. Для кода 1 отчет обязателен для исправления. Для кода 2 главным становится технический log. Для кода 3 сохраняйте сообщение лицензирования отдельно от очереди документов, чтобы после восстановления разрешения повторно обработать все отложенные счета.

В графическом режиме эти категории распознаются по наличию результата и тексту состояния. Красный XML при сформированном отчете соответствует завершенной проверке невалидного документа. Окно, остановившееся до итогов, относится к технической диагностике. Такая граница защищает поставщика от ошибочного отказа, когда на самом деле недоступна сеть вашей организации.

Проверка конфиденциальности перед первым счетом

На вкладке конфиденциальности пользователь подтверждает передачу файла сервису проверки. Без этого согласия рабочий процесс не должен считаться настроенным. До загрузки реальных документов изучите, какие категории данных содержатся в счетах: имена, адреса, налоговые номера, банковские реквизиты, позиции поставки и договорные ссылки. Решение о допустимости передачи принимает организация, а не цвет результата валидатора.

Производитель указывает защищенное соединение, обработку в Германии и удаление после проверки. Эти меры относятся к сервисной стороне. На рабочем месте остаются исходный файл, журналы, HTML-отчет и возможные временные копии. Настройте права и сроки хранения для каждого типа. Отчет может содержать достаточно данных для идентификации сделки, поэтому его нельзя автоматически публиковать в общем техническом каталоге.

Для тестирования интеграции используйте синтетические счета. Реальный документ нужен только после согласования процесса, проверки сетевого маршрута и определения ответственных. Если внутренняя политика запрещает внешнюю обработку, программный интерфейс не устраняет это ограничение. В таком случае выбирают валидатор, который можно развернуть в собственной инфраструктуре, и документируют различие наборов правил.

При расследовании сетевой ошибки не отправляйте счет по незащищенному каналу администратору. Достаточно передать время, код 2, адрес назначения из сетевых журналов и обезличенный тестовый файл. Содержательный отчет по реальному счету направляйте только участникам процесса. Такое разделение позволяет восстановить доступ, не расширяя круг лиц, видящих финансовые данные.

Регрессионный набор для генератора счетов

После настройки экспортера сохраните несколько эталонов, покрывающих UBL, CII и гибридный PDF, которые реально используются организацией. В наборе должны быть обычная ставка НДС, нулевая или освобожденная операция при наличии такого сценария, скидка, надбавка, несколько налоговых категорий и округление. Каждому файлу назначьте ожидаемый код, ключевые идентификаторы и контрольную сумму.

Добавьте отрицательные примеры с одной намеренной ошибкой: отсутствующей валютой, неверным кодом единицы, несходящейся суммой, неподдерживаемым идентификатором профиля и неправильной связью XML в PDF. Один дефект на файл делает результат объяснимым. Документ с десятками случайных нарушений плохо подходит для регрессии, потому что изменение одного правила меняет длинный каскад сообщений.

После обновления ERP, шаблона PDF или библиотеки экспорта прогоните весь набор через GUI либо CLI. Сравнивайте не только код возврата, но и идентификаторы правил в отчетах. Если корректный эталон стал красным, выясните, изменился ли сам экспорт или применяемая конфигурация сервиса. Если отрицательный пример внезапно стал зеленым, проверьте, не исчезло ли нужное правило и не исправил ли генератор ошибку автоматически.

Храните результаты теста рядом с версией конфигурации генератора, но не выводите служебную информацию в публичный счет. Валидатор нужен как внешний контроль конечного файла. Проверка промежуточного объекта недостаточна: последующая упаковка в PDF/A-3, добавление визуального слоя или транспортное преобразование способны изменить итоговый документ.

Передача ошибки поставщику или разработчику

Сообщение счет невалиден почти бесполезно. В запрос включите номер документа, хеш полученного файла, тип входа PDF или XML, итог PDF/A-3, итог XML, идентификатор первого корневого правила и небольшой фрагмент текста ошибки без лишних персональных данных. Приложите HTML-отчет через разрешенный защищенный канал. Для гибридного счета явно укажите, какой слой не прошел.

Поставщику не нужно отправлять внутренний сетевой log, если код равен 1 и отчет сформирован: проблема воспроизводится в документе. Разработчику инфраструктуры, наоборот, при коде 2 нужны время, параметры запуска, права каталогов и технический журнал, но не утверждение о некорректном XML. Код 3 направляется ответственному за лицензии. Такое распределение сокращает количество ошибочных возвратов.

При запросе исправления сформулируйте ожидаемый результат. Для отсутствующего сценария — файл в согласованном профиле. Для несходящихся сумм — новый экспорт с согласованной арифметикой. Для дефекта PDF/A — заново сформированный гибридный PDF, а не отдельный XML, прикрепленный вручную. Не просите починить PDF без указания, что машинная часть уже прошла или тоже содержит ошибки.

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

Ошибки оператора, которые искажают результат

Самая частая ошибка — проверка не того вложения. В письме могут быть счет, визуальная копия, приложение и XML с похожими именами. Сохраните файлы в отдельную папку и сопоставьте их с указанием отправителя. В поле 7-PDF должен находиться исходный электронный счет. Скриншот, распечатка или конвертированный PDF не сохраняют машинную структуру.

Вторая ошибка — повторное сохранение PDF перед анализом. Некоторые редакторы оптимизируют структуру, удаляют вложения или меняют PDF/A-метаданные. Если нужно обезопасить просмотр, работайте с копией, но валидатору передавайте байты, полученные по официальному каналу. Для исходящего счета проверяйте финальный файл после всех операций, а не черновик до подписи транспортного пакета.

Третья ошибка — интерпретация желтого или смешанного результата как полного успеха. Откройте обе строки и сводку. Если XML зеленый, а PDF красный, это не единый зеленый счет. Если формальная проверка прошла, это не разрешение на платеж. Цвет сокращает время сортировки, но не отменяет чтение отчета и внутренних контрольных процедур.

Дополнительные вопросы по эксплуатации

Почему один и тот же счет дает разные замечания после нового экспорта?

Экспортер мог изменить идентификатор сценария, порядок и набор элементов, округление либо структуру PDF/A-3. Сравните хеши и отчеты. Одинаковое имя файла не означает одинаковое содержимое.

Нужно ли открывать просмотрщик при каждом запуске?

Нет. Для автоматизированной сортировки достаточно кода и отчета, но перед оплатой или отправкой полезна визуальная сверка ключевых реквизитов. Автоматическое открытие включают только для ручного рабочего места.

Можно ли считать предупреждение несущественным?

Решение зависит от классификации сообщения и правил получателя. Сохраните исходный отчет и зафиксируйте внутреннее решение отдельно; не удаляйте предупреждение из протокола и не меняйте его смысл.

Что передать разработчику при ошибке XML?

Исходный файл, полный HTML-отчет, первый корневой код правила, путь к элементу, синтаксис UBL или CII и ожидаемый профиль. Скриншота красной полосы недостаточно для воспроизведения.

Что делать, если код 0 получен, а отчет не записан?

Проверьте каталог после -report, права записи и журнал. Для аудируемого процесса такой запуск лучше считать неполным и повторить после исправления сохранения доказательства.

Почему нельзя прикрепить исправленный XML к старому PDF вручную?

Обычное вложение может не получить требуемую ассоциацию Alternative и способно нарушить PDF/A-3. Гибридный счет должен заново формироваться инструментом, который контролирует контейнер и машинную часть.

Как отличить сетевую проблему от ошибки счета?

При сетевой проблеме анализ не завершается содержательным отчетом и CLI возвращает код выполнения. При ошибке счета сервис формирует результат, XML или PDF получает отрицательный статус, а код равен 1.

Следует ли отправлять поставщику весь технический журнал?

Нет, если документ проверен и есть HTML-отчет. Log нужен администратору при коде 2. Поставщику передают отчет о формальных правилах и идентификатор конкретного файла.

Сравнение 7-PDF E-Invoice Validator с аналогами

Программа	Лучше подходит для	Главное ограничение
7-PDF E-Invoice Validator	Ручной проверки PDF/ZUGFeRD и XML с единым окном, отчетом, просмотрщиком и CLI	Проверка зависит от сервиса и лицензии
Quba Viewer	Бесплатного просмотра электронных счетов на Windows, Linux и macOS	Онлайн-валидация использует Mustangserver
Mustangproject	Разработчиков, Java-интеграций и командной проверки ZUGFeRD, Factur-X и XRechnung	Требует технической настройки Java и CLI
KoSIT Validator	Воспроизводимой XML-проверки XRechnung по официальной конфигурации сценариев	Нужны Java и отдельная конфигурация
E-Rechnungs-Studio	Браузерного просмотра, проверки и исправления существующего XML или ZUGFeRD	Работа строится через веб-приложение

7-PDF удобнее бухгалтеру или небольшому офису, которому нужны знакомое окно, раздельные результаты PDF/A-3 и XML, просмотр и отчет без ручной сборки Java-компонентов. Quba стоит выбирать для бесплатного кроссплатформенного чтения счетов. Mustangproject и KoSIT подходят разработчикам и закрытым процессам, где важны воспроизводимые сценарии и собственная инфраструктура. E-Rechnungs-Studio полезен, когда требуется не только увидеть ошибку, но и пройти веб-процесс корректировки файла.

PDF Commander не заменяет ни один из этих валидаторов: его сильная сторона — редактирование и организация обычных PDF, тогда как EN 16931, XRechnung и встроенный XML требуют специализированных правил. Он уместен для работы с сопроводительными PDF-документами, но не должен использоваться как доказательство формальной корректности электронной накладной или счета.

Как выбрать тестовые документы

Для оценки программы недостаточно одного корректного счета. Набор должен включать минимум пять случаев: действующую XRechnung UBL, XRechnung CII, корректный ZUGFeRD/Factur-X, PDF с корректным XML и нарушенным PDF/A-3, а также документ с заведомой ошибкой обязательного поля. Такой комплект показывает распознавание сценариев, раздельные результаты и качество отчета.

Добавьте файл с неправильным вложением XML: он демонстрирует разницу между видимым attachment и нормативной связью Alternative. Отдельно полезен старый профиль, чтобы увидеть сообщение об отсутствии действующего сценария. Не используйте реальные банковские реквизиты клиентов для учебного теста, если передачу не согласовали; лучше взять официальные или синтетические образцы.

Каждый ожидаемый результат зафиксируйте заранее. Если тестовый файл считается корректным только потому, что другой валидатор показал зеленый статус, возможны различия наборов правил. Сравнивайте идентификатор сценария, версии схем и конкретные сообщения, а не только цвет.

Контроль качества после внедрения

Правила электронных счетов меняются, поэтому контроль не заканчивается в день установки. Периодически прогоняйте эталонный набор и сравнивайте отчеты. Если ранее проходивший файл стал отклоняться, сначала выясните, изменился ли примененный сценарий или требования профиля; не отключайте проверку автоматически.

В журнале эксплуатации полезно хранить дату, исходный файл, код возврата, путь к отчету и результат ручной сверки. Для красных документов добавляйте категорию причины: структура, бизнес-правило, PDF/A, сеть или лицензия. Такая статистика показывает, где исправлять процесс — у поставщика, в собственном экспорте, в инфраструктуре или в обучении операторов.

Следите за остатком пробных проверок на тестовых машинах и состоянием лицензии на рабочих. В автоматическом процессе код 3 должен создавать отдельное уведомление. Проверка, внезапно остановившаяся из-за лицензии, не должна оставлять счета в общей папке без статуса.

Практические вопросы

Можно ли проверить обычный PDF-счет?

Файл можно выбрать, но полноценная проверка электронного счета возможна только при наличии правильно встроенного XML и подходящего сценария. Обычная визуальная PDF-страница без структурированных данных не превращается в XRechnung или ZUGFeRD.

Почему программа показывает зеленый XML и красный PDF?

Это два независимых слоя. Машинные данные прошли EN 16931, а контейнер не прошел PDF/A-3. Откройте отчет и исправляйте генерацию PDF, не меняя корректные реквизиты XML без причины.

Можно ли проверять целую папку?

Да, через внешний сценарий, который поочередно вызывает CLI для каждого файла. Один вызов использует один -infile; результаты следует раскладывать по отдельным логам и каталогам отчетов.

Где искать подробности при коде 2?

В файле, заданном параметром -logfile. Код 2 означает проблему выполнения — путь, сеть, доступ, сервис или запись результата, а не подтвержденную ошибку счета.

Почему нет отчета при видимом factur-x.xml?

Проверьте AFRelationship=Alternative, описание вложения и PDF/A-3-структуру. Видимость XML в панели вложений не доказывает нормативное встраивание.

Нужен ли интернет после активации?

Да, он нужен для самой проверки, поскольку счет передается в сервис валидации. Активация — отдельный сетевой процесс.

Исправляет ли программа ошибки автоматически?

Нет. Она показывает результат, визуальное представление и отчет. Новый корректный файл нужно сформировать в учетной системе, генераторе или специализированном редакторе.

Можно ли использовать результат как единственное разрешение на оплату?

Нет. Формальная валидация не подтверждает поставку, контрагента, договор, банковский счет и отсутствие дубликата. Эти проверки выполняются внутренними процедурами.

Итоговый порядок безопасной проверки

Сохраните исходный счет, убедитесь, что выбран PDF или XML, включите согласие на передачу, запустите анализ и дождитесь завершения. Затем прочитайте отдельно PDF/A-3, XML и сводку, откройте отчет, а для XML без печатной формы — встроенный просмотрщик. Красный статус классифицируйте по типу: дефект контейнера, ошибка бизнес-правила, неподдерживаемый сценарий или проблема выполнения.

После исправления создайте новый файл из исходной учетной системы и повторите проверку. Не маскируйте проблему переименованием, ручным изменением итогов или повторной печатью PDF. Для автоматизации используйте коды возврата, отдельные журналы и HTML-отчеты; для конфиденциальных документов заранее согласуйте передачу сервису и правила хранения доказательств.

7-PDF E-Invoice Validator особенно удобен, когда один сотрудник должен быстро принять или отклонить небольшой поток ZUGFeRD и XRechnung, а затем при необходимости передать точный отчет разработчику или поставщику. Его сильная сторона — единый рабочий экран с раздельной оценкой XML и PDF/A-3; основные ограничения — зависимость от сети, десять пробных запусков и отсутствие встроенного исправления данных.