Как исправить ошибки обмена с УТМ в 1С:Розница, если не найден идентификатор запроса?

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

Почему возникает ошибка поиска идентификатора запроса

Проанализируем архитектуру взаимодействия. УТМ работает как промежуточный почтовый ящик между 1С и сервером ЕГАИС. Когда 1С отправляет запрос (например, запрос остатков), она фиксирует в своей базе уникальный идентификатор этого запроса (UUID). Когда приходит ответ, 1С ищет в своей базе исходящую запись с таким же UUID. Если соответствие найдено, документ загружается.

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

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

Метод 1: Очистка транспортной базы УТМ (Универсальный способ)

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

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

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

Метод 2: Выборочное удаление сообщений через curl

Для продвинутых пользователей и системных администраторов существует способ точечного удаления «проблемных» сообщений без полной очистки базы. Для этого используется утилита curl. Команда отправляется непосредственно в транспортный модуль.

Рассмотрим пример команды для удаления сообщения:

curl -X DELETE http://localhost:8080/opt/out/ReplyRests/15

Где ReplyRests/15 — это тип документа и его порядковый номер в очереди, который можно подсмотреть на локальной странице УТМ (обычно по адресу http://localhost:8080 в разделе «Входящие»). Выясним причину: 1С не может забрать документ, потому что он «чужой», и он продолжает висеть в УТМ, мешая остальным. Ручное удаление через DELETE решает эту проблему.

Метод 3: Ручная привязка идентификатора в 1С

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

Проанализируем техническую часть: данные об обменах хранятся в справочнике ЕГАИСПрисоединенныеФайлы или специальных регистрах сведений. Если вы нашли в журнале регистрации UUID запроса (например, 25df86c4-f908-4ef3-a11d-d315ef9ae037), можно попробовать найти запись с пустым идентификатором за текущую дату и вручную заполнить поле Идентификатор запроса. После этого при очередном сеансе обмена 1С «узнает» входящий файл и успешно его загрузит. Для решения похожих проблем рассинхронизации данных в ЕГАИС и базе Розницы можно использовать методику ручного изменения статусов марок.

Пример логики поиска в коде (для разработчиков):

Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |   ЕГАИСЗапросы.Ссылка КАК Ссылка
    |ИЗ
    |   Справочник.ЕГАИСЗапросы КАК ЕГАИСЗапросы
    |ГДЕ
    |   ЕГАИСЗапросы.ИдентификаторЗапроса = &ПустойID";
Запрос.УстановитьПараметр("ПустойID", "");
// Далее программно присваиваем ID из ошибки

Правильная схема работы при совместном использовании УТМ

Чтобы избежать подобных проблем в будущем, рассмотрим рекомендации по организации работы, если вам необходимо использовать несколько программ для одного ФСРАР ID:

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

Подводя итог, отметим: появление ошибок с идентификаторами в 1С:Розница 2.2 — это чаще всего признак «засорения» очереди УТМ сообщениями от сторонних систем. Самым быстрым и эффективным решением остается остановка служб и удаление папки transportDB, что позволяет начать обмен с «чистого листа».