Что делать, если не приходит акт подтверждения на исходящую ТТН ЕГАИС при возврате товара?

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

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

Понимание цепочки документооборота ЕГАИС при возврате

Для начала проанализируем, как в норме должен проходить процесс возврата товара поставщику. Цепочка состоит из нескольких строго последовательных шагов:

1. Формирование и отправка ТТН: Отправитель (покупатель, оформляющий возврат) создает в 1С документ «ТТН ЕГАИС (исходящая)». При отправке 1С подписывает документ и передает его в локальный УТМ.
2. Передача на сервер ФСРАР: Локальный УТМ шифрует XML-пакет с помощью ключей ГОСТ/RSA и отправляет его на центральный сервер ЕГАИС.
3. Получение тикетов (квитанций): В ответ на отправку сервер ЕГАИС должен вернуть отправителю два тикета:
   • Первый тикет (Ticket 1): Подтверждает, что документ успешно доставлен на сервер ЕГАИС и принят в очередь на обработку.
   • Второй тикет (Ticket 2): Содержит результат проведения документа. Если проверка прошла успешно, документ проводится в ЕГАИС, ему присваивается уникальный идентификатор (например, TTN-0123456789 или международный WBRegId), а отправителю возвращается положительный тикет. Если обнаружены ошибки (например, нехватка остатков), возвращается тикет с описанием ошибки (отказ в проведении).
4. Получение документа поставщиком: Поставщик (получатель возврата) забирает ТТН из своего УТМ, проверяет товар и отправляет обратно «Акт подтверждения» (или акт расхождения/отказа).
5. Закрытие цепочки: Акт подтверждения проходит через сервер ЕГАИС и поступает в УТМ отправителя. Только после этого в 1С статус документа меняется на «Подтвержден».

Если цепочка прервалась, наша задача — выяснить, на каком именно этапе застрял документ. Для этого мы последовательно пройдем все шаги диагностики.

Шаг 1. Проверка отправки документа из 1С в УТМ

Часто пользователи ошибочно полагают, что если они нажали кнопку «Отправить» в 1С, то документ гарантированно ушел в ЕГАИС. Это не всегда так. Выясним, покинул ли документ учетную систему.

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

• Уникальный идентификатор транзакции (GUID).
• Подпись транзакции.
• Статус передачи в УТМ (успешно отправлено).

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

Шаг 2. Проверка домашней страницы УТМ

Перейдем к анализу самого транспортного модуля. Откроем в браузере домашнюю страницу УТМ. Нам понадобятся две вкладки:

• Исходящие (Outbox): Здесь хранятся документы, которые 1С передала в УТМ, но которые еще не были отправлены на сервер ФСРАР (например, из-за отсутствия интернета или проблем с криптоключом). Если вы видите там свою возвратную ТТН в статусе ожидания или ошибки — проблема локальная.
• Входящие (Inbox): Сюда поступают тикеты от ЕГАИС и акты от поставщиков. Если папка пуста, хотя вы точно знаете, что документы отправлялись, это повод проверить логи.

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

Шаг 3. Глубокий анализ логов УТМ (файл transport_info.log)

Это самый надежный способ узнать истинную причину проблемы. Лог-файлы службы транспорта УТМ фиксируют каждое действие: обращения 1С, подписание документов ключом, отправку на сервер ФСРАР и получение ответов.

Откроем лог-файл, который по умолчанию находится на диске по пути:

C:\UTM\transporter\l\transport_info.log

Рекомендуется использовать текстовый редактор с возможностью поиска (например, Notepad++). Нам необходимо найти записи, сделанные в момент отправки накладной из 1С. Выполним поиск по ключевым фразам.

Проанализируем основные типы записей, которые мы можем встретить:

1. Успешная отправка на сервер:
Если УТМ успешно подписал документ и отправил его во ФСРАР, мы увидим строки, содержащие информацию об отправке пакета на сервер:

2023-11-20 14:30:15,456 [pool-4-thread-2] INFO  ru.fsrar.wegais.transport.Transport - Отправка документа на сервер ЕГАИС (запрос типа WayBill_v4)...
2023-11-20 14:30:17,890 [pool-4-thread-2] INFO  ru.fsrar.wegais.transport.Transport - Документ успешно отправлен. ID транзакции: 1a2b3c4d-5e6f-7g8h...

2. Ошибки криптографии и подписи:
Если на аппаратном ключе (Рутокен, JaCarta) истек срок действия сертификата ГОСТ или RSA, либо служба ЕГАИС не может получить доступ к аппаратному ключу, в логах появятся ошибки вида:

2023-11-20 14:32:00,111 [pool-4-thread-2] ERROR ru.fsrar.wegais.transport.Transport - Ошибка подписания документа: expired certificate
2023-11-20 14:32:01,222 [pool-4-thread-2] ERROR ru.fsrar.wegais.crypto.KeyManager - Не удалось получить приватный ключ RSA. Проверьте подключение токена.

При обнаружении таких ошибок необходимо перезапустить службу УТМ, проверить работоспособность токена через Единый Клиент JaCarta или Панель управления Рутокен, а также проверить сроки действия сертификатов в Личном кабинете ЕГАИС.

3. Ошибки структуры XML-файла (схемы):
Если учетная система сформировала файл с нарушением XSD-схем ЕГАИС (например, не заполнено обязательное поле или указана неверная версия формата), УТМ откажется его отправлять:

2023-11-20 14:35:10,333 [pool-4-thread-2] ERROR ru.fsrar.wegais.transport.Transport - Ошибка валидации XML-документа: SAXParseException: cvc-complex-type.2.4.a: Invalid content was found starting with element...

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

Шаг 4. Проверка статуса накладной на портале check1.fsrar.ru

Если в логах УТМ зафиксирована успешная отправка на сервер ЕГАИС, но в 1С статус документа так и не обновился, воспользуемся официальным проверочным сервисом ФСРАР.

Рассмотрим порядок действий для проверки:

1. Переходим на сайт check1.fsrar.ru.
2. Выбираем вкладку «Поиск по Идентификатору накладной».
3. Вводим FSRAR ID отправителя (ваш уникальный идентификационный номер в системе ЕГАИС, его можно скопировать на домашней странице УТМ).
4. Вводим Идентификатор накладной. Обратите внимание: нужно вводить именно уникальный номер ЕГАИС (вида TTN-XXXXXXXXXX, также известный как WBRegId), а не внутренний номер документа из 1С.
5. Вводим защитный код с картинки и нажимаем кнопку поиска.

Возможные результаты поиска и наши действия:

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

Шаг 5. Проблема «Необеспеченного расхода» при возврате пива

Специфика возврата алкогольной продукции заключается в том, что в момент проведения ТТН на сервере ЕГАИС система пытается списать указанный объем продукции с баланса вашей организации. Если баланс пуст, система откажет в проведении. Для корректного отражения операций с алкоголем и отправки накладных применяется модуль обмена данными между 1С и ЕГАИС.

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

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

Шаг 6. Актуальная версия УТМ — критический фактор

Обратим внимание на версию УТМ, установленную на вашем рабочем месте. В процессе эволюции системы ЕГАИС старые версии программного обеспечения регулярно выводятся из эксплуатации ФСРАР.

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

Решение: Убедитесь, что у вас установлена актуальная версия УТМ (семейства 4.2.0 и выше). При необходимости выполните обновление транспортного модуля, предварительно создав резервную копию базы данных УТМ (папка transportDB) во избежание потери входящих документов.

Пошаговый алгоритм решения проблемы (Резюме)

Подведем итог и составим краткую инструкцию для быстрого устранения неполадки:

1. Проверяем, запущена ли служба УТМ и открывается ли локальная веб-страница по адресу http://localhost:8080/.
2. Заходим в 1С и смотрим протокол обмена ЕГАИС: убеждаемся, что документу присвоен внутренний GUID отправки.
3. Открываем файл лога transport_info.log и проверяем наличие ошибок подписания (криптографии) или ошибок XML-валидации в момент отправки.
4. Если лог сообщает об успешной отправке, копируем номер WBRegId (ТТН-...) и проверяем статус документа на портале check1.fsrar.ru.
5. Если статус на портале «Проведена», связываемся с поставщиком и просим его принудительно перезапросить ТТН в своем личном кабинете ЕГАИС и прислать акт подтверждения.
6. Если статус «Ошибка проведения», устраняем причину (перемещаем пиво с Регистра 2 на Регистр 1, проверяем остатки, актуализируем коды маркировки в системе «Честный Знак») и отправляем накладную повторно с новым номером.