После обновления конфигурации 1С:Розница до релиза 2.2.10 (и последующих версий) многие пользователи и администраторы столкнулись с крайне неприятной проблемой. В режиме Рабочего места кассира (РМК) при возникновении любой технической ошибки на кассовом аппарате (закончилась лента, пропала связь с фискальным регистратором, замялась бумага) в базе данных 1С начинают плодиться дублирующиеся проведенные чеки. На ККТ чек физически не распечатался, однако в системе регистрируется проведение документа. Кассир пытается пробить чек повторно — и в результате база наполняется проведенными «чеками-призраками» без фискальных номеров. Это ломает учет остатков, удваивает/утраивает выручку в отчетах и создает огромные риски при торговле маркированным товаром и алкоголем (ЕГАИС).
В этой статье мы подробно разберем, почему разработчики изменили логику работы программы, к каким последствиям это приводит и какими методами можно решить эту проблему как на уровне работы кассира, так и на уровне программного кода.
Для начала давайте проанализируем, почему старая и стабильная схема работы вдруг сломалась. В более ранних релизах 1С:Розницы процесс оформления продажи происходил по следующей цепочке:
Чек ККМ проводится в базе 1С с фиксацией списания товаров и поступления денег.Эта схема имела один существенный недостаток. Если в момент между печатью чека на ККТ и проведением документа в 1С происходил сбой (например, внезапно отключился компьютер или зависла сессия 1С), покупатель уходил с реальным бумажным чеком и товаром, а в базе данных продажа оставалась незафиксированной. Это приводило к пересортице, недостачам и требовало ручного проведения документов администратором.
Начиная с релиза 2.2.10, разработчики 1С кардинально изменили логику работы, сделав ее более «безопасной» с точки зрения транзакций базы данных:
Чек ККМ сначала записывается и проводится в базе 1С (товары списываются, резервируются).Но здесь возникла архитектурная недоработка интерфейса РМК. Если на шаге отправки команды ККТ возвращает ошибку (например, «Нет бумаги»), документ в базе 1С уже имеет статус «Проведен». Однако на экране кассира окно РМК не закрывается и продолжает отображать товары в корзине, предлагая завершить оплату. Кассир, видя, что бумажный чек не вышел, а товары все еще на экране, устраняет замятие бумаги и нажимает кнопку «Оплатить» еще раз. В этот момент РМК в фоновом режиме создает новый документ Чек ККМ, снова проводит его и пытается распечатать. Предыдущий проведенный чек так и остается «висеть» в базе данных в статусе проведенного, но без заполненных реквизитов номера смены и номера чека ККМ.
Если для обычных товаров дублирование чеков грозит «всего лишь» неверным списанием остатков и задвоением выручки в конце смены, то для розницы с подакцизной и маркированной продукцией это настоящая катастрофа:
Если у вас нет возможности оперативно обновить систему или внедрить доработки, необходимо строго проинструктировать персонал о правилах поведения при сбоях кассы. Разберем по шагам правильный алгоритм действий кассира:
Чек ККМ останется записанным в базе данных.Важное замечание по эквайрингу: Если оплата по банковскому терминалу уже прошла, а касса выдала ошибку до печати чека, во избежание повторного списания средств у покупателя кассиру следует временно перевести интеграцию с терминалом в ручной режим, выбрать «Пробить непробитый чек» и завершить операцию.
Если кассиры уже успели наплодить дублирующиеся документы, базу данных необходимо вычистить до момента закрытия кассовой смены. В противном случае документ Отчет о розничных продажах закроется с некорректными данными.
Выполним следующие действия:
Чеки ККМ.Для радикального решения проблемы на программном уровне технические специалисты используют механизм **расширений конфигурации**. Это позволяет не снимать конфигурацию с поддержки и гарантирует легкое обновление в будущем.
Рассмотрим логику доработки. Нам необходимо перехватить момент отправки чека на печать. Если фискальный регистратор возвращает ошибку, транзакция должна откатываться назад, а документ Чек ККМ — распроводиться, возвращаясь в статус «Не проведен» (или переводиться в статус «Отложен»).
Проанализируем пример кода, который можно внедрить в расширение конфигурации. Перехватываем процедуру печати чека в общем модуле или модуле менеджера оборудования:
&Вместо("ПробитьЧекНаФискальномРегистраторе")
Функция ИСТ_ПробитьЧекНаФискальномРегистраторе(ДокументСсылка, ПараметрыЧека, Отказ)
// Вызываем стандартный обработчик пробития чека
Результат = ПродолжитьВызов(ДокументСсылка, ПараметрыЧека, Отказ);
// Проверяем, успешно ли выполнена печать на ККТ
Если Отказ Или НЕ Результат Тогда
// Если ККТ вернула ошибку, отменяем проведение проведенного ранее чека
НачатьТранзакцию();
Попытка
Блокировка = Новый БлокировкаДанных;
ЭлементБлокировки = Блокировка.Добавить("Документ.ЧекККМ");
ЭлементБлокировки.УстановитьЗначение("Ссылка", ДокументСсылка);
Блокировка.Заблокировать();
ДокументОбъект = ДокументСсылка.ПолучитьОбъект();
Если ДокументОбъект.Проведен Тогда
ДокументОбъект.Записать(РежимЗаписиДокумента.ОтменаПроведения);
ЗаписатьЛогОшибки("Чек " + ДокументСсылка + " распроведен из-за ошибки ККТ.");
КонецЕсли;
ЗафиксироватьТранзакцию();
Исключение
ОтменитьТранзакцию();
ЗаписатьЛогОшибки("Не удалось отменить проведение чека: " + ОписаниеОшибки());
КонецПопытки;
КонецЕсли;
Возврат Результат;
КонецФункции
Используя данный подход, при возникновении ошибки на стороне кассового аппарата (например, замятие бумаги), документ автоматически лишается статуса «Проведен». Это позволяет кассиру устранить проблему и нажать кнопку печати повторно без риска задвоить движения по регистрам остатков и продаж.
Стоит отметить, что в более поздних версиях (начиная с Розницы 2.3 и в новой линейке Розница 3.0 / УНФ) разработчики 1С существенно доработали «Новое РМК». Контроль незавершенных операций фискализации стал строже. Были добавлены механизмы очереди чеков и автоматического фонового повтора фискализации, что минимизировало появление подобных ошибок. Тем не менее, базовая концепция «сначала запись в базу — потом отправка на ККТ» сохраняется, поэтому понимание логики работы этого механизма критически важно для любого администратора торговой точки.