Скидки выглядят простой темой ровно до первой распродажи, когда выясняется, что промокод складывается с акцией и товар уходит ниже себестоимости, а клиент в соседнем заказе получил меньше положенного, потому что правила сработали в другом порядке. Система скидок — это не «поле для процента» в админке, а логика, которую нужно спроектировать: какие скидки бывают, как они сочетаются, что важнее и где граница, ниже которой цена падать не должна.
В этой статье разберём, как спроектировать гибкую систему скидок и промокодов на 1С-Битрикс: чем купон отличается от скидки, как работают правила корзины, как задать приоритеты и совместимость, защитить маржу и синхронизировать цены с 1С. Порядок в ценообразовании и обмене помогает навести аудит и оптимизация 1С.
Коротко
- Скидка применяется автоматически по условиям, промокод — по вводу кода; в Битрикс купоны работают поверх правил корзины.
- Всегда явно задавайте приоритет и совместимость скидок, иначе клиент получает разную цену от случайного порядка правил.
- Ставьте нижний порог цены — складывающиеся скидки быстро уводят товар ниже себестоимости.
- Логика скидок на сайте и в 1С должна совпадать, иначе сумма заказа у клиента и в учёте разойдётся.
Почему скидки ломаются чаще всего
Скидочная система — одно из самых частых мест сбоев в интернет-магазине, и почти всегда причина не в платформе, а в отсутствии проектирования. Скидки заводят по одной, под конкретную акцию, не думая о том, как они будут сочетаться друг с другом. В итоге к моменту крупной распродажи в магазине десятки правил, между которыми никто не описал приоритеты.
Типичные последствия такого подхода:
- Непредсказуемая цена. Один заказ получает одну скидку, похожий — другую, потому что правила сработали в разном порядке.
- Цена ниже себестоимости. Акция, промокод и скидка за объём сложились, и магазин продал в минус.
- Расхождение с 1С. Сайт посчитал одну сумму, учётная система — другую, и заказ не сходится.
- Злоупотребления. Публичный промокод утёк и применяется массово там, где задумывался персональным.
Вывод простой: скидки нужно проектировать как систему, а не добавлять по случаю. До того как завести первое правило, стоит описать модель — виды скидок, их приоритеты, совместимость и границы. Тогда добавление новой акции не превращается в лотерею.
Скидки и промокоды: в чём разница
Эти два понятия часто путают, хотя в 1С-Битрикс они устроены по-разному и играют разные роли. Скидка — это автоматическое снижение цены, когда выполнены условия: сумма корзины достигла порога, в ней есть нужные товары, клиент из определённой группы, действует акционный период. Покупателю ничего вводить не нужно — скидка применяется сама.
Промокод (купон) — это код, который покупатель вводит вручную, чтобы активировать скидку. В Битрикс купон не существует сам по себе: он привязан к правилу работы с корзиной. Правило описывает саму логику скидки (что и на сколько дешевеет), а купон задаёт условие активации и ограничения — сколько раз можно применить, кому, до какой даты. То есть промокод — это «ключ», который включает заранее описанную скидку.
Правила работы с корзиной в Битрикс
Ядро скидочной системы в 1С-Битрикс — «Правила работы с корзиной» (иногда их называют скидками на корзину). Это конструктор, в котором каждое правило состоит из трёх частей: условие (когда применять), действие (что сделать с ценой) и параметры применения (приоритет, совместимость, срок).
- Условие. Логическое выражение: сумма корзины, наличие товаров категории, группа пользователя, дата, применённый купон.
- Действие. Что делать при выполнении условия: процент или сумма скидки на корзину, на товар, на доставку, подарок.
- Приоритет. Порядок, в котором правила проверяются относительно друг друга.
- Остановка применения. Флаг, прерывающий проверку последующих правил, если это сработало.
Именно связка «приоритет + остановка применения» определяет, сложатся скидки или магазин остановится на первой подходящей. Это самый важный и самый недооценённый механизм: без явной настройки правила применяются в порядке, который бизнес не контролирует. Реализация сложных условий часто уходит в код через обработчики событий корзины — а это уже уровень современного слоя данных платформы, про который мы пишем в материале про D7 ORM в 1С-Битрикс.
Виды скидок и условия срабатывания
Гибкая система строится из нескольких типов скидок, каждый под свою бизнес-задачу. Понимание их набора помогает не изобретать велосипед и не дублировать логику.
| Тип скидки | Условие | Бизнес-задача |
|---|---|---|
| По сумме корзины | Порог суммы заказа | Поднять средний чек |
| По объёму товара | Количество единиц | Стимулировать опт |
| По группе клиента | Дилер, опт, VIP | Дифференцировать цены |
| Акционная | Товар и период | Распродать позицию |
| Промокод | Ввод купона | Точечные и адресные акции |
| За первый заказ | Новый клиент | Привлечь покупателя |
Условия можно комбинировать: скидка на категорию только для оптовой группы в акционный период. Но чем сложнее условие, тем важнее, чтобы оно было явно описано и протестировано — запутанные многоуровневые условия труднее сопровождать и легче сломать при следующей акции.
Приоритеты и совместимость скидок
Главный вопрос проектирования — что происходит, когда к заказу подходит несколько скидок. Ответ должен быть задан явно, а не оставлен на волю случая. Есть три базовые стратегии совместимости.
- Взаимоисключение. Применяется одна, самая выгодная (или самая приоритетная) скидка, остальные игнорируются. Безопасно для маржи.
- Складывание. Скидки суммируются. Гибко, но опасно — нужен нижний порог цены.
- Группы совместимости. Одни скидки складываются между собой, другие — нет. Самый гибкий и самый сложный вариант.
В Битрикс это реализуется приоритетами и флагом остановки применения. Например, акционная скидка ставится с высоким приоритетом и остановкой — тогда промокод поверх неё не сработает. Или наоборот: скидка за объём и промокод помечены как совместимые и складываются, но с общим ограничением снизу.
Купоны: типы и ограничения
Промокоды в Битрикс различаются по тому, сколько раз и кем их можно применить. Выбор типа определяет, для какой акции купон годится и насколько он защищён от злоупотреблений.
- Одноразовый. Сгорает после первого применения. Годится для персональных и генерируемых пачками купонов.
- Многоразовый с лимитом. Действует заданное число раз суммарно. Для публичных акций с ограниченным бюджетом.
- Один на пользователя. Клиент не применит его дважды. Защищает от повторного использования публичного кода.
- С ограничениями. Срок действия, минимальная сумма, привязка к группе — сужают применение купона.
Для персональных акций (день рождения, реактивация, извинение за проблему) генерируют пачку уникальных одноразовых купонов и рассылают адресно. Для массовых — публичный многоразовый код с общим лимитом и сроком. Логи применения помогают заметить утечку: если публичный код вдруг массово применяется из разных аккаунтов, пора его отключать.
Нижний порог цены и защита маржи
Самая дорогая ошибка скидочной системы — продажа ниже себестоимости из-за сложения скидок. Когда акция, промокод и скидка за объём накладываются друг на друга, итоговая цена может уйти в минус, и магазин узнаёт об этом по итогам распродажи. Защита от этого — явный нижний порог, ниже которого цена не опускается, какие бы скидки ни сработали.
Реализуют защиту несколькими способами:
- Максимальная суммарная скидка. Ограничение на общий процент скидки по позиции или заказу.
- Минимальная цена товара. Порог, ниже которого цена не падает даже при всех скидках.
- Ограничение складывания. Запрет применять промокод поверх акционной цены.
- Контроль маржи. Скидка не может опустить цену ниже заданного процента от себестоимости.
Себестоимость и закупочные цены живут в учётной системе, поэтому контроль маржи чаще всего требует, чтобы эти данные были доступны при расчёте — либо приходили обменом, либо проверялись на стороне 1С при проведении заказа. Без этой связки нижний порог остаётся «на глаз».
Синхронизация цен с 1С
В большинстве магазинов на 1С-Битрикс цены и часть скидок приходят из 1С обменом, а промокоды и правила корзины работают на сайте. Это создаёт риск расхождения: сайт показал одну сумму, а учётная система при проведении заказа посчитала другую. Для клиента это выглядит как ошибка, а для бизнеса — как проблема учёта.
Чтобы суммы сходились, нужно договориться о разделении ответственности:
- Источник базовой цены. Обычно 1С — она ведёт цены и акционные цены по типам цен и группам.
- Место расчёта промокодов. Как правило, сайт — купоны и правила корзины удобнее держать в Битрикс.
- Передача итоговой скидки. Применённые на сайте скидки уходят в заказ и в 1С, чтобы учёт видел ту же сумму.
- Единая логика акций. Если акция ведётся в 1С, сайт не должен дублировать её своим правилом.
Настроить корректный двусторонний обмен ценами, скидками и итоговыми суммами заказа помогает автоматизация продаж и склада на 1С. Без согласованного обмена любая гибкая система скидок рано или поздно даёт расхождение между витриной и учётом.
Производительность на распродажах
Расчёт скидок происходит на каждое изменение корзины — добавление товара, смену количества, ввод купона. На распродаже это тысячи одновременных пересчётов, и сложные правила с тяжёлыми условиями превращаются в узкое место. Медленный расчёт скидок тормозит корзину именно тогда, когда трафик максимален.
Что держит скидки быстрыми под нагрузкой:
- Простые условия. Чем меньше тяжёлых проверок в правиле, тем быстрее пересчёт.
- Разумное число правил. Десятки активных правил проверяются на каждый пересчёт — лишние отключают.
- Быстрая проверка купонов. Проверка и списание купона не должны блокировать базу под нагрузкой.
- Нагрузочное тестирование. Логику скидок проверяют под нагрузкой до акции, а не во время неё.
Нагрузку распродаж закладывают в инфраструктуру заранее — иначе сайт ложится в пик, и скидки становятся неважны, потому что заказ вообще не оформить. Про фундамент под такие пики — материал про хостинг и инфраструктуру BitrixVM.
Когда нужна своя разработка
Для большинства магазинов штатных правил работы с корзиной и купонов достаточно: они закрывают скидки по сумме, объёму, группе, акции и промокоды. Собственная разработка нужна, когда логика выходит за пределы конструктора и её нельзя выразить стандартными условиями.
Типичные поводы для кастомного обработчика скидок:
- Программа лояльности. Накопительные уровни, баллы, сложные механики членства.
- Внешняя система лояльности. Скидки и баллы считаются в стороннем сервисе, а сайт применяет их результат.
- Нестандартные условия. Логика, которую невозможно собрать из стандартных полей правила.
- Динамическое ценообразование. Цена зависит от факторов, недоступных штатному конструктору.
Кастомную логику пишут поверх событий корзины, не ломая штатный расчёт, и часто оформляют отдельным модулем — так её проще сопровождать и обновлять. О подходе к разработке таких модулей — статья про разработку модуля Битрикс, а про выкатку изменений без простоя магазина — про CI/CD и деплой Битрикс.
Частые ошибки
- Нет матрицы совместимости. Скидки заводят по одной, приоритеты не описаны — цена непредсказуема.
- Складывание без порога. Акция плюс промокод уводят товар ниже себестоимости.
- Публичный код вместо персонального. Короткий промокод утекает и применяется массово.
- Расхождение с 1С. Сайт и учёт считают скидку по-разному, суммы заказа не сходятся.
- Тяжёлые правила на распродаже. Сложные условия тормозят пересчёт корзины в пик.
- Нет ограничений у купона. Промокод без срока, лимита и минимальной суммы применяют бесконтрольно.
- Всё в код сразу. Пишут кастомную логику там, где хватило бы штатных правил корзины.
Чек-лист проектирования
- Модель описана. Перечислены виды скидок, их условия и бизнес-задачи.
- Матрица совместимости готова. Задано, какие скидки складываются, а какие взаимоисключают друг друга.
- Приоритеты настроены. Порядок применения и остановка правил заданы явно в Битрикс.
- Нижний порог задан. Есть максимальная суммарная скидка или минимальная цена, защищающая маржу.
- Купоны ограничены. У промокодов заданы тип, срок, лимит и минимальная сумма.
- Цены синхронизированы. Логика скидок на сайте и в 1С согласована, итоговые суммы совпадают.
- Нагрузка проверена. Расчёт скидок протестирован под нагрузкой распродажи.
Вывод
Гибкая система скидок — это не набор процентов, а спроектированная логика с явными приоритетами, совместимостью и границами. На 1С-Битрикс инструментов достаточно: правила работы с корзиной и купоны покрывают почти все сценарии, а связка приоритета и остановки применения решает, сложатся скидки или нет. Проблемы начинаются не от нехватки возможностей, а от их бесконтрольного использования.
Начните с модели: опишите виды скидок, составьте матрицу совместимости, задайте нижний порог цены и ограничения купонов. Синхронизируйте логику с 1С, чтобы витрина и учёт видели одну сумму, и проверьте расчёт под нагрузкой до распродажи. Тогда добавление новой акции перестанет быть риском, а скидки будут работать на прибыль, а не против неё.
