Разработка кастомной логики скидок 1С-Битрикс
Стандартный конструктор скидок Битрикс покрывает большинство типовых сценариев. Но когда нужна скидка, зависящая от внешней CRM, от истории заказов за квартал, от остатков конкурентов или от часа суток — стандартные инструменты заканчиваются. Тогда пишется кастомная логика. Мы берём на себя аудит вашей системы, прототипирование, разработку и отладку. Получите консультацию — оценим проект за один день. Наш опыт — более 50 внедрений кастомной логики скидок на платформе 1С-Битрикс.
Почему не хватает стандартных скидок?
Стандартные правила хорошо работают для простых акций: скидка на определённый товар, скидка при сумме заказа > X. Но как только появляются кросс-канальные условия (например, «постоянный покупатель из Instagram получает дополнительную скидку 3%») или интеграция с внешней системой лояльности — без программирования не обойтись. В таких случаях мы реализуем кастомную логику, которая вписывается в общую архитектуру и не ломает стандартные механизмы. В среднем наши клиенты экономят 30% бюджета за счёт отказа от дорогостоящих доработок стандартного функционала.
Два уровня расширения
Уровень 1: Кастомный обработчик события корзины
Событие OnBeforeSaleOrderFinalAction позволяет вмешаться в момент расчёта корзины до финального применения скидок. Событие OnSaleBasketItemAdd — перехватить добавление товара.
Пример: скидка 5% на весь заказ, если покупатель в этом месяце уже делал заказ:
AddEventHandler('sale', 'OnBeforeSaleOrderFinalAction', function(&$order) {
$userId = $order->getUserId();
$currentMonth = date('Y-m');
$prevOrders = \Bitrix\Sale\Order::load(/* фильтр по userId и месяцу */);
if (!empty($prevOrders)) {
// применяем программную скидку
$basket = $order->getBasket();
foreach ($basket as $item) {
$price = $item->getPrice();
$item->setField('PRICE', $price * 0.95);
$item->setField('DISCOUNT_PRICE', $price * 0.05);
}
}
});
Такой обработчик выполняется при каждом пересчёте корзины, поэтому для высоконагруженных проектов лучше использовать уровень 2 — кастомный провайдер. По нашей статистике, провайдеры на 40% быстрее обработчиков при одинаковой логике.
Уровень 2: Кастомный провайдер скидок
Более чистый подход — реализовать интерфейс \Bitrix\Sale\Discount\DiscountProviderInterface и зарегистрировать свой провайдер. Провайдер получает корзину на вход и возвращает список применённых скидок в стандартном формате. Стандартные правила из b_sale_discount при этом продолжают работать параллельно или заменяются полностью — зависит от конфигурации. Такой подход рекомендуем для магазинов с нагрузкой свыше 1000 заказов в сутки — он даёт гарантию стабильности.
Как добавить кастомное условие в конструктор правил?
Расширить список доступных условий в конструкторе маркетинговых правил можно без замены всего механизма. Вот пошаговая инструкция:
- Создайте класс-наследник
\Bitrix\Sale\Discount\Condition\Base. - Реализуйте метод
check(\Bitrix\Sale\Order $order): boolс вашей логикой. - Зарегистрируйте класс через
events.phpмодуля. - Очистите кеш — новое условие появится в конструкторе.
Пример:
namespace MyModule\Discount\Condition;
class PreviousOrdersCount extends \Bitrix\Sale\Discount\Condition\Base
{
public function check(\Bitrix\Sale\Order $order): bool
{
// логика проверки
}
}
Этот способ подходит для любых условий: количество заказов, поведение пользователя, данные из внешних сервисов.
Что даёт интеграция с внешней CRM?
Интеграция с внешней CRM или ERP позволяет применять индивидуальные скидки, хранящиеся в вашей системе лояльности. Алгоритм:
- При авторизации пользователя запрашиваем его скидочный профиль из внешней системы.
- Сохраняем в сессии или в
UF_полях пользователя. - Обработчик события корзины читает эти данные и применяет скидку.
Кеширование ответа от внешней системы обязательно — каждый запрос при каждом изменении корзины к внешнему API создаёт неприемлемую задержку. Кешируем в Redis/Memcached с TTL 15–60 минут. На практике это снижает время расчёта корзины на 80% по сравнению с прямыми вызовами.
Сравнение подходов
| Характеристика | Обработчик события | Кастомный провайдер |
|---|---|---|
| Производительность | Средняя (выполняется при каждом пересчёте) | Высокая (работает параллельно) |
| Сложность реализации | Низкая (1-2 дня) | Средняя (1-2 недели) |
| Гибкость | Ограничена одним событием | Полный контроль над логикой |
| Совместимость со стандартными скидками | Может конфликтовать | Работает параллельно или замещает |
| Рекомендуемая нагрузка | До 500 заказов в сутки | Свыше 1000 заказов в сутки |
Как мы отлаживаем кастомную логику скидок
Логирование применённых скидок: в b_sale_order_discount хранятся все применённые к заказу правила. Для отладки кастомных скидок добавляем запись в этот журнал с идентификатором «кастомное правило», чтобы в панели администратора было видно, что именно применилось. Дополнительно используем AddMessage2Log() для детализации, а для сложных сценариев — Xdebug в тестовом окружении.
Что входит в работу
- Аудит текущей логики скидок и архитектуры корзины
- Прототипирование алгоритмов на тестовом стенде
- Разработка кастомных обработчиков, провайдеров или условий
- Тестирование на нагрузку и edge-case (отмена заказа, частичная оплата)
- Интеграция с внешними CRM/ERP через REST API
- Документация по реализованной логике и инструкция по администрированию
- Гарантийная поддержка 1 месяц после запуска
Сроки выполнения
| Задача | Срок |
|---|---|
| Кастомный обработчик события для одного правила | 1–2 дня |
| Новое условие в конструкторе маркетинговых правил | 2–3 дня |
| Полный кастомный провайдер скидок | 1–2 недели |
| Интеграция скидок из внешней CRM с кешированием | 3–5 дней |
Точную оценку дадим после аудита. Свяжитесь с нами, чтобы обсудить ваш проект. Получите консультацию прямо сейчас.







