Проблема двойного пробития чеков стала массовой после перехода конфигурации 1С:Розница на версии 2.3.5 и выше. Ситуация выглядит следующим образом: кассир закрывает чек в РМК, ККТ печатает документ, но через несколько секунд (или при следующем пробитии) касса выдает еще один идентичный чек. В базе при этом может появиться второй документ Чек ККМ, который часто остается непроведенным, но имеет статус "Пробитый". Разберем по шагам, почему это происходит и как программно или административно решить эту проблему.
Главным виновником "двоения" является механизм асинхронной фискализации, реализованный через регистр сведений ОчередьЧековККТ. Рассмотрим подробнее, как это работает. В современных версиях 1С при нажатии кнопки оплаты данные не отправляются на кассу мгновенно. Вместо этого программа записывает данные чека в этот регистр. Специальное фоновое задание или обработчик в РМК "подхватывает" запись из очереди и инициирует фискализацию на ККТ.
Проблема возникает в момент, когда происходит сбой связи или задержка ответа от кассы (особенно актуально для ФФД 1.2 и маркировки). Если 1С отправила команду на пробитие, но не получила подтверждения от ККТ в течение установленного тайм-аута, система считает, что произошла ошибка. Запись в очереди получает статус Ошибка. Однако физически касса могла уже начать печать или даже успешно закрыть чек. При следующей попытке фискализации (или при автоматическом перезапуске очереди) 1С видит запись со статусом Ошибка и отправляет ее на ККТ повторно. В итоге мы получаем два чека в ОФД и две бумажные ленты.
Проанализируем ситуацию со стороны оборудования. Одной из частых причин является слишком короткое время ожидания ответа от ККТ. При работе с маркированным товаром касса тратит значительное время на проверку кодов в системе "Честный ЗНАК". Если тайм-аут в 1С установлен по умолчанию (например, 5 или 10 секунд), программа успевает "отвалиться" по ошибке раньше, чем касса вернет статус успеха.
Рекомендуем выполнить следующие настройки:
Если настройка тайм-аутов не помогает, проанализируем код, отвечающий за выборку чеков из очереди. Проблема часто кроется в том, что система пытается повторно пробить чеки, помеченные как ошибочные. Посмотрим на функцию ЧекиВОчередиНаФискализацию в общем модуле МенеджерОборудованиеЧекопечатающиеУстройстваВызовСервера.
В типовом коде запрос к регистру ОчередьЧековККТ выглядит примерно так:
Запрос = Новый Запрос(
"ВЫБРАТЬ
| ОчередьЧековККТ.ИдентификаторЗаписи КАК ИдентификаторЗаписи,
| ОчередьЧековККТ.СтатусЧека КАК СтатусЧека,
| ОчередьЧековККТ.ДанныеЧека КАК ДанныеЧека
|ИЗ
| РегистрСведений.ОчередьЧековККТ КАК ОчередьЧековККТ
|ГДЕ
| (ОчередьЧековККТ.СтатусЧека = ЗНАЧЕНИЕ(Перечисление.СтатусЧекаККТВОчереди.Новый))
| ИЛИ (ОчередьЧековККТ.СтатусЧека = ЗНАЧЕНИЕ(Перечисление.СтатусЧекаККТВОчереди.Ошибка))
|УПОРЯДОЧИТЬ ПО
| ОчередьЧековККТ.Дата УБЫВ");
Проблема здесь в условии ИЛИ СтатусЧека = Ошибка. Для решения проблемы можно создать расширение и переопределить этот запрос, убрав автоматическую повторную фискализацию ошибочных чеков. Это заставит систему игнорировать "проблемные" записи до ручного вмешательства администратора, предотвращая автоматический дубль.
Если дубли уже появились, кассирам сложно с ними работать: один чек проведен, второй висит непроведенным, но имеет статус "Пробитый". Изменить его типовыми средствами невозможно. Проанализируем способы ручного лечения ситуации, предложенные опытными пользователями:
Чеки ККМ кнопку, позволяющую программно менять статус чека. Если вышло два чека, кассир должен пометить второй чек как "Пробитый", провести его и тут же сделать на его основании Чек на возврат, чтобы выровнять остатки и кассу.РегистрСведений.ОчередьЧековККТ. Если там висят записи в статусе Ошибка, которые фактически уже пробиты, их нужно удалять или вручную переводить в статус Фискализировано.Разберем влияние прошивок. Для владельцев ККТ Атол критически важно обновить прошивку до актуальных версий (платформа 5.0). Старые прошивки (например, ветка 5.7.10) имели внутренние баги обработки очередей, которые признавал сам производитель. Аналогично для Штрих-М и Вики Принт — работа с маркировкой требует последних обновлений внутреннего ПО кассы для корректной обработки длинных пауз при связи с ИС МП.
Резюмируем: Основное лечение симптоматическое — увеличиваем тайм-ауты и обновляем прошивки. Кардинальное решение — модификация кода 1С через расширение, чтобы система не пыталась "самостоятельно" перепробивать чеки, завершившиеся с неопределенным статусом или ошибкой тайм-аута.