Как исправить ошибку подтверждения ТТН ЕГАИС со статусом «Передан в УТМ» в «1С:Розница»

← На главную

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

Выясним причину возникновения проблемы

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

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

Решение №1: Групповое изменение реквизитов (универсальный способ)

Если нам нужно быстро восстановить статус накладной без вмешательства в конфигуратор (что особенно актуально для пользователей Базовых версий), воспользуемся механизмом группового изменения данных. Этот метод заставляет систему «перезаписать» объект и инициировать проверку привязанных к нему тикетов.

Разберем этот процесс по шагам:

Перейдем в раздел Администрирование, далее выберем пункт Обслуживание.
В открывшемся окне найдем подраздел Корректировка данных и выберем ссылку Групповое изменение реквизитов.
В поле «Изменять» выберем тип документа: Товарно-транспортная накладная ЕГАИС (входящая).
Настроим отбор, чтобы не изменить лишние документы. Нажмем «Добавить условие отбора», выберем поле Ссылка или Идентификатор ЕГАИС и укажем конкретную накладную (например, содержащую номер TTN-0000000000).
В списке реквизитов найдем поле Дата регистрации движений.
Установим новое значение: рекомендуется изменить время на несколько секунд позже даты самого документа (например, прибавить 5-10 секунд) или просто поставить текущую дату и время, если накладная пришла сегодня.
Нажмем кнопку Изменить реквизиты.
После успешного завершения операции вернемся в рабочее место ЕГАИС и нажмем Выполнить обмен.

Почему это помогает? Изменение даты регистрации движений и последующая запись объекта активируют программные подписки на события. При записи документа 1С заново сканирует входящие сообщения из УТМ и, обнаружив «потерянный» тикет, привязывает его к нашей ТТН. Статус документа корректно меняется на «Подтвержден».

Решение №2: Исправление программного кода (для версий ПРОФ)

Если вы используете версию ПРОФ и готовы внести изменения в код (или использовать расширение), проанализируем ситуацию в конфигураторе. Проблема заключается в функции, которая проверяет соответствие типа документа. Нам необходимо расширить список допустимых типов, чтобы программа начала узнавать акты подтверждения накладных.

Рассмотрим подробнее изменения в общем модуле ИнтеграцияЕГАИС. Нам нужно найти функцию ДокументСоответствуетТипуЕГАИС и дополнить её логику.

Исходный фрагмент кода обычно выглядит так:


Возврат ВРег(ТипЕГАИС) = ВРег("WayBill") 
    ИЛИ ВРег(ТипЕГАИС) = ВРег("WayBill_v2") 
    ИЛИ ВРег(ТипЕГАИС) = ВРег("WayBill_v3");

Нам необходимо заменить его на вариант, который учитывает типы WayBillAct. Мы добавим проверку на версии актов, чтобы система корректно обрабатывала тикеты, приходящие от ФСРАР:


Возврат ВРег(ТипЕГАИС) = ВРег("WayBill") 
    ИЛИ ВРег(ТипЕГАИС) = ВРег("WayBill_v2") 
    ИЛИ ВРег(ТипЕГАИС) = ВРег("WayBill_v3") 
    ИЛИ ВРег(ТипЕГАИС) = ВРег("WayBillAct") 
    ИЛИ ВРег(ТипЕГАИС) = ВРег("WayBillAct_v2") 
    ИЛИ ВРег(ТипЕГАИС) = ВРег("WayBillAct_v3");

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

Альтернативный метод через «Запросы ЕГАИС»

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

Перейдем в раздел Запросы ЕГАИС.
Создадим новый документ с типом Запрос накладной по идентификатору.
В поле идентификатора введем полный номер накладной (например, TTN-0123456789).
Отправим запрос в ЕГАИС и дождемся ответа.

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

Проверка состояния УТМ

Иногда корень проблемы лежит не в коде 1С, а в работе самого транспортного модуля. Проанализируем ситуацию: если в очереди УТМ скопилось слишком много необработанных сообщений (более 100-200), 1С может работать крайне нестабильно и пропускать нужные пакеты данных.

Рекомендуется выполнить следующие действия:

Откроем браузер и перейдем по адресу домашней страницы УТМ (обычно это http://localhost:8080).
Перейдем на вкладку Входящие.
Если список документов огромен, это означает, что 1С не успевает их забирать или блокируется ошибкой.
В таком случае стоит попробовать очистить базу УТМ (через настройки самого модуля) и повторно запросить нужную ТТН из ЕГАИС, предварительно применив «костыль» с датой регистрации из первого решения.

Подведем итоги

Мы рассмотрели несколько способов решения проблемы со статусом ТТН. Самым надежным и долгосрочным решением является обновление конфигурации 1С:Розница до релиза 2.2.7.43 или выше (в ветке 2.2.8 и 2.3 эта ошибка полностью исправлена). Однако, если обновление невозможно по техническим причинам, использование групповой обработки реквизитов для изменения ДатаРегистрацииДвижений является проверенным и безопасным способом «протолкнуть» зависший документ.