Как реализовать накопительную скидку по картам лояльности без создания множества контрагентов в 1С:КА 2.4

← На главную

При внедрении программ лояльности в 1С:Комплексная автоматизация 2.4 (или 1С:УТ 11) специалисты часто сталкиваются с дилеммой. С одной стороны, бизнес хочет внедрить накопительную систему скидок («чем больше купил за все время, тем выше процент»), с другой — отдел продаж и ИТ-служба обоснованно боятся разрастания справочников Партнеры и Контрагенты за счет тысяч розничных покупателей. Разберем, как обойти ограничение системы, требующее обязательной привязки карты к партнеру для работы накопительных алгоритмов.

Почему типовой механизм требует создания партнера?

Проанализируем работу системы «под капотом». В типовой конфигурации условие предоставления скидки «За накопленный объем продаж» обращается к данным регистра накопления ВыручкаИСебестоимостьПродаж. Проблема заключается в том, что в этом регистре основным разрезом аналитики является АналитикаУчетаПоПартнерам. Реквизит КартаЛояльности в документах РеализацияТоваровУслуг или ЧекККМ является информационным и в стандартные регистры накопления продаж в качестве измерения не попадает.

Следовательно, чтобы система «увидела» историю покупок конкретного человека, ей нужно зацепиться за объект, который есть в регистрах — то есть за Партнера. Если использовать одну обезличенную карточку на всех, накопление будет общим. Если использовать одного партнера «Розничный покупатель» на всех, система не сможет отличить покупки Иванова от покупок Петрова.

Способ 1: Программная модификация алгоритма расчета скидок

Это наиболее гибкий путь, который позволяет оставить справочник партнеров чистым. Мы будем использовать обезличенные карты лояльности, где номером карты будет являться номер телефона клиента. Основная задача — переопределить логику сбора накоплений.

Рассмотрим алгоритм действий:

Создаем вид карты лояльности с типом «Обезличенная». Это позволит кассиру выбирать карту в заказе без необходимости создавать или выбирать партнера.
В настройках автоматической скидки используем тип «Внешняя обработка» или создаем расширение для модификации типового запроса расчета.
Пишем запрос, который будет суммировать обороты не по партнеру, а по документам, в которых указана данная КартаЛояльности.

Пример логики запроса в расширении для получения суммы накоплений по карте:


Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |	СУММА(Продажи.СуммаВыручки) КАК ОбъемПродаж
    |ИЗ
    |	(ВЫБРАТЬ
    |		ДокументПродажи.СуммаДокумента КАК СуммаВыручки
    |	ИЗ
    |		Документ.РеализацияТоваровУслуг КАК ДокументПродажи
    |	ГДЕ
    |		ДокументПродажи.КартаЛояльности = &КартаЛояльности
    |		И ДокументПродажи.Проведен
    |
    |	ОБЪЕДИНИТЬ ВСЕ
    |
    |	ГДЕ
    |		ДокументВозврата.КартаЛояльности = &КартаЛояльности
    |		И ДокументВозврата.Проведен) КАК Продажи";

Запрос.УстановитьПараметр("КартаЛояльности", ТекущаяКарта);
Результат = Запрос.Выполнить().Выгрузить();

Важный нюанс: при таком подходе необходимо обязательно учитывать документы возврата, чтобы клиенты не злоупотребляли системой, возвращая товар после фиксации накопления. Также стоит помнить, что прямой запрос по таблицам документов при очень больших объемах данных может работать медленнее, чем запрос к регистру накопления. Для оптимизации рекомендуется создать индекс по полю КартаЛояльности через расширение.

Способ 2: Использование доп. реквизитов для хранения оборотов

Если вы не хотите, чтобы система при каждом расчете скидки «перелопачивала» базу документов, можно использовать комбинированный подход. Выясним, как это реализовать:

Добавляем для справочника КартыЛояльности дополнительный реквизит НакопленнаяСуммаПродаж (тип Число).
Создаем подписку на событие при проведении документов РеализацияТоваровУслуг, ЧекККМ и ВозвратТоваровОтКлиента.
В обработчике события обновляем значение в дополнительном реквизите карты, которая указана в документе.

Проанализируем плюсы: расчет скидки в ЗаказеКлиента будет мгновенным, так как системе достаточно просто прочитать число из реквизита карты. Минусы: при отмене проведения документов или их редактировании задним числом нужно обеспечивать механизм пересчета этого реквизита.

Способ 3: Виртуальные партнеры с ограниченным доступом

Если программирование кажется слишком сложным, можно использовать типовой функционал, но минимизировать его вред для интерфейса. Рассмотрим этот вариант подробнее:

В настройках системы включите разделение на Партнеров и Контрагентов. В этом случае вы можете создавать тысячи «Партнеров» (физических лиц), привязывая их всех к одному-единственному «Контрагенту» (например, «Розничный покупатель»).

Чтобы справочник не пугал бухгалтерию и оптовых менеджеров, выполните следующие шаги:

Настройте Группы доступа партнеров. Создайте группу «Розничная сеть».
Ограничьте права доступа так, чтобы этих партнеров видели только кассиры и менеджеры розницы.
Используйте «Помощник регистрации клиента», настроив его так, чтобы создание связки «Партнер + Карта» занимало у кассира не более 30 секунд.

Преимущество этого метода: вы сохраняете полностью типовую конфигурацию, что гарантирует корректное обновление программы в будущем и работу всех стандартных отчетов по лояльности.

Резюме и рекомендации

Выбор решения зависит от масштаба вашей базы данных и готовности к поддержке кода. Если количество чеков в день исчисляется сотнями, а не тысячами, наиболее элегантным решением будет Способ 1 с прямой выборкой по документам в алгоритме скидки. Это избавит вас от дублей в справочниках и обеспечит актуальность данных «здесь и сейчас».

Если же вы планируете масштабную федеральную сеть, лучше посмотреть в сторону внешних систем лояльности, которые интегрируются с 1С через API. В этом случае 1С передает номер телефона во внешний сервис, а получает уже готовый процент скидки, не нагружая свою базу данных лишними оборотами и сущностями.