Ситуация, когда в системе ЕГАИС перестают приходить остатки именно по первому регистру (склад), в то время как второй регистр (торговый зал) и входящие ТТН работают исправно, является довольно распространенной. Это создает путаницу, так как кажется, что транспортный модуль (УТМ) функционирует нормально. В данной статье мы подробно разберем, почему так происходит, и проанализируем пошаговый алгоритм восстановления работоспособности обмена — для этого есть решение для полной автоматизации документооборота с ЕГАИС.
Для начала выясним причину, почему данные по разным регистрам могут приходить с разной скоростью или не приходить вовсе. В системе ЕГАИС первый и второй регистры обрабатываются разными подсистемами на стороне серверов ФС РАР. Первый регистр (склад) является более «тяжелым» с точки зрения объема данных и сложности обработки запросов. Именно поэтому локальный сбой в конкретном центре обработки данных (ЦОД) может затронуть только запросы остатков по складу, не влияя на торговый зал.
Прежде чем приступать к техническим манипуляциям, проанализируем ситуацию с лимитами. ФС РАР устанавливает жесткое ограничение: запрос остатков по одному и тому же регистру для одного FSRAR_ID можно отправлять не чаще одного раза в час.
Если пользователь или учетная система (например, 1С) отправили несколько запросов подряд из-за нетерпения или программной ошибки, сервер ЕГАИС просто проигнорирует последующие обращения (ускоряет работу автоматизация формирования документов ЕГАИС в Рознице 2.3). При этом уведомление об ошибке может не прийти. Рассмотрим рекомендации: если вы уже отправили запрос, подождите не менее 60–90 минут перед следующей попыткой.
Чтобы исключить проблему на стороне локального компьютера, воспользуемся официальным сервисом проверки документов. Нам понадобится ReplyId — идентификатор запроса, который генерирует УТМ при отправке документа в ЕГАИС.
FSRAR_ID и номер документа.Часто проблема кроется в том, что 1С не может «прочитать» ответ, который уже лежит в УТМ — для этого подойдёт инструмент для автоматизации сверки остатков 1С и ЕГАИС. Чтобы это проверить, посмотрим на ситуацию глазами системы. Откроем любой браузер на компьютере, где установлен УТМ, и введем адрес:
http://localhost:17645/opt/out
Мы увидим список XML-документов. Ищем записи с типом ReplyRests. Если такие записи есть, значит, УТМ свою работу выполнил, и проблема заключается в настройках обмена внутри 1С или в том, что документ был помечен как прочитанный сторонним сервисом.
Если очередь пуста и ответов нет, попробуем «подтолкнуть» транспортный модуль. Разберем последовательность действий:
C:\UTM\transporter\logs) и очистим содержимое папки с логами.После этого проанализируем файл transport_info.log. В нем должны появиться записи о попытках соединения с сервером. Если мы видим ошибки типа 403 Forbidden или 500 Internal Server Error, это прямой признак проблем с ключом RSA или техническим обслуживанием на стороне РАР.
Важно убедиться, что вы используете актуальную версию модуля. Чтобы узнать номер версии, можно воспользоваться старым интерфейсом «домашней страницы» УТМ. В адресной строке браузера введем:
http://localhost:17645/home
Здесь на главной странице будет указана полная версия сборки. Если версия устарела, модуль может некорректно формировать структуру XML-запроса, что приведет к игнорированию его сервером ЕГАИС.
С выходом новых версий УТМ (4.2.0 и выше) изменились протоколы обмена. Если в вашей 1С в настройках ЕГАИС установлен старый протокол (например, V2), то запрос остатков может уходить в неверном формате. Рассмотрим подробнее, где это проверить:
В конфигурации 1С перейдите в раздел Администрирование — Настройки номенклатуры — Настройки обмена с ЕГАИС — удобнее через обработку автоматизации полного цикла обмена с ЕГАИС. Убедитесь, что для вашего рабочего места выбран актуальный формат обмена (рекомендуется V4 для последних версий УТМ).
Если ничего из вышеперечисленного не помогло, проанализируем ситуацию с локальной базой данных transportDB (поможет обработка восстановления корректного учета и переноса марок в ЕГАИС). Иногда внутренняя база УТМ (Apache Derby) «зависает» или повреждается.
Вариант решения А: Перезапись RSA-ключа. Зайдите в личный кабинет на сайте egais.ru, сформируйте новый RSA-ключ на ваш токен (Рутокен/JaCarta). Это обновит сертификат безопасности и восстановит связь с сервером.
Вариант решения Б (радикальный): Полная переустановка УТМ.
C:\UTM.Внимание: При этом действии вся история входящих документов, не загруженных в 1С, будет безвозвратно удалена!
Поскольку файлы с остатками (особенно по первому регистру) могут быть объемными, антивирусы или брандмауэры иногда блокируют входящий XML-пакет, считая его подозрительным из-за структуры. Чтобы исключить этот фактор, попробуем временно отключить защитное ПО и повторить запрос остатков через час.
Подведем итог: если остатки по складу не приходят более двух суток, скорее всего, вы либо попали под ограничение частоты запросов, либо в локальной базе УТМ произошел сбой. Начните с проверки статуса через check1.fsrar.ru и контроля входящей очереди через localhost:17645/opt/out. В большинстве случаев помогает простая перезапись RSA-ключа или обновление версии протокола в 1С.