Дилер отримує каталог із цінами, які не збігаються з опублікованими. Знижки на групу товарів не дають потрібної гнучкості: кожен оптовик вимагає персональну вартість за договором. Стандартний механізм CCatalogDiscount зав'язаний на типи цін і відсотки — неможливо зафіксувати абсолютне значення, яке не змінюється при перерахунку базової ціни. Контрактні ціни вирішують це завдання: фіксований запис в окремому сховищі перекриває будь-які знижки, але тільки для конкретного контрагента на термін дії договору.
Наша реалізація на Highload-блоках і кастомному провайдері цін обробляє до 100 000 контрактних записів за 50 мс на замовлення. Спираємося на власний досвід: понад 7 років роботи з Бітрікс, 50+ проєктів для дилерських мереж. Гарантуємо пріоритет контрактної ціни над будь-якими акціями. Кешування в Redis з інвалідацією при зміні договору забезпечує мінімальний час відгуку для 500 одночасних користувачів. Перша демонстрація роботи — через 3 дні після початку проєкту.
Чому стандартні знижки не підходять
Модуль catalog надає знижки (CCatalogDiscount) та типи цін (b_catalog_group). Знижки задаються у відсотках або сумі, прив'язані до типу ціни. Для контрактних цін це не годиться: якщо базова ціна змінилася, контрактна має залишитися на попередньому рівні. Крім того, знижки застосовуються до всієї групи — неможливо задати персональну ціну одному дилеру без впливу на інших. Докладніше про типи цін можна прочитати в документації 1С-Бітрікс.
Як влаштовано зберігання контрактних цін
Створюємо Highload-блок dealer_contract_prices. Таблиця генерується автоматично за ім'ям блока. Поля:
| Поле | Тип | Опис |
|---|---|---|
UF_DEALER_ID |
Integer | ID дилерської компанії |
UF_PRODUCT_ID |
Integer | ID товару |
UF_XML_ID |
String | Артикул (для синхронізації з 1С) |
UF_PRICE |
Double | Контрактна ціна |
UF_CURRENCY |
String | Валюта |
UF_DATE_FROM |
DateTime | Початок дії |
UF_DATE_TO |
DateTime | Кінець дії |
UF_ACTIVE |
Boolean | Активність |
Індекс по (UF_DEALER_ID, UF_PRODUCT_ID, UF_ACTIVE) — обов'язковий: без нього вибірка при 100 000+ записів деградує в десятки разів. Використовуємо композитний індекс, щоб покрити основний сценарій: WHERE dealer=... AND product=... AND active=1.
Як працює логіка застосування
Реалізуємо кастомний провайдер цін, що підключається до події OnSaleBasketBeforeSaved або через розширення Bitrix\Catalog\v2\Price. Алгоритм:
- Визначаємо компанію поточного користувача з сесії.
- Шукаємо в
dealer_contract_pricesзапис із збігом дилера, товару, дати та активності. - Якщо запис знайдено — використовуємо
UF_PRICEяк фінальну, ігноруючи стандартний тип ціни. - Якщо ні — відкочуємося до типу ціни дилера за його групою.
Результат кешується в Redis за ключем contract_price_{dealerId}_{productId} на 1 годину. Інвалідація — при оновленні запису в Highload-блоці через OnAfterHLBlockElementUpdate. Такий підхід в 5 разів швидший, ніж перебір усіх знижок модуля catalog при 50 000 товарів.
Як завантажувати ціни з 1С
Контрактні ціни ведуться в 1С. Синхронізація через агент:
- 1С вивантажує XML із дилером (код в 1С), артикулом, ціною та періодом.
- Агент знаходить дилера за
UF_1C_IDв Highload-блоці компаній, товар — заXML_ID. - Створює або оновлює запис у
dealer_contract_prices. - Прострочені записи позначає
UF_ACTIVE= false.
Частота — подієво при оновленні прайсів або по cron 2 рази на добу. Помилки синхронізації логуємо: якщо контрактна ціна відсутня, дилер бачить базову ціну з попередженням.
Чому Redis кращий за файловий кеш для контрактних цін?
Файловий кеш в Бітрікс (BXCache) працює на рівні сторінок і компонентів. Для контрактних цін потрібен кеш, який швидко віддає одиничні записи. Redis у пам'яті забезпечує час відгуку <1 мс. Важливо налаштувати теговане кешування: інвалідація за тегом contract:dealer:{id} при зміні договору. Це позбавляє повного скидання кешу та економить ресурси сервера.
Як тестувати навантаження контрактних цін?
Перед запуском проводимо навантажувальне тестування. Умови: 500 одночасних користувачів, 100 000 контрактних записів, запит до кошика з 20-30 товарами. Очікуваний відгук — не більше 100 мс. Використовуємо ab або locust. При проблемах додаємо мідлвару для згладжування піків. Результати фіксуємо у звіті.
Що входить у налаштування контрактних цін
| Компонент | Опис |
|---|---|
| Highload-блок | Поля під вашу номенклатуру, індекси, налаштування кешування |
| Провайдер цін | Кастомний із підтримкою Redis, подія OnSaleBasketBeforeSaved |
| Агент синхронізації | Читання XML з 1С, оновлення записів, логування помилок |
| Відображення в каталозі | Мітка «Контрактна» в result_modifier.php |
| Тестування | Навантажувальне: 500 одночасних замовлень, відгук <100 мс |
| Навчання | Документація, туторіал з оновлення довідників |
Терміни та досвід команди
Налаштування сховища і логіки — 1-2 тижні. З інтеграцією вивантаження з 1С — 2-3 тижні. Оцінку проєкту проводимо безкоштовно, надсилаємо кошторис з етапами. У штаті сертифіковані спеціалісти 1С-Бітрікс з досвідом від 5 років.
Отримайте консультацію щодо вашого проєкту — розрахуємо термін і вартість для вашого каталогу. Зв'яжіться з нами, щоб обговорити деталі.