В розничной торговле подарочные сертификаты являются мощным инструментом привлечения покупателей и увеличения среднего чека. Однако при работе в распределенной розничной сети (РИБ) с использованием нескольких кассовых аппаратов технические специалисты часто сталкиваются со специфическими трудностями. В этой статье мы подробно разберем, как устроена логика гашения сертификатов в разных магазинах одной сети, и как решить распространенную проблему с ошибкой ККТ 36h («Некорректные параметры в команде») при продаже нескольких сертификатов на кассе.
---
Для начала разберем бизнес-логику работы с подарочными сертификатами в «1С:Розница». С технической точки зрения подарочный сертификат не является классическим товаром. Это бланк строгой отчетности, подтверждающий получение компанией авансового платежа от покупателя. Учет номиналов и жизненного цикла сертификатов ведется в разрезе серийных номеров.
Каждый подарочный сертификат имеет определенный статус в системе:
Да, типовой функционал «1С:Розница 2.2 / 2.3» полностью поддерживает кросс-магазинную оплату. Но для корректной работы этой схемы в распределенной информационной базе (РИБ) необходимо учитывать два важнейших фактора: синхронизацию данных и механизм списания серийных номеров.
Аспекты синхронизации данных:
Если покупатель приобретает сертификат в Магазине №1, документ Чек ККМ (или документ реализации) фиксирует смену статуса серийного номера на Продан. Чтобы этот сертификат можно было принять к оплате в Магазине №2, информация о продаже должна быть передана через центральный узел РИБ в базу Магазина №2.
Если обмен данными между точками происходит редко (например, раз в день), возникнет классическая коллизия: покупатель, мгновенно приехавший в другой магазин сети, не сможет отоварить карту. Касса Магазина №2 выдаст ошибку, так как в локальной базе этот серийный номер все еще имеет статус Создан, а не Продан.
Для минимизации задержек синхронизации мы рекомендуем использовать следующие подходы:
Развенчиваем миф о блокировке складов:
У многих начинающих специалистов возникает вопрос: если в регистре накопления ДвиженияСерийныхНомеров отправителем и получателем значатся конкретные склады торговых точек, не заблокирует ли система гашение сертификата на «чужом» складе?
Выясним причину: регистр ДвиженияСерийныхНомеров отвечает исключительно за складской учет физических «болванок» (пластиковых карт как бланков строгой отчетности). При продаже сертификата происходит физическое списание пластиковой карточки со склада Магазина №1. В Магазине №2 при гашении сертификата физическое движение пластика не происходит (он уже находится на руках у клиента). На кассе Магазина №2 оформляется финансовый зачет аванса. Система проверяет только финансовый статус серийного номера (что он действительно Продан), складской учет бланка на этой точке контролировать не требуется.
В практике розничной торговли часто возникает ситуация, когда руководство решает подарить сертификаты партнерам или клиентам в рекламных целях, минуя кассу. Если просто отдать пластиковую карту клиенту, в базе ее статус останется Создан. Оплатить покупку на кассе таким сертификатом будет невозможно.
Для реализации этой схемы необходимо выполнить ручную корректировку статусов. Мы можем использовать один из следующих вариантов:
Реализация товаров и услуг на контрагента (например, на самого директора или на статью представительских расходов) со 100% скидкой. Это переведет сертификат в статус Продан.Корректировка регистров для принудительного изменения состояния серийного номера в регистре сведений, отвечающем за статусы сертификатов.Давайте посмотрим на пример запроса, с помощью которого система проверяет текущее состояние сертификата перед пробитием чека оплаты:
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| СостоянияПодарочныхСертификатовСрезПоследних.Состояние КАК Состояние,
| СостоянияПодарочныхСертификатовСрезПоследних.Номинал КАК Номинал
|ИЗ
| РегистрСведений.СостоянияПодарочныхСертификатов.СрезПоследних(&Период, ПодарочныйСертификат = &Сертификат) КАК СостоянияПодарочныхСертификатовСрезПоследних";
Если срез последних возвращает состояние, отличное от разрешенного для продажи или гашения, кассир получит отказ в проведении операции.
---
Перейдем ко второй технической проблеме. Пользователи часто сталкиваются со сбоем: при продаже одного подарочного сертификата в чеке ККМ операция проходит штатно. Но как только кассир пытается пробить в одном чеке два и более сертификатов (или сертификат совместно с другими товарами, содержащими скидки), кассовый аппарат блокирует печать чека и выдает ошибку:
36h Некорректные параметры в команде для данной реализации ККТ
Эта ошибка характерна для фискальных регистраторов марок Атол и Штрих-М, работающих по протоколам ФФД 1.05 и ФФД 1.2.
Проанализируем ситуацию и выясним причину сбоя. Проблема кроется в математических округлениях и жестких правилах форматно-логического контроля (ФЛК), встроенных в прошивку самой кассы:
Цена * Количество = Сумма.36h (в десятичном виде — ошибка 54).---
Для устранения этой ошибки не требуется переписывать программный код или менять конфигурацию. Все необходимые инструменты уже встроены в типовой функционал интеграции ККТ с «1С:Розница».
Разберем по шагам процесс исправления настройки интеграции:
Рассмотрим подробнее физику процесса. Когда включен режим Разделять строки, алгоритм подготовки XML-пакета чека в 1С начинает работать следующим образом. Если система фиксирует математическую погрешность округления при расчете множества позиций, она программно дробит одну номенклатурную позицию на несколько строк в чеке с разными ценами (разница составит 1 копейку).
Например, вместо передачи в ККТ строки:
Подарочный сертификат 1000 руб. — 2 шт. на общую сумму 1999.99 руб. (скидка 1 коп.)
Программа передаст ККТ две раздельные строки:
1. Подарочный сертификат 1000 руб. — 1 шт. по цене 1000.00 руб.
2. Подарочный сертификат 1000 руб. — 1 шт. по цене 999.99 руб.
С точки зрения покупателя и итоговой суммы чека ничего не меняется — общая сумма к оплате остается абсолютно точной. Но с точки зрения логических проверок кассы математическое равенство 1 * Цена = Сумма выполняется идеально для каждой строчки. Конфликт округления внутри ККТ полностью исчерпывается, и ошибка 36h гарантированно пропадает.
---
Если после настройки форматно-логического контроля проблема сохраняется, рекомендуем выполнить следующие действия:
Применяя данные настройки, мы обеспечим бесперебойную продажу и гашение подарочных сертификатов по всей розничной сети без технических сбоев и задержек на кассовых узлах.