← На главную

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

Анализируем причину возникновения «фантомных чеков»

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

Проанализируем типовой сценарий сбоя:

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

В результате мы получаем ситуацию, когда по данным ФСРАР товар на остатках, а по данным УТМ и 1С — продажа не отменена.

Проверка фактических остатков и статуса марки

Прежде чем предпринимать радикальные действия, нам необходимо выяснить реальный статус марки в системе ЕГАИС. Мы не можем доверять только сообщениям в кассовом ПО.

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

1. Сформируем запрос QueryBarcode (Запрос штрихкода) через 1С или напрямую через интерфейс УТМ. Это позволит узнать, за какой Справкой 2 (или Справкой Б) числится данная бутылка.
2. Запросим остатки по регистру №1 (склад) и регистру №3 (поштучный учет). Если марка числится на остатках, значит, возврат в ЕГАИС действительно прошел.
3. Если марка числится проданной в ЕГАИС, но фактически бутылка у нас в руках, нам придется использовать Акт постановки на баланс (для старых марок) или документ Акт фиксации марок (для новых поштучных марок), чтобы вернуть ее в оборот.

Обновление фильтров и очистка локальной базы УТМ

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

Рассмотрим, как «оживить» УТМ:

Во-первых, проверим версию сборки УТМ. Для этого в браузере перейдем по адресу http://127.0.0.1:8080. Если версия устарела, необходимо обновить модуль до актуальной. Вместе с обновлением часто обновляется и Filter (внутренний механизм контроля), который может содержать исправления для подобных багов.

Во-вторых, выполним команду обновления фильтров. В некоторых случаях помогает запрос UpdateFilter, который принудительно синхронизирует локальные правила проверки с актуальными требованиями ФСРАР.

В-третьих, в критических случаях, когда локальная БД Derby повреждена, мы можем выполнить полную переустановку УТМ:

1. Остановим службы Transport и Transport-Updater.
2. Сделаем резервную копию папки transportDB.
3. Удалим содержимое папки с БД.
4. Запустим службы. УТМ создаст чистую базу данных, которая еще не «знает» о проблемных транзакциях и будет опираться только на актуальные запросы к серверу.

Корректировка данных в 1С:Розница (РТ 2)

В программе 1С:Розница (особенно версии 2.3) статус документа Чек ЕГАИС на возврат может «зависнуть» в состоянии «Ошибка передачи», хотя в ЕГАИС все прошло. Это блокирует дальнейшую работу кассира с этой позицией.

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

Посмотрим на пример логики, которую мы преследуем при ручной правке:

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

Реализация «чистой» продажи через УТМ

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

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

• Номер смены.
• Номер чека.
• Идентификатор кассы (KassaID).

Если эти данные различаются (например, кассу заменили или перепрошили), УТМ не сможет сопоставить продажу и возврат по своей локальной базе.

Итоговые рекомендации

Подводя итог, при возникновении бага с возвратами в УТМ, мы рекомендуем придерживаться следующего алгоритма:

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

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