Почему клиент не видит исправленную накладную в ЕГАИС после отзыва и как это исправить

Рассмотрим распространенную и неприятную ситуацию в оптово-розничной торговле алкогольной продукцией. Поставщик оформляет товарно-транспортную накладную (ТТН), отправляет ее в ЕГАИС и получает регистрационный номер WBRegId. Затем обнаруживается ошибка, отправляется отказ за грузополучателя, фиксируется тикет о распроведении документа, и поставщик повторно выгружает исправленную ТТН в ЕГАИС, получая совершенно новый WBRegId. Однако клиент утверждает, что исправленная накладная до него не дошла и в его учетной системе не отображается.

Разберем подробно причины такого поведения ЕГАИС и учетных систем контрагентов, а также выясним, какие технические шаги необходимо предпринять отправителю и получателю для успешного обмена.

Причина 1: Дублирование клиентского идентификатора документа (тег Identity)

Проанализируем структуру XML-пакета накладной WayBill, отправляемого в ЕГАИС. В заголовке документа присутствует тег wb:Identity:

<xs:element name="Identity" type="c:IdentityType" nillable="false" minOccurs="0" maxOccurs="1">
    <xs:annotation>
        <xs:documentation>Идентификатор накладной (клиентский, к заполнению необязательный)</xs:documentation>
    </xs:annotation>
</xs:element>

В это поле типовые конфигурации 1С и сторонние учетные системы обычно выгружают внутренний уникальный идентификатор (GUID) документа. Если после отзыва старой накладной вы отправляете исправленный документ с тем же самым GUID в поле wb:Identity, на стороне грузополучателя могут возникнуть следующие проблемы:

1. Схлопывание по идентификатору: Многие учетные программы грузополучателей при разборе входящих пакетов из УТМ используют поле Identity для контроля дублей. Обнаружив накладную с уже известным Identity, программа считает ее повтором уже обработанного (или отклоненного) документа и просто игнорирует входящий XML.
2. Разрыв связки накладной и справки Б: При фиксации накладной ЕГАИС формирует справку к ТТН (справку 2 / форму Б), в которой указан номер WBRegId. Учетная система получателя сопоставляет саму накладную и регистрационную справку по идентификатору Identity. Если он совпадает со старой версией, новая справка может привязаться к ранее отмененной ТТН.

Решение для отправителя: При повторной отправке накладной в 1С создавайте новый документ с генерацией нового GUID либо программно обновляйте значение поля wb:Identity. Старый документ в базе следует перевести в статус «Отменен/Отозван» для сохранения корректной истории.

Причина 2: Контроль уникальности связки «Номер + Дата + Поставщик» в базе клиента

Выясним, как работают типовые конфигурации 1С на стороне грузополучателя (например, «1С:Розница» или «1С:Управление торговлей»). Даже если документу присвоен новый WBRegId, механизм загрузки входящих ТТН проверяет уникальность по реквизитам:

1. ИНН/КПП или ФСРАР_ID грузоотправителя;
2. Номер входящей ТТН поставщика;
3. Дата накладной.

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

Причина 3: Зависание документа в очереди УТМ или сбой доставки ЕГАИС

Посмотрим на ситуацию со стороны транспортного модуля (УТМ). Служба ЕГАИС не всегда моментально доставляет входящие пакеты конечному получателю. Документ может застрять на центральном сервере или в очереди УТМ контрагента по следующим причинам:

1. Зависла служба УТМ на компьютере клиента или переполнена входящая очередь необработанных тикетов.
2. Истек срок действия RSA-ключа или ГОСТ-сертификата на аппаратном ключе грузополучателя, из-за чего модуль временно не забирает входящую корреспонденцию с серверов ЕГАИС.
3. Накладная отправлена на неактивный ФСРАР_ID (например, если у обособленного подразделения клиента недавно сменился КПП или адрес лицензии).

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

Разберем по шагам порядок действий для локализации и устранения проблемы:

1. Проверка статуса ТТН: Попросите грузополучателя или проверьте самостоятельно через официальный сервис проверки документов ЕГАИС статус накладной по ее номеру WBRegId и ФСРАР_ID отправителя. Если статус указывает «Отправлено в УТМ получателя», значит, со стороны ЕГАИС документ передан успешно и проблема находится исключительно в учетной системе или УТМ клиента.
2. Запрос на переотправку документа (QueryResendDoc): Получатель может сформировать прямой запрос на повторное получение накладной из своего программного интерфейса 1С. Для этого в форме обмена с ЕГАИС оформляется запрос на загрузку ТТН по известному номеру WBRegId. Сервер ЕГАИС повторно положит пакет документа в очередь входящих сообщений УТМ получателя.
3. Перезапуск службы УТМ: Если очередь входящих сообщений заблокирована, грузополучателю необходимо перезапустить транспортный модуль и запустить регламентное задание загрузки данных ЕГАИС в своей 1С.

Рекомендуемый регламент работы с исправлениями ТТН

Чтобы минимизировать риск потери накладных и разногласий с контрагентами, придерживайтесь следующих правил:

1. При обнаружении расхождений по количеству товара отдавайте предпочтение оформлению акта расхождений (акта разногласий) со стороны грузополучателя вместо полного отказа и перевыгрузки ТТН.
2. Если отказ и повторная отправка неизбежны — формируйте в 1С совершенно новый документ отгрузки с новым wb:Identity (новым GUID), не перезаписывая отправленные ранее реквизиты.
3. Всегда передавайте контрагенту актуальный номер WBRegId новой накладной, чтобы его оператор мог выполнить точечный поиск и принудительную загрузку документа.