Как исправить ошибку «Не найден документ с идентификатором запроса» при обмене 1С:Розница с ЕГАИС?

Системный администратор 1С v8.3 (Управляемые формы) 1С:Розница Торговля и дистрибуция
← На главную

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

Проанализируем причину возникновения этого сбоя и разберем по шагам практические способы восстановления штатной работы транспортного модуля и товароучетной системы.

Почему возникает данная ошибка

Документ с типом ReplyRestsShop_Mini представляет собой сформированный системой ЕГАИС ответ на исходящий запрос остатков продукции в торговом зале (Регистр №2). Взаимодействие между 1С:Розница и Универсальным транспортным модулем (УТМ) построено на строгом контроле уникальных идентификаторов (GUID):

  1. Когда пользователь отправляет запрос остатков из 1С, программа генерирует уникальный идентификатор запроса и сохраняет его в базе данных.
  2. УТМ передает запрос на серверы ЕГАИС, получает ответ и помещает его в свою локальную входящую очередь (директория /opt/out/).
  3. При очередном сеансе обмена 1С считывает входящий XML-пакет, находит в своей базе исходный документ по сохраненному GUID и, если документ найден, загружает строки остатков. После успешного прочтения 1С отправляет в УТМ команду DELETE, удаляя файл из очереди транспортного модуля.

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

Способ 1. Точечное удаление зависшего ответа из УТМ (рекомендуемый способ)

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

Выясним точный номер входящего документа из текста ошибки. В приведенном примере это документ с номером 1414 по адресу /opt/out/ReplyRestsShop_Mini/1414.

Откроем командную строку операционной системы (cmd) или терминал на компьютере, где установлен УТМ, и выполним утилиту curl:

curl -X DELETE http://localhost:8080/opt/out/ReplyRestsShop_Mini/1414

Если на сервере удобнее использовать PowerShell, запустим консоль от имени администратора и выполним следующую команду:


Invoke-RestMethod -Uri "http://localhost:8080/opt/out/ReplyRestsShop_Mini/1414" -Method Delete

После успешного выполнения команды пакет с номером 1414 будет удален из базы УТМ. Теперь запустим обмен в 1С:Розница повторно: система пропустит удаленный документ и перейдет к получению следующих актуальных данных.

Способ 2. Полная очистка входящей очереди УТМ при массовом скоплении пакетов

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

  1. Откроем оснастку управления службами Windows (services.msc).
  2. Найдем и остановим все службы, относящиеся к УТМ: обычно это Transport и Transport-Updater.
  3. Перейдем в каталог установки транспортного модуля (по умолчанию C:\UTM\transporter\ или корневая папка C:\UTM\).
  4. Найдем подпапку transportDB, в которой хранится встроенная база данных УТМ. Переименуем её (например, в transportDB_old) или переместим в архивную директорию.
  5. Вернемся в оснастку служб и запустим службы УТМ заново. При старте транспортный модуль автоматически создаст абсолютно чистую базу данных transportDB.

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

Способ 3. Создание документа-основания в 1С (альтернативный вариант)

Если данные из входящего ответа все же требуется загрузить в информационную базу, применим обходной путь. Проанализируем журнал регистрации, найдем текст входящего XML и с помощью внешней обработки или встроенных средств разработчика создадим в базе документ «Остатки ЕГАИС» по Регистру №2. Запишем в реквизит идентификатора запроса значение из ошибки: 92705214-a716-4cb5-8562-556c5f82afb1. При следующем запуске обмена типовой механизм 1С успешно сопоставит входящий ответ с созданным документом, проведет загрузку остатков и самостоятельно очистит очередь УТМ штатной командой.

Особенности возобновления работы после длительного простоя

При возвращении к работе с алкогольной продукцией после длительного перерыва обратим внимание на важные регламентные изменения:

  1. Регистр №2 (Торговый зал): Федеральная служба по регулированию алкогольного рынка вывела данный регистр из оборота для маркированной алкогольной продукции. Весь поштучный учет крепкого алкоголя ведется строго на Регистре №1 и Регистре №3 с указанием цифровых акцизных марок. Регистр №2 в настоящее время применяется преимущественно для немаркированной продукции (пиво, сидр, медовуха). Запрашивать остатки по регистру №2 для крепких напитков не имеет практического смысла.
  2. Сертификаты и версии ПО: перед отправкой новых запросов обязательно убедимся, что срок действия сертификатов КЭП и RSA на аппаратном ключе (Рутокен или JaCarta) не истек, а версия УТМ обновлена до актуальной рабочей сборки.
← На главную