Валидация XML по XSD и проверка правил ФНС: в чём разница

«Я проверил файл по схеме, ошибок нет, а оператор ЭДО его отклонил». Ситуация знакомая всем, кто формирует электронные УПД. Причина в том, что валидация XML по XSD проверяет только одну сторону документа — его форму. Содержание, то есть суммы, НДС и связи между полями, проверяется отдельно, по логическим правилам.

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

Что проверяет XSD, а что нет

XSD-схема — это формальное описание структуры XML. Валидатор берёт ваш файл и схему ФНС для УПД 5.03 и проверяет каждое правило, записанное в схеме.

Что ловит валидация по XSD:

• есть ли все обязательные элементы и атрибуты;
• нет ли лишних или неизвестных тегов;
• в правильном ли порядке идут элементы;
• подходит ли значение под тип: число, дата, строка нужной длины;
• соответствует ли значение шаблону (например, ИНН из 10 или 12 цифр) или списку разрешённых (КНД, функция документа, ставка НДС);
• не указаны ли два взаимоисключающих варианта (адрес в РФ и иностранный одновременно).

Чего XSD не видит:

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

Схема знает, что в поле «Стоимость с НДС» должно быть число с двумя знаками после точки. Но ей всё равно, какое это число.

Логические правила: итоги, НДС, даты, связи полей

Второй уровень проверки — контрольные соотношения. Это правила, которые связывают значения разных полей между собой. В мире XML их часто описывают на языке Schematron, а операторы ЭДО и ФНС реализуют у себя.

Основные группы правил для УПД:

Часть этих правил оператор ЭДО проверит при загрузке и откажет, часть всплывёт позже: у покупателя при сверке, в учётной системе при приёмке или при проверке.

Пример: файл прошёл XSD, но отклонён

Возьмём строку товара:

<СведТов НомСтр="1" НаимТов="Ноутбук NB-X15" ОКЕИ_Тов="796"
         КолТов="2" ЦенаТов="50000.00" СтТовБезНДС="100000.00"
         НалСт="22%" СтТовУчНал="122000.00">
  <Акциз><БезАкциз>без акциза</БезАкциз></Акциз>
  <СумНал><СумНал>2200.00</СумНал></СумНал>
</СведТов>

С точки зрения схемы всё прекрасно: все атрибуты на месте, суммы — числа с двумя знаками, ставка из списка. Валидация по XSD проходит без замечаний.

Но логика нарушена дважды:

1. НДС 22% от 100 000 — это 22 000, а не 2 200. Опечатка в один ноль.
2. Стоимость с НДС 122 000 не равна 100 000 + 2 200.

Дальше ошибка расползается по документу: итог в ВсегоОпл, если он посчитан из строк, тоже не сойдётся с суммой «с НДС». Оператор ЭДО может отклонить такой файл, а если пропустит, покупатель получит счёт-фактуру с неверным налогом, и её придётся исправлять.

Другой частый пример — имя файла. Вы сформировали УПД, всё проверили по схеме, потом переименовали файл в «УПД_145.xml», чтобы было удобнее искать. Схема имя файла не проверяет вообще, а оператор ЭДО отклонит документ с ошибкой «Имя файла не соответствует ИдФайл».

Третий — функция документа. В файле указано Функция="СЧФДОП", но блока о передаче товаров нет. Для схемы это может быть допустимо, ведь блок описан как необязательный для разных сценариев. По смыслу же передаточный документ без сведений о передаче неполон.

Как проверять оба уровня

Порядок простой:

1. Сначала структура. Если файл не проходит XSD, логические проверки бессмысленны: валидатор может даже не дочитать документ. Исправьте ошибки схемы. Как их расшифровывать, подробно разобрано в статье Файл не соответствует XSD-схеме УПД: что значит ошибка и как исправить.
2. Затем логика. Пересчитайте строки, НДС и итоги, сверьте даты и функцию документа, проверьте имя файла.
3. Повторная проверка после каждой правки. Ручное исправление суммы в одной строке легко ломает итог.
4. Только потом подпись. После подписи изменить документ уже нельзя, только выпустить исправление.

Лучше всего, когда оба уровня проверяет один инструмент и выдаёт общий список ошибок.

Если вы разработчик и формируете УПД программно, встройте проверку в сам процесс выгрузки: валидация XML по XSD — стандартная функция большинства XML-библиотек, а логические правила удобно оформить отдельными тестами на итоги и НДС. Тогда ошибка будет видна на этапе разработки, а не в отказе оператора ЭДО. Не забудьте, что тестовые файлы тоже должны быть в windows-1251 и называться по ИдФайл, иначе вы проверите не то, что уйдёт контрагенту.

Инструменты для валидации

Универсальные валидаторы хороши, если вы разработчик и отлаживаете выгрузку. Но учтите, что загружать в сторонние сервисы документы с реальными данными контрагентов стоит осознанно.

Для бухгалтера практичнее инструмент, который уже знает формат УПД и объясняет ошибки на языке реквизитов, а не тегов.

Коротко

• Валидация XML по XSD отвечает на вопрос «правильно ли собран файл».
• Логические правила отвечают на вопрос «правильные ли в нём данные».
• Файл, прошедший только XSD, вполне может быть отклонён оператором ЭДО или содержать ошибку в налоге.
• Проверять нужно оба уровня, до подписания.

Загрузить XML и проверить УПД по схеме ФНС вместе с логическими правилами можно за минуту. А если удобнее готовить документ в таблице, наш конвертер УПД сам посчитает суммы, НДС и итоги и сформирует имя файла по ИдФайл, так что большая часть логических ошибок просто не появится. Подпись и отправка документа выполняются у вашего оператора ЭДО.