Как исправить ошибку валидации XML при запросе на отмену проведения в ЕГАИС?

← На главную

При работе с системой ЕГАИС через Универсальный Транспортный Модуль (УТМ) разработчики часто сталкиваются с ошибками валидации XML-документов. Одной из самых коварных является ошибка SAXParseException, указывающая на некорректное содержимое элемента. Рассмотрим ситуацию, когда при отправке запроса на отмену проведения прихода (RequestRepealWB) система возвращает сообщение о том, что ожидается элемент ClientId, но найден qp:ClientID. Разберем по шагам, почему это происходит и как правильно сформировать запрос.

Анализ причины ошибки валидации

Основная причина возникновения ошибки cvc-complex-type.2.4.a: Invalid content was found starting with element 'qp:ClientID' заключается в строгом соблюдении регистра символов в XML-схемах ЕГАИС. Стандарт XSD (XML Schema Definition) чувствителен к регистру (case-sensitive). В данном случае в структуре сообщения был использован тег ClientID (с большой буквой "D" в конце), в то время как схема ожидает ClientId.

Проанализируем структуру, которую ожидает сервер:

ClientId — идентификатор организации в системе ФСРАР (FSRAR_ID).
RequestNumber — уникальный номер запроса (обычно GUID).
RequestDate — дата и время формирования запроса в строгом формате.
WBRegId — регистрационный номер накладной в системе ЕГАИС (например, TTN-0080189231).

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

Корректное формирование XML-запроса

Рассмотрим правильный пример XML-структуры для запроса на отмену проведения. Обратите внимание на правильное написание тегов и использование пространств имен (namespaces). Выясним, как должен выглядеть исправленный файл:


<?xml version="1.0" encoding="UTF-8" ?>
<ns:Documents Version="1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:ns="http://fsrar.ru/WEGAIS/WB_DOC_SINGLE_01"
    xmlns:qp="http://fsrar.ru/WEGAIS/RequestRepealWB">
    <ns:Owner>
        <ns:FSRAR_ID>010000005334</ns:FSRAR_ID>
    </ns:Owner>
    <ns:Document>
        <ns:RequestRepealWB>
            <qp:ClientId>010000005334</qp:ClientId>
            <qp:RequestNumber>B3FA9E1B-F77D-4B46-823D-E5D0211CAD09</qp:RequestNumber>
            <qp:RequestDate>2016-12-08T17:08:33</qp:RequestDate>
            <qp:WBRegId>TTN-0080189231</qp:WBRegId>
        </ns:RequestRepealWB>
    </ns:Document>
</ns:Documents>

Важно: убедитесь, что значение в теге qp:ClientId полностью совпадает со значением ns:FSRAR_ID в блоке ns:Owner. Это должен быть идентификатор того участника системы, который инициирует отмену.

Дополнительные технические требования схемы

Помимо регистра символов, существует еще несколько критических моментов, которые необходимо проверить при возникновении подобных ошибок:

Порядок следования элементов: Схема XSD строго регламентирует последовательность полей внутри RequestRepealWB. Если вы переставите местами, например, WBRegId и RequestNumber, УТМ выдаст аналогичную ошибку валидации. Порядок должен быть именно таким: ClientId -> RequestNumber -> RequestDate -> WBRegId.
Формат даты: Поле RequestDate должно соответствовать формату ISO 8601 (ГГГГ-ММ-ДДThh:mm:ss). Наличие лишних пробелов или неверных разделителей приведет к ошибке.
Уникальность RequestNumber: Для каждого нового запроса генерируйте новый идентификатор (GUID). Если отправить запрос с номером, который уже использовался ранее, система может его проигнорировать или вернуть ошибку дублирования.

Особенности реализации в 1С 7.7

Поскольку в платформе 1С 7.7 нет встроенных современных средств работы с XML, таких как в 8.3, разработчики часто формируют текст XML вручную (склейкой строк) или используют внешние компоненты. Посмотрим, на что стоит обратить внимание в этом случае:

Во-первых, при формировании строки обязательно следите за кодировкой. Файл должен быть сохранен в UTF-8 без BOM. Использование стандартных методов записи текстовых файлов в 7.7 может добавить невидимые символы в начало файла, что вызовет ошибку парсинга в УТМ.

Во-вторых, рекомендуется использовать объект DOMDocument (через СоздатьОбъект("msxml2.domdocument")), так как это позволяет более корректно управлять пространствами имен и гарантирует, что структура документа будет соответствовать стандартам XML. Рассмотрим пример логики формирования узлов:


// Пример логики создания узлов (схематично)
ДокXML = СоздатьОбъект("msxml2.domdocument");
Корень = ДокXML.createElement("ns:Documents");
// ... установка атрибутов xmlns:ns, xmlns:qp ...
УзелЗапроса = ДокXML.createElement("qp:RequestRepealWB");
// Важно: создаем именно ClientId, а не ClientID
УзелКлиент = ДокXML.createElement("qp:ClientId");
УзелКлиент.text = "010000005334";
УзелЗапроса.appendChild(УзелКлиент);

Проверка результата через логи УТМ

Если после исправления регистра ошибка сохраняется, проанализируйте лог-файлы самого транспортного модуля. Файл transport_info.log в папке logs вашего УТМ содержит детальную информацию о том, какой именно элемент не прошел валидацию. Это поможет быстро локализовать проблему, если она вызвана, например, скрытыми символами или неверным адресом отправки запроса.

Помните, что для запроса на отмену проведения (RequestRepealWB) используется специфический URL входа в УТМ: http://[адрес_утм]:[порт]/opt/in/RequestRepealWB. Убедитесь, что ваш программный код отправляет сформированный XML именно по этому адресу.