Розробка кастомної логіки знижок 1С-Бітрікс під ключ

Розробка кастомної логіки знижок 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 замовлень на добу — він дає гарантію стабільності.

Як додати кастомну умову в конструктор правил?

Розширити список доступних умов у конструкторі маркетингових правил можна без заміни всього механізму. Ось покрокова інструкція:

1. Створіть клас-спадкоємець \Bitrix\Sale\Discount\Condition\Base.
2. Реалізуйте метод check(\Bitrix\Sale\Order $order): bool з вашою логікою.
3. Зареєструйте клас через events.php модуля.
4. Очистіть кеш — нова умова з'явиться в конструкторі.

Приклад:

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% порівняно з прямими викликами.

Сценарій з реального проекту

Для інтернет-магазину побутової техніки ми реалізували знижку на основі кількості замовлень за останній квартал. Завдання: постійні покупці з 3+ замовленнями за квартал отримують додаткову знижку 5% на весь кошик. Використали кастомний провайдер, який перевіряв історію замовлень через API CRM. Провайдер кешував результат на 30 хвилин. У результаті час розрахунку кошика зріс лише на 2%, а повторні продажі збільшилися на 15% за перший місяць.

Порівняння підходів

Як ми налагоджуємо кастомну логіку знижок

Логування застосованих знижок: у b_sale_order_discount зберігаються всі застосовані до замовлення правила. Для налагодження кастомних знижок додаємо запис у цей журнал з ідентифікатором «кастомне правило», щоб у панелі адміністратора було видно, що саме застосувалося. Додатково використовуємо AddMessage2Log() для деталізації, а для складних сценаріїв — Xdebug у тестовому середовищі.

Що входить у роботу

• Аудит поточної логіки знижок та архітектури кошика
• Прототипування алгоритмів на тестовому стенді
• Розробка кастомних обробників, провайдерів або умов
• Тестування на навантаження та edge-case (скасування замовлення, часткова оплата)
• Інтеграція із зовнішніми CRM/ERP через REST API
• Документація по реалізованій логіці та інструкція з адміністрування
• Гарантійна підтримка 1 місяць після запуску

Терміни виконання

Точну оцінку дамо після аудиту. Зв'яжіться з нами, щоб обговорити ваш проект. Отримайте консультацію прямо зараз.