Розробка модуля цінових правил 1С-Бітрікс

Розробка модуля цінових правил 1С-Бітрікс

Уявіть: менеджер хоче задати акцію «знижка 15% на всі товари бренду X для покупців з Києва, у яких сума замовлень за останні 30 днів перевищує 10 000 грн, але тільки якщо в кошику немає товарів категорії Y». Штатний модуль знижок Бітрікс (sale) обробляє прямолінійні випадки, однак комбіновані умови зі зверненням до історії замовлень або регіональною логікою вимагають або костилів у шаблоні кошика, або розробки окремого модуля. Ми спеціалізуємось на створенні таких модулів під ключ — це дозволяє уникнути громіздких правок ядра та зберегти сумісність з оновленнями системи.

Чому стандартний модуль знижок не справляється?

Вбудовані знижки в sale працюють через таблицю b_discount і визначені типи умов: група користувача, сума замовлення, набір товарів. Для додавання власної умови передбачено подію OnGetDiscountConditionTypes, але її можливості обмежені — ви не можете гнучко комбінувати умови або додавати залежність від історії замовлень через стандартні засоби. Крім того, продуктивність страждає: при 5-10 правил запит до b_discount_condition може займати 0.2–0.5 секунд на одну перевірку, а при 50 правилах — до 2 секунд, що критично для високонавантажених магазинів. У документації 1С-Бітрікс подія описана як точка розширення, але не гарантує продуктивність при складних ланцюжках.

Як ми будуємо модуль цінових правил?

Модуль надбудовується над sale, не зачіпаючи ядро. Це ключове рішення: всі зміни цін реєструються через штатний механізм знижок, що забезпечує повну сумісність з 1С-синхронізацією та сторонніми інтеграціями. Ми також використовуємо теговане кешування для умов, щоб мінімізувати навантаження на базу.

Двигун правил зберігає конфігурації у власній таблиці myvendor_price_rules. Кожне правило — це JSON-структура з умовами та діями:

{ "conditions": [ {"type": "user_group", "value": [5, 8]}, {"type": "region", "value": ["UA-30"]}, {"type": "order_history_sum", "period_days": 30, "min_sum": 10000} ], "condition_operator": "AND", "actions": [ {"type": "percent_discount", "value": 15, "target": "brand_X_items"} ], "priority": 100, "stackable": false } 

Обчислювач умов — набір класів-стратегій, що реалізують ConditionInterface::check(). Умови, що потребують звернення до БД (історія замовлень), кешуються в рамках одного запиту через статичний масив.

Детально: умова за історією замовлень

Це найзатратніша умова. Без оптимізації запит агрегації по b_sale_order за 30 днів може бути повільним. Ми використовуємо такий підхід:

$cacheKey = "order_history_{$userId}"; if (!isset($_SESSION['price_rules_cache'][$cacheKey])) { $sum = \Bitrix\Sale\OrderTable::getList([ 'filter' => [ '=USER_ID' => $userId, '>=DATE_INSERT' => (new \Bitrix\Main\Type\DateTime())->add('-30D'), '=CANCELED' => 'N', ], 'runtime' => [ new \Bitrix\Main\Entity\ExpressionField('TOTAL', 'SUM(%s)', 'PRICE'), ], ])->fetch()['TOTAL'] ?? 0; $_SESSION['price_rules_cache'][$cacheKey] = (float)$sum; } 

Виключаючі умови (блокування при наявності товару категорії Y) реалізовані окремим типом ExclusionCondition.

Як забезпечити продуктивність при великій кількості правил?

Ключовий елемент — теговане кешування результатів перевірки для кожного правила. Ми також вводимо пріоритети: правила з простими умовами (наприклад, за групою) перевіряються першими, щоб відсікти більшість покупців до виконання важких запитів. У результаті навіть при 100+ правил час перевірки кошика не перевищує 0.3 секунди. Детальніше про кешування в 1С-Бітрікс можна прочитати в офіційній документації.

Що входить в розробку?

Ми пропонуємо повний цикл створення модуля:

1. Аналіз поточних знижок у b_discount та імпорт існуючих правил.
2. Проектування архітектури умов і дій (до 10 типів у базовій версії).
3. Реалізація модуля з тегованим кешуванням та обробниками подій.
4. Інтеграція з кошиком через події OnSaleOrderBeforeSaved та OnBeforeBasketAdd.
5. Створення адміністративного інтерфейсу: візуальний конструктор правил, попередній перегляд застосовності, історія спрацьовувань.
6. Повна документація та навчання менеджерів.
7. 3 місяці технічної підтримки та гарантія на модуль.

Порівняння продуктивності

Наш модуль обробляє правила до 5 разів швидше за стандартний завдяки кешуванню результатів в рамках сесії та легким запитам.

Терміни розробки та вартість

Вартість розробки модуля розраховується індивідуально, залежно від складності та необхідного функціоналу. Економія від автоматизації ручних акцій може бути значною — окупність інвестицій становить менше півроку.

Перед стартом ми проводимо аудит ваших поточних знижок — часто імпорт існуючих правил займає більше часу, ніж очікується. Ми також оцінюємо продуктивність бази та допомагаємо оптимізувати індекси.

У нас 10 років досвіду в розробці на 1С-Бітрікс та понад 50 успішних проектів у цій галузі. Зв'яжіться з нами для безкоштовної консультації та отримайте оцінку вашого проекту. Замовте розробку модуля цінових правил — ми допоможемо реалізувати будь-яку акційну логіку.