← На главную

При построении систем лояльности с дифференцированным процентом начисления бонусов (например, 5%, 7% или 10% в зависимости от суммы покупок за весь период) разработчики и аналитики сталкиваются с необходимостью выяснить, откуда конфигурация считывает историю продаж и где хранит результаты начислений. Разберем архитектуру хранения данных о продажах и бонусных баллах в «1С:Комплексная автоматизация» (а также в аналогичных конфигурациях «1С:ERP» и «1С:Управление торговлей»).

В каких регистрах хранятся данные о покупках и бонусах

Для корректной работы накопительных скидок и бонусных программ в системе используется разделение на два ключевых регистра накопления:

1. Регистр накопления ВыручкаИСебестоимостьПродаж. Это основной оборотный регистр, в котором фиксируются все продажи клиентам. Именно по нему типовой алгоритм автоматических скидок и бонусных программ вычисляет накопленный объем покупок партнера или по карте лояльности. В устаревших редакциях конфигураций (например, КА 1.1 или УТ 10.3) эту роль выполнял регистр накопления Продажи.
2. Регистр накопления БонусныеБаллы. Это регистр остатков, в котором хранятся непосредственно начисленные, списанные и доступные бонусные баллы в разрезе бонусных программ, карт лояльности и партнеров. Данные о самих покупках сюда не попадают — здесь учитываются только единицы внутренней программы лояльности.

Таким образом, когда требуется получить сумму выручки по клиенту за период для проверки условий начисления бонуса, запросы строятся именно к таблице оборотов регистра ВыручкаИСебестоимостьПродаж.

Как настраивается шкала начисления бонусов от объема покупок

Рассмотрим типовую схему настройки дифференцированного начисления бонусов в пользовательском интерфейсе:

1. Перейдем в справочник СкидкиНаценки и создадим группу скидок с правилом совместного применения «Максимум».
2. Внутри группы создадим отдельные элементы начисления с типом «Начисление бонусов процентом» для каждого порога (5%, 7%, 10%), привязав их к действующей бонусной программе.
3. Для каждого элемента настроим условие предоставления с типом «За накопленный объем продаж». В условии укажем критерий «не менее суммы порога» и зададим период «Весь период».
4. Благодаря правилу совместного применения «Максимум» программа автоматически выберет наибольший процент, порог накопления которого уже достигнут покупателем.

Важные нюансы и поведение системы при расчете

Проанализируем технические особенности, которые необходимо учитывать при настройке и контроле расчетов:

1. Флаг «Учитывать текущую продажу в накопленном объеме продаж». В настройке условия предоставления есть важный параметр. Если флаг установлен, то покупка, переводящая клиента через пороговую сумму, сразу рассчитывается по новому повышенному проценту на всю сумму документа. Если флаг снят, текущий чек рассчитается еще по старому проценту, а новая шкала начнет действовать только со следующей продажи.
2. Отсутствие ступенчатого дробления суммы чека. Типовой механизм не умеет разбивать сумму одной операции на части (например, начислить 5% на сумму до достижения порога и 7% на остаток, превышающий порог). Процент применяется ко всей сумме документа целиком. Если требуется непрерывный кусочно-линейный расчет, потребуется доработка логики расчета через внешнюю обработку скидок или расширение конфигурации.
3. Особенности розничной торговли (РМК и чеки ККМ). Документ ЧекККМ не делает непосредственных движений по регистру ВыручкаИСебестоимостьПродаж. Движения в регистр записываются документом ОтчетОРозничныхПродажах в момент закрытия кассовой смены. По этой причине покупки, совершенные клиентом в течение дня в розничной точке, увеличивают накопленный объем в регистре только после проведения вечернего отчета.
4. Возвраты товаров и корректировки. Документы ВозвратТоваровОтКлиента и КорректировкаРеализации формируют сторнирующие движения в регистре ВыручкаИСебестоимостьПродаж. Если покупатель оформляет возврат, его суммарный объем покупок уменьшается, что при следующей продаже может автоматически вернуть его на предыдущую, более низкую ступень начисления бонусов.