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