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