Опыт настройки, кастомизации и боли в 1С

В этой статье — немного практики и живого опыта из мира рассчета бонусных баллов в ОК (отчеты комиссионера), 1С и вечного «а можно ещё вот такую механику?».

⸻

Почему бонусные системы — это не просто «процентик от суммы»

Если ты думаешь, что бонусы в 1С:Розница — это просто “5% от чека начислили, клиент потом списал”, то держи что скрывается под капотом:
1) Программы лояльности с многоуровневыми условиями;
2) Расчёт бонусов по определённым группам товаров;
3) Рассчет бонусов в ОК — только если это необходимо (Собсвенная доработка);
5) Бонусы, которые зависят от физ. лица, канала, региона, уровня карты и т.д.
6) Персональные скидки, акции, подарочные баллы, партнёрские накопления…

И всё это желательно “считать на лету”, интегрироваться с фронтом и не взорвать 1С.

⸻

Пример применения кастомного расчета ББ в ОК:

Кастомные доработки: расчёт ББ (бонусный баланс) в ОК и реализациях

Когда дело доходит до реализации бонусных механик по заказам из e-commerce, особенно в рамках документов “Отчёт комиссионера”, появляется масса нюансов.

Особенно если дело касается рассчета ББ в Рознице, а там отчетов комиссионера как таковых нет.

Например:
1) Бонусы начисляются только в конкретных случаях (предоплата, самовывоз, наличие дисконтной карты и т.д.);
2) Тип магазина влияет на расчёт — вводится перечисление в справочнике "ТипыМагазиновЕКОМ", где мы делим точки на ЕКОМЦС, ЕКОМУнивермаг, неЕКОМ;
3) Алгоритм расчёта бонусов зависит от двух дат: дата оформления заказа и дата выкупа (и это не всегда один и тот же день);
4) В документе “Реализация товаров” теперь появляются кастомные реквизиты:
4.1 ЕКОМ_КодСпособаДоставки
4.1 ЕКОМ_ЭтоОтчетКомиссионера

Даже визуально в форме документа реализуется подсветка/плашка — чтобы пользователь понимал, что он работает с ОК.

⸻

 Кастомизация справочников, регистров, обменов

Бонусные механики затронули всё:
1) Спр.СкидкиНаценки — добавляем булево этоПравилоНачисленияБонусов;
2) РегСв.ДействиеСкидокНаценок — вводим реквизит ДатаОкончанияВыкупаЕКОМ;
3) Документ.МаркетинговаяАкция — получает поле с ограничением по дате для ЕКОМ;

А ещё:
1) Создаём дополнительные обработки для массовой инициализации данных;
2) Переписываем алгоритмы расчёта скидок/бонусов для заказов ЕКОМ;
3) Устанавливаем правила обмена между УТ, ЦР и магазинами с учётом ЕКОМ-атрибутов.

⸻

Возвраты: самые сложные сценарии

Вот где боль особенно ощутима — это возвраты товаров и бонусов. В зависимости от сценария (аннулирование, заявка, чек, постоплата) — мы:
1) либо сторнируем начисленные бонусы;
2) либо возвращаем списанные;
2) либо… не делаем ничего (и это правильно).

Придумана и внедрена целая система классификации возвратов (в1–в6), по которой определяется:
1) Основание для возврата;
2) Источник начислений и списаний;
3) Что должно происходить по бонусам.

Пример:
в3 — возврат по заявке от розничного покупателя. Надо сторнировать начисленные бонусы по ОК (если была реализация), а списание брать из заказа.

⸻

Автоматизация расчёта: учёт в чеке, заказе и реализации

В ЧекККМ при выкупе заказа ЕКОМ бонусы считаются по спец. алгоритму
В РеализацияТоваров перед записью проверяем условия: если заказ ЕКОМ, есть карта, дата > X — выполняем расчёт бонусов по правилам ЕКОМ
Даже в возвратах учитываем дату заказа и настройки из ЕКОМНачалоРасчетаББДатаОфЗаказа

⸻

Вывод

Бонусные системы в рознице — это сложная экосистема из бизнес-правил, кастомных обработок, изменений в обменах и учёта десятков условий. Особенно если вы хотите:
1) считать бонусы корректно по каждому заказу;
2) учитывать лояльность даже при возврате;
3) и не сломать всё при передаче данных между 1С УТ, ЦР и фронтами.

⸻

P.S. Все инструменты и обработки, если они не под NDA, выложил в Telegram-канале.
также там разбираемся с интерсными кейсами из жихни и делимся опытом - присоеденяйся.