Как реализовать расчет бонусов через внешнюю обработку в 1С:Розница?

← На главную

При внедрении программ лояльности в торговых сетях стандартных механизмов начисления бонусов часто оказывается недостаточно. Например, бизнесу может потребоваться сложный алгоритм: рассчитывать бонусы как процент от маржинальности товара (разница между розничной ценой и себестоимостью) или начислять баллы в зависимости от объема продаж за определенный период. Для реализации таких задач разработчики традиционно используют механизм внешних обработок.

Однако при попытке настроить произвольный расчет бонусов через внешнюю обработку в конфигурации 1С:Розница 2.х (а также в связанных решениях вроде «Управление торговлей 11» или «ERP Управление предприятием») многие сталкиваются с техническим ограничением: система начисляет рублевую скидку вместо бонусных баллов либо вовсе игнорирует алгоритм обработки. В этой статье мы подробно разберем, почему возникает эта проблема, проанализируем исходный код платформы и рассмотрим два надежных способа обхода этого ограничения.

В чем суть архитектурной проблемы?

В архитектуре маркетинговой подсистемы решений 1С механизмы обычных (денежных) скидок и бонусных баллов разделены на уровне системных перечислений. Когда мы регистрируем в справочнике внешнюю обработку с видом «Расчет скидки (наценки)», система ожидает, что результатом ее работы станет уменьшение стоимости товара в чеке в денежном выражении.

Давайте выясним причину, почему стандартная внешняя обработка расчета не может начислить бонусы. Обратимся к общему модулю СкидкиНаценкиСервер, а именно к функции ВыбратьПодчиненныеСкидки(). В типовом коде этого модуля жестко прописано условие отбора скидок, которые могут работать с бонусными баллами:


Если СтрокаСкидки.СпособПредоставления = Перечисления.СпособыПредоставленияСкидокНаценок.КоличествоБонусныхБаллов
    ИЛИ СтрокаСкидки.СпособПредоставления = Перечисления.СпособыПредоставленияСкидокНаценок.ПроцентОтСуммыВВидеБонусныхБаллов Тогда

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

---

Решение 1: Обход ограничения через расширение конфигурации

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

Разберем этот процесс по шагам:

Создайте новое расширение конфигурации в режиме «Конфигуратор».
Добавьте в расширение общий модуль СкидкиНаценкиСервер.
Найдите метод ВыбратьПодчиненныеСкидки() и переопределите его с помощью аннотации &Вместо или &ИзменениеИКонтроль.
Модифицируйте блокирующее условие, добавив проверку заполнения бонусной программы лояльности.

В результате модификации код условия должен выглядеть следующим образом:


Если СтрокаСкидки.СпособПредоставления = Перечисления.СпособыПредоставленияСкидокНаценок.КоличествоБонусныхБаллов
    ИЛИ СтрокаСкидки.СпособПредоставления = Перечисления.СпособыПредоставленияСкидокНаценок.ПроцентОтСуммыВВидеБонусныхБаллов 
    ИЛИ ЗначениеЗаполнено(СтрокаСкидки.СкидкаНаценка.БонуснаяПрограммаЛояльности) Тогда

Почему это работает? Добавление проверки ЗначениеЗаполнено(СтрокаСкидки.СкидкаНаценка.БонуснаяПрограммаЛояльности) позволяет системе понять: если для рассчитываемой скидки в пользовательском интерфейсе была указана конкретная бонусная программа, то результат, возвращаемый нашей внешней обработкой, является именно бонусными баллами, а не скидкой в рублях. Это полностью решает проблему интеграции нестандартных формул расчета бонусов.

---

Решение 2: Альтернативный обходной путь (без изменения кода базы)

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

Рассмотрим подробнее этот алгоритм настройки:

Создание штатной скидки: В пользовательском режиме создайте стандартную скидку с типом «Начисление бонусов» (процентом или суммой). Привяжите ее к необходимой бонусной программе лояльности. На этом этапе система получает корректный признак начисления бонусов по умолчанию.
Разработка внешней обработки условий: Вместо обработки типа «Расчет скидки (наценки)» создайте обработку с видом «Проверка условия предоставления скидки (наценки)».
Реализация логики в коде: В модуле внешней обработки в экспортной функции ПроверитьУсловие() напишите алгоритм анализа данных. Например, если вам нужно начислять бонусы по формуле (РозничнаяЦена - ЗакупочнаяЦена) * 10% * Количество, вы можете выполнять это вычисление прямо внутри проверки условий.
Передача параметров расчета: Чтобы передать динамически вычисленное значение бонуса в чек, разработчики часто используют запись рассчитанных коэффициентов во временную структуру ПараметрыРасчета, которая передается дальше по стеку вызовов и подхватывается стандартным механизмом начисления.

Этот подход сложнее в реализации, но он гарантирует абсолютную чистоту конфигурации и позволяет проходить любые аудиты безопасности в облачных сервисах.

---

Важные нюансы при расчете бонусов от закупочных цен (маржи)

Если вы реализуете алгоритмы, завязанные на расчет прибыли (разницы между розничной и закупочной ценами), обязательно учитывайте специфику работы кассовых мест (РМК):

Доступность данных на кассе: Если кассовые узлы работают в режиме распределенной информационной базы (РИБ) или через автономные рабочие места, данных о себестоимости или закупочных ценах на кассе может физически не быть в целях безопасности или для экономии объема базы данных. Убедитесь, что тип цен «Закупочная» (или регистр сведений с себестоимостью) выгружается на кассовые терминалы, иначе внешняя обработка вернет ошибку или нулевой результат.
Округление бонусных баллов: При расчете бонусов по формулам с процентами неизбежно возникают дробные числа. Настройте правила округления баллов в параметрах бонусной программы в пользовательском режиме «1С:Розницы», чтобы избежать расхождений в копейках при проведении чеков ККМ.

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