«3 по цене 2», «1+1», «каждый третий бесплатно» звучат как простые маркетинговые акции. Но в настройке скидок это могут быть совершенно разные задачи.
Если покупатель берет три одинаковых товара и одна единица должна стать бесплатной, в типовом механизме есть подходящий вариант — «Скидка количеством».
Если за два товара одной группы нужно выдать другой товар, это уже «Подарок» с отдельным условием предоставления.
Если покупатель выбирает любые три товара категории, а скидка должна равняться стоимости самого дешевого, типовой механизм тоже позволяет собрать такой сценарий, но настройка становится интереснее.
И совсем другой класс задачи появляется, когда маркетолог говорит:
- каждый второй товар — скидка 50%;
- каждый третий — 70%;
- каждый пятый — 99,99%;
- правила работают одновременно;
- при пересечении кратностей результат должен быть однозначным;
- самые большие проценты нужно предоставлять наиболее дешевым товарам выбранного сегмента.
Здесь уже недостаточно решить, какая карточка скидки нужна. Сначала приходится формализовать сам алгоритм.
Поэтому пойдем от простого к сложному: сначала соберем несколько полезных типовых акций, затем разберем границу типового механизма и посмотрим, как подключается собственный внешний способ расчета скидки.
Примечание по версиям. Механизм скидок используется в УТ 11, КА 2 и ERP 2, но расположение отдельных команд и состав формы менялись между релизами. Поэтому названия конкретных элементов интерфейса перед настройкой рабочей базы стоит сверять именно на своем релизе. Особенно это относится к старым веткам УТ 11.2 и КА 2.0.
Из каких частей состоит автоматическая скидка
Одна из причин, почему механизм скидок сначала кажется сложнее ожидаемого: автоматическая скидка — это не только процент или сумма.
| Часть настройки | Что определяет |
|---|---|
| Тип скидки | Что получает покупатель: процент, сумму, бесплатное количество, подарок и т. д. |
| Условия предоставления | Когда возникает право на скидку: сумма документа, количество товаров, время продажи, накопленный объем и другие условия |
| Предоставляется на | На какие товары разрешено предоставить рассчитанную скидку |
| Получатель | Где или для кого скидка действует: склад, соглашение, карта лояльности и другие варианты |
| Совместное применение | Что делать, если одновременно подходят несколько скидок |
Особенно полезно сразу разделить два вопроса:
Какие товары дают право на акцию?
и
На какие товары должна лечь рассчитанная скидка?
Это не обязательно один и тот же набор.
Например, можно купить два холодильника и получить кофеварку. Холодильники участвуют в проверке условия, а скидка должна примениться уже к подарочной кофеварке.
С чего начать настройку
В современных редакциях механизм автоматических скидок включается функциональной опцией «Автоматические скидки в продажах» в настройках CRM и маркетинга.
После этого становится доступен справочник «Скидки (наценки)».
Но создание карточки скидки само по себе еще не означает, что акция заработала.
Нужно проверить как минимум:
- способ назначения скидки;
- условия предоставления;
- область «Предоставляется на»;
- период действия;
- получателя скидки;
- группу совместного применения.
Если правило выглядит правильным, но в продаже ничего не происходит, эти пункты стоит проверить раньше, чем искать ошибку в коде.
Контрольный пример: 10% от определенной суммы
Начнем с обычной процентной скидки, потому что на ней хорошо видно разделение самой скидки и условия ее предоставления.
Допустим, хотим предоставить покупателю 10% при сумме документа от 30 000 рублей.
В самой скидке задаем примерно такую логику:
| Назначается | Автоматически |
| Тип | Скидка процентом |
| Размер | 10% |
| Предоставляется на | Любая номенклатура либо нужная нам группа товаров |
Затем отдельно создаем условие предоставления:
| Вариант условия | За разовый объем продаж |
| Показатель | Сумма |
| Область | В документе |
| Сравнение | Не менее |
| Значение | 30 000 |
Это условие подключаем к скидке.
После этого остается назначить скидку нужному получателю и ввести ее в действие.
Получается простая, но важная модель:
тип скидки определяет, что рассчитать, а условие — когда это рассчитывать.
Как посмотреть, почему скидка не сработала
Когда в базе десятки акций, смотреть только на конечную цену строки неудобно.
Для диагностики полезна информация о примененных скидках: там можно увидеть, какие правила участвовали в расчете и почему отдельная скидка не была предоставлена.
Это особенно важно, если одновременно существуют постоянные скидки клиента, сезонная акция, карта лояльности и специальное предложение на отдельную группу товаров.
Вместо изменения настроек наугад сначала полезно понять, на каком именно уровне правило перестало подходить.
Типовая акция «3 по цене 2» для одинакового товара
Теперь конкретная акция:
покупатель берет три одинаковые единицы товара, а платит только за две.
Если бесплатной становится часть количества того же самого товара, для этого существует тип «Скидка количеством».
Смысл настройки:
| Тип | Скидка количеством |
| Правило | Одна бесплатная единица из трех одинаковых |
| Назначение | Автоматически |
| Номенклатура | Товары, участвующие в акции |
Для классического «1+1» аналогично настраивается одна бесплатная единица из двух.
Что проверить после настройки
| Количество | Ожидаемый результат |
|---|---|
| 2 | Для акции «3 по цене 2» скидки нет |
| 3 | Одна бесплатная единица |
| 5 | Одна бесплатная единица |
| 6 | Две бесплатные единицы |
Уже здесь есть нюанс, который нужно согласовать с маркетологом: как считать характеристики товара.
Например, три футболки одной модели разных цветов — это три одинаковых товара с точки зрения акции или три независимых варианта?
Универсального ответа нет. Это часть бизнес-условия акции, а не техническая деталь.
Когда нужен именно «Подарок»
Изменим правило:
при покупке двух холодильников покупатель получает кофеварку.
Бесплатным становится уже не тот же товар, поэтому «Скидка количеством» здесь не подходит по смыслу.
Для такого сценария предназначен тип «Подарок».
Здесь появляются две разные группы номенклатуры:
| Группа | Роль |
|---|---|
| Холодильники | Их количество проверяется условием акции |
| Кофеварки | Из них предоставляется подарок |
Создаем условие «За разовый объем продаж», ограничиваем его сегментом холодильников и задаем необходимое количество.
Затем создаем скидку типа «Подарок» и определяем подарочную номенклатуру.
Получаем примерно такую конструкцию:
| Условие | В документе не менее двух товаров сегмента «Холодильники акции» |
| Тип скидки | Подарок |
| Подарок | Одна единица из сегмента «Кофеварки акции» |
| Предоставляется на | Подарочный сегмент |
Если кассиру или менеджеру нужно дополнительно напоминать о подарке, типовой механизм позволяет использовать отдельное действие «Выдача сообщения».
Это удобно: расчет скидки и пользовательское уведомление не приходится смешивать в одном самописном механизме.
Типовая «3 по цене 2» для разных товаров
А теперь более интересный вариант.
Покупатель берет любые три товара из акционной категории, а общая скидка должна равняться стоимости самого дешевого из них.
Например:
| Товар | Цена |
|---|---|
| Товар А | 1 000 |
| Товар Б | 1 500 |
| Товар В | 2 000 |
Размер скидки должен составить 1 000.
Один из практических вариантов собрать такой сценарий типовыми средствами — использовать «Подарок» со стоимостью одной самой дешевой единицы акционного сегмента и условием по количеству товаров этого же сегмента.
Последовательность настройки:
- Создать сегмент номенклатуры «Акция 3 по цене 2».
- Включить в него товары, которые могут участвовать в акции.
- Создать условие «За разовый объем продаж».
- Ограничить расчет условия акционным сегментом.
- Установить необходимое количество товаров.
- Создать скидку типа «Подарок».
- Размер подарка определить стоимостью одной самой дешевой единицы акционного сегмента.
- Проверить область «Предоставляется на».
- Если акция должна повторяться при 6, 9, 12 товарах, проверить кратность выполнения условия.
И здесь появляется нюанс, который легко пропустить.
«Самый дешевый бесплатно» и «скидка распределена по строкам» — не одно и то же
Типовой механизм в конечном счете рассчитывает денежную скидку.
Поэтому общая сумма скидки действительно может быть равна цене самого дешевого товара, но визуально сумма может распределиться между несколькими строками документа.
Например, при товарах на 1 000, 1 500 и 2 000 рублей итоговая скидка может составлять правильные 1 000 рублей, но это не обязательно означает, что в табличной части одна конкретная строка станет ровно нулевой.
Если для маркетинга, кассового чека, обмена с сайтом или аналитики важно именно отображение «этот товар бесплатный», проверять нужно не только общую сумму документа, но и фактическое распределение скидки по строкам.
Это хороший пример того, почему две одинаково звучащие бизнес-фразы могут требовать разных технических решений.
Кратность выполнения условия
Еще одна важная деталь типовых акций — должна ли акция повторяться.
Допустим:
за каждые три товара положен один подарок.
Тогда нужно заранее определить:
| Количество | Ожидаемое количество подарков |
|---|---|
| 3 | 1 |
| 5 | 1 |
| 6 | 2 |
| 9 | 3 |
Если маркетолог ожидает именно такое поведение, нужно проверять кратность выполнения условия.
Если акция должна давать подарок только один раз независимо от количества, настройка будет другой.
Несколько скидок одновременно
Отдельная важная часть механизма — группы совместного применения.
Предположим, у клиента одновременно появились:
постоянная скидка 5% и акционная скидка 10%.
Получит ли он 5%, 10%, 15% или другой результат?
Это определяется способом совместного применения.
| Способ | Что происходит |
|---|---|
| Минимум | Выбирается меньшая скидка |
| Максимум | Выбирается большая скидка |
| Сложение | Размеры скидок складываются |
| Умножение | Скидки применяются последовательно |
| Вытеснение | Остается скидка с более высоким приоритетом |
Например, две независимые скидки 5% и 10% в группе «Сложение» дадут 15%.
Но это не означает, что группой совместного применения удобно выражать любое сложное маркетинговое правило.
Группа отвечает за взаимодействие готовых скидок. Она не определяет сама по себе, что такое «каждый второй товар» или какой именно товар должен получить рассчитанный процент.
Когда обычная настройка начинает разрастаться
Теперь сформулируем акцию, ради которой типовых карточек уже становится недостаточно удобно.
| Кратность | Скидка |
|---|---|
| Каждый 2-й товар | 50% |
| Каждый 3-й товар | 70% |
| Каждый 5-й товар | 99,99% |
Причем:
- количество считается по всем товарам выбранного сегмента;
- количество внутри одной строки тоже участвует в расчете;
- все кратности работают одновременно;
- пересечения кратностей должны давать предсказуемый результат;
- самые большие проценты должны назначаться наиболее дешевым участвующим товарам.
Здесь появляется важное отличие.
Нам уже недостаточно ответить на вопрос «при каком количестве дать скидку».
Нужно решить сразу две независимые задачи:
1. Какой набор процентов положен документу при текущем количестве товаров?
2. Каким конкретно товарам документа назначить этот набор процентов?
Разберем пересечения на десяти товарах
Пусть в акционном сегменте десять товарных единиц.
Правила остаются прежними:
каждый второй — 50%, каждый третий — 70%, каждый пятый — 99,99%.
| Позиция | Сработавшее правило | Результат |
|---|---|---|
| 1 | Нет | 0% |
| 2 | Кратность 2 | 50% |
| 3 | Кратность 3 | 70% |
| 4 | Кратность 2 | 50% |
| 5 | Кратность 5 | 99,99% |
| 6 | Кратности 2 и 3 | 99,99% |
| 7 | Нет | 0% |
| 8 | Кратность 2 | 50% |
| 9 | Кратность 3 | 70% |
| 10 | Кратности 2 и 5 | 99,99% |
Здесь как раз обнаруживается то, что не видно в рекламной фразе «каждый N-й товар».
Позиция 6 одновременно является второй и третьей кратностью.
Позиция 10 одновременно является второй и пятой.
Как поступить при пересечении?
Универсально правильного ответа нет.
Возможны разные бизнес-правила:
- взять максимальный процент;
- сложить проценты;
- применить проценты последовательно;
- одно правило оставить на текущей позиции, второе перенести;
- ограничить суммарный процент заданным максимумом.
Это нужно определить до написания кода.
В рассматриваемом далее рабочем алгоритме выбрано конкретное правило:
проценты, пришедшиеся на одну расчетную позицию, складываются; результат ограничивается 99,99%; превышение не переносится на следующий товар.
Поэтому для шестой позиции 50% и 70% превращаются в 99,99%, а не в две разные скидочные позиции.
В результате для десяти товаров получается:
- 3 позиции со скидкой 99,99%;
- 2 позиции со скидкой 70%;
- 3 позиции со скидкой 50%;
- 2 позиции без скидки.
Но мы пока еще не выбрали реальные товары.
Почему сначала полезно рассчитать проценты, а потом выбирать товары
Предположим, участвующие товары стоят:
| 1 000 | 2 000 | 3 000 | 5 000 | 10 000 |
И алгоритм уже определил, что покупателю положены, например, 99,99%, 70% и 50%.
Если максимальный процент случайно достанется товару за 10 000, стоимость акции будет совсем другой, чем если тот же процент попадет на товар за 1 000.
Поэтому в рассматриваемой механике используется отдельное экономическое правило:
максимальный процент получает наиболее дешевый участвующий товар.
Следующий по величине процент получает следующий по цене товар и так далее.
Это не «оптимизация программы». Это часть бизнес-семантики самой акции.
Если маркетолог обещал покупателю другое правило выбора товаров, алгоритм должен быть другим.
Штатная точка расширения вместо изменения конфигурации
Для нестандартного способа расчета не обязательно переписывать типовую подсистему скидок.
УТ, КА и ERP предусматривают подключаемые внешние алгоритмы расчета скидок.
То есть типовая конфигурация по-прежнему отвечает за:
- справочник скидок;
- условия предоставления;
- получателей;
- группы совместного применения;
- общий запуск расчета;
- применение результата.
А внешняя обработка реализует только новую математику конкретного способа скидки.
Это значительно лучше, чем создавать параллельную систему скидок внутри документа продажи.
Как внешний алгоритм включается в штатный расчет
Ниже несколько небольших фрагментов из реальной внешней обработки.
Они показывают контракт интеграции и отдельные инженерные решения, но сама задача здесь важнее полного листинга исходного кода.
Например, обработка явно сообщает, что должна участвовать именно в момент штатного расчета скидок:
Функция СпособПрименения() Экспорт
Возврат Перечисления.СпособыПримененияСкидокНаценок.
ПрименитьВМоментРасчетаСкидокНаценок;
КонецФункции
Главная точка входа внешнего алгоритма имеет такой контракт:
Функция Рассчитать(
СкидкаНаценка,
Настройки,
Товары,
ПараметрыРасчета) Экспорт
РезультатРасчета =
СкидкиНаценкиСервер.ПустаяТаблицаСкидокСРасшифровкой();
// Здесь выполняется собственный алгоритм расчета.
Возврат РезультатРасчета;
КонецФункции
То есть внешний код получает не абстрактный документ, а контекст штатной подсистемы скидок, ее настройки и товарные строки.
Сегмент остается бизнес-настройкой, а не кодом
В рассматриваемом алгоритме акционный сегмент передается через настройки внешнего способа.
Его фактический состав получается штатным механизмом:
МассивТоваровСегмента =
СегментыСервер.МассивЭлементов(Сегмент);
Это важное архитектурное разделение.
Разработчику не приходится зашивать в обработку конкретные артикулы.
Маркетолог меняет состав сегмента штатными средствами, а внешний алгоритм продолжает применять к этому сегменту одно и то же правило расчета.
Первая неочевидная проблема: строка документа не равна одному товару
Допустим, документ содержит одну строку:
Футболка, количество 6.
Для акции «каждый третий товар» в этой строке две скидочные товарные единицы.
Если алгоритм будет считать только строки табличной части, он увидит одну строку вместо шести единиц и выдаст неправильный результат.
Поэтому в рабочем алгоритме количество рассматривается на уровне отдельных товарных единиц.
Сокращенный фрагмент фактической реализации:
Для НомерЕдиницы = 1 По Товар.Количество Цикл
СтрокаМатрицы = ТЗ.Добавить();
СтрокаМатрицы.КлючСвязи = Товар.КлючСвязи;
СтрокаМатрицы.Цена = Товар.Цена;
СтрокаМатрицы.НомерЕдиницы = НомерЕдиницы;
КонецЦикла;
Здесь важен не сам цикл, а модель данных:
кратность относится к товарным единицам, а итог потом нужно корректно вернуть в исходные строки документа.
Почему нельзя потом просто сгруппировать по номенклатуре
Одна и та же номенклатура может встретиться в документе несколько раз.
Например:
| Строка | Номенклатура | Характеристика | Цена |
|---|---|---|---|
| 1 | Футболка | Красная, M | 1 500 |
| 2 | Футболка | Синяя, L | 1 700 |
| 3 | Футболка | Красная, M | 1 400 |
Если после расчета схлопнуть все только по ссылке номенклатуры, можно вернуть скидку не в ту строку.
Поэтому реальная реализация должна сохранять связь с исходной строкой и достаточный набор признаков, чтобы обратное распределение было однозначным.
Это один из тех нюансов, которые обычно появляются только после проверки алгоритма на реальных документах.
Вторая проблема: одинаковые цены должны давать стабильный результат
Для распределения максимальных процентов товары нужно упорядочить по цене.
Но что будет, если три товара стоят одинаково?
Недостаточно просто сказать «сортируем по цене».
При равных ценах нужен дополнительный стабильный критерий. Иначе при повторных расчетах невозможно гарантировать один и тот же выбор равнозначной позиции.
В рабочем варианте это выражено одной строкой:
ТЗ.Сортировать(
"Цена, ПорядокСтроки, НомерЕдиницы");
Основной критерий — цена.
Исходный порядок строки и номер единицы используются как дополнительные критерии только для детерминированности.
Это не влияет на экономический смысл акции, но делает результат повторяемым.
Третья проблема: пересечение нескольких кратностей
Вернемся к шестой товарной позиции.
Она одновременно удовлетворяет правилу «каждый второй» и «каждый третий».
В фактической реализации проценты такой позиции накапливаются внутри одного акционного результата.
Ключевой фрагмент выглядит так:
СтрокаПозиции.ПроцентСкидки =
СтрокаПозиции.ПроцентСкидки + Процент;
После накопления применяется максимальное допустимое значение 99,99%.
Существеннее самого кода здесь семантика:
две кратности, совпавшие на одной позиции, не создают две разные товарные скидки.
Они создают одну скидочную позицию с объединенным результатом.
Поэтому, например, превышение после ограничения 99,99% не переносится на соседний товар.
Если бизнес хочет переносить его, это уже другой алгоритм.
Четвертая проблема: номер кратной позиции и реальный товар — разные сущности
Это, пожалуй, самая важная мысль во всей сложной схеме.
Номер 6 в последовательности нужен, чтобы понять, что на нем пересеклись кратности 2 и 3.
Но это совершенно не означает, что скидка обязательно должна достаться шестому товару документа.
После определения всех пересечений условные номера выполнили свою задачу.
Теперь у нас есть набор скидок:
99,99%, 99,99%, 99,99%, 70%, 70%, 50%, 50%, 50%.
И отдельно есть реальные товары с фактическими ценами.
Только после этого применяется экономическое правило распределения: большие проценты сопоставляются с более дешевыми товарами.
Именно такое разделение позволяет не путать математику кратностей и выбор конкретных скидочных товаров.
Почему это важно для маржи
Возьмем упрощенный пример.
Есть три товара:
| Товар | Цена |
|---|---|
| А | 1 000 |
| Б | 3 000 |
| В | 10 000 |
И рассчитаны проценты:
99,99%, 70% и 50%.
Если 99,99% достанется товару за 10 000, денежная скидка только по нему практически равна 10 000.
Если правила маркетинговой акции разрешают выдавать максимальный процент наиболее дешевому товару, тот же процент применяется к позиции за 1 000.
Поэтому правило распределения нельзя оставлять на случайный порядок строк документа.
Оно должно быть явно определено как часть акции.
Возвращаем результат типовому механизму
Еще один важный инженерный момент: после вычисления суммы внешняя обработка не должна самостоятельно переписывать цены документа.
Готовый результат передается обратно штатному механизму скидок.
В реальном коде это выглядит так:
СкидкиНаценкиСервер.ПрименитьЗначениеСкидкиКТовару(
СкидкаНаценка,
СтрокаСкидки.СуммаСкидки,
Товар,
РезультатРасчета,
ПараметрыРасчета);
То есть внешняя обработка отвечает за свою математику, а типовая конфигурация продолжает владеть дальнейшим применением результата.
Это позволяет не создавать второй независимый контур скидок поверх существующего.
Настройки сложной акции тоже не должны быть зашиты в коде
Если проценты и кратности будут константами в модуле, любое изменение маркетинговой акции потребует программиста.
Поэтому для внешнего способа логичнее хранить настройку как таблицу:
| Кратность | Скидка, % |
|---|---|
| 2 | 50,00 |
| 3 | 70,00 |
| 5 | 99,99 |
Плюс отдельно выбирается сегмент номенклатуры.
При такой модели маркетолог может создавать совершенно разные акции одним и тем же способом расчета.
Например:
| Акция | Правила |
|---|---|
| Каждый второй дешевле | 2 = 50% |
| Классическая 1+1 | 2 = 99,99% |
| Три уровня стимулирования | 2 = 30%, 3 = 50%, 5 = 70% |
| Сложная промоакция | 2 = 50%, 3 = 70%, 5 = 99,99% |
Алгоритм остается один, меняются только бизнес-настройки.
Что обязательно валидировать в настройках
Чем гибче пользовательская настройка, тем легче получить бессмысленное правило.
Например:
- кратность равна нулю;
- процент не задан;
- нет ни одного правила;
- одна кратность введена дважды;
- не выбран сегмент.
Такие ошибки лучше запрещать в настройке, а не пытаться угадывать намерение пользователя уже во время расчета документа.
И серверный расчет не должен слепо полагаться только на корректность формы: базовые инварианты стоит проверять и перед выполнением алгоритма.
Отдельно о дробном количестве
Алгоритм «каждый второй товар» естественно работает с дискретными единицами.
Одна строка с количеством 6 означает шесть товарных единиц.
Но что означает «каждый третий» для 4,75 кг товара?
Универсального ответа нет.
Если в акционном сегменте возможна продажа дробным количеством, бизнес-правило нужно определить отдельно до использования алгоритма.
Нельзя автоматически переносить семантику штучного товара на весовой.
Что проверять перед запуском такой акции
| Сценарий | Что проверяем |
|---|---|
| Количество меньше первой кратности | Скидки нет |
| Количество равно кратности | Появляется ровно одна ожидаемая скидка |
| Несколько повторений одной кратности | Правило повторяется требуемое число раз |
| Пересечение двух кратностей | Работает согласованная семантика пересечения |
| Пересечение трех правил | Корректно применяется верхнее ограничение |
| Несколько единиц в одной строке | Считаются единицы, а не строки |
| Одинаковая номенклатура в нескольких строках | Результат возвращается в правильную исходную строку |
| Разные характеристики | Не смешиваются разные товарные позиции |
| Товар вне сегмента | Не участвует ни в количестве, ни в распределении |
| Одинаковые цены | Результат повторяем при повторном расчете |
| Сильно различающиеся цены | Проверяется экономическое правило распределения процентов |
| Одновременно работает другая скидка | Проверяется группа совместного применения |
| Количество изменили после расчета | Повторный расчет полностью перестраивает результат |
Когда внешний алгоритм вообще не нужен
После всех этих деталей может возникнуть обратное заблуждение: будто для любой акции лучше сразу писать обработку.
Нет.
Если бизнес-правило полностью выражается типовым механизмом, типовая настройка обычно проще и дешевле в сопровождении.
| Задача | Первый вариант, который стоит проверить |
|---|---|
| Три одинаковых товара, один бесплатно | Скидка количеством |
| Две одинаковых единицы, одна бесплатно | Скидка количеством |
| Купить товары одной группы и получить другой товар | Подарок и условие предоставления |
| Общая скидка равна стоимости самого дешевого товара из набора | Подарок с условием по сегменту и проверкой фактического распределения |
| Обычная процентная скидка по сумме или количеству | Типовая процентная скидка и условие |
| Несколько независимых скидок | Группа совместного применения |
Внешний способ становится интересен тогда, когда появляется именно новая математика одной акции.
Когда внешний способ расчета становится естественным
Для рассмотренного примера признаки уже хорошо видны:
- количество считается совместно по сегменту;
- одновременно существует несколько кратностей;
- каждой кратности соответствует свой процент;
- пересечения имеют собственное бизнес-правило;
- нужно учитывать количество внутри строк;
- рассчитанный набор скидок распределяется между товарами по отдельному критерию;
- при одинаковой цене результат должен оставаться детерминированным.
Попытка представить всё это несколькими независимыми карточками скидок возможна далеко не всегда удобно.
И главное — человеку, который потом будет сопровождать такую акцию, придется понимать взаимное влияние нескольких правил.
Одна настраиваемая внешняя скидка в таком случае может быть проще именно как единый бизнес-объект:
сегмент + таблица кратностей + однозначный алгоритм распределения.
Не забываем о группах совместного применения
Внешний способ не живет вне типовой подсистемы.
Он становится одной из скидок общего дерева.
Поэтому после проверки собственной математики нужно отдельно проверить взаимодействие с:
- персональной скидкой клиента;
- скидкой по карте лояльности;
- сезонной акцией;
- другой автоматической скидкой на те же товары;
- ручной скидкой, если она используется в бизнес-процессе.
Правильный собственный алгоритм внутри неправильно настроенной группы совместного применения все равно даст неправильный бизнес-результат.
Как выбирать между типовой настройкой и разработкой
Я бы использовал простой порядок.
Сначала точно записать правило акции человеческим языком.
Не «3 по цене 2», а:
«При наличии любых трех товаров сегмента стоимость одной самой дешевой единицы должна стать скидкой; правило повторяется на каждые три товара».
Или:
«По общему количеству товаров сегмента каждый второй дает 50%, каждый третий 70%, каждый пятый 99,99%; пересечения суммируются до 99,99%; большие проценты предоставляются более дешевым товарам».
После такой формализации обычно становится понятно, какой путь проще.
Если задачу выражает «Скидка количеством», «Подарок», обычное условие и группа совместного применения — лучше сначала использовать их.
Если же приходится придумывать отдельную математику расчетных позиций, пересечений и распределения — это уже хороший кандидат на внешний способ расчета.
Итог
Типовой механизм скидок УТ, КА и ERP закрывает гораздо больше задач, чем может показаться при первом знакомстве.
Для одинакового товара есть «Скидка количеством». Для подарочного товара — «Подарок». Условия предоставления позволяют отдельно определить момент возникновения акции, а «Предоставляется на» — товары, на которые должна лечь скидка. Группы совместного применения управляют конфликтами нескольких скидок.
Поэтому далеко не каждая акция «1+1» или «3 по цене 2» требует разработки.
Но как только появляется несколько кратностей с разными процентами, собственная семантика пересечений, подсчет физических товарных единиц и специальное распределение скидок по цене, задача уже становится алгоритмической.
И здесь полезно не переписывать подсистему продаж, а воспользоваться предусмотренной точкой расширения и вернуть рассчитанный результат обратно штатному механизму скидок.
Если требуется именно рассмотренный сложный вариант — несколько кратностей и процентов в одной акции, учет пересечений и назначение максимальных процентов наиболее дешевым товарам сегмента — готовая реализация доступна отдельно: «Акции 3 по цене 2 / 1+1 / каждый N-й товар со скидкой для УТ 11.2-11.6, КА 2.0-2.6 и ERP».
Код решения открыт, поэтому его можно использовать как готовый рабочий механизм или изучить целиком уже на полноценной реализации, а не на изолированных фрагментах из статьи.
Вступайте в нашу телеграмм-группу Инфостарт