Налаштування регіональних цін на 1С-Бітрікс: повне керівництво

При спробі виставити різні ціни для Києва та регіонів клієнти часто стикаються з тим, що ціни підміняються або не оновлюються. Проблема в тому, що задіяно три підсистеми: типи цін, правила торгівлі та географічні групи. Наш досвід налаштування 10+ проєктів показує, що типова помилка — забути прив'язати регіон до групи користувачів через подію OnBeforeUserRegister або агент. Розберемо механізм повністю. Ми — сертифіковані інженери Бітрікс, працюємо з платформою 10+ років. Гарантуємо коректну роботу регіонального ціноутворення на будь-якому проєкті. Ви отримуєте налаштування під ключ: від проєктування до тестування та підтримки. Зверніть увагу: при неправильному налаштуванні кешування середнє завантаження сторінки каталогу збільшується на 40–60%.

Як Бітрікс визначає регіон користувача?

Для визначення регіону використовується модуль sale.regions. Він доступний починаючи з редакції Business. Доступні три способи, які ми порівняли в таблиці:

Кожен спосіб вимагає налаштування обробника, який додає користувача в потрібну групу Бітрікс. Приклад програмного додавання:

$locationCode = \Bitrix\Sale\Location\LocationTable::getLocationCityCode($cityId); if (in_array($locationCode, ['0000073738', '0c5b2444b22d4d0fa32c11a4401d4c46'])) { // Київ та Київська область — в групу 5 \CUser::SetUserGroup($userId, array_unique(array_merge($currentGroups, [5]))); } 

Чому важливо використовувати GetOptimalPrice?

Метод GetOptimalPrice — ключовий для регіональних цін. Він повертає мінімальну ціну з усіх типів, доступних групам користувача. Замість ручного перебору типів цін використовуйте його — це в 2-3 рази швидше та надійніше:

$userGroups = \Bitrix\Main\UserTable::getUserGroupIds($userId); $price = \CCatalogProduct::GetOptimalPrice($productId, 1, $userGroups); 

Цей підхід коректно обробляє знижки та націнки з правил торгівлі. В одному проєкті ми замінили саморобний перебір на GetOptimalPrice та знизили час генерації сторінки каталогу з 1.2 с до 0.4 с.

Кешування та продуктивність

Регіональні ціни збільшують навантаження на кеш. Використовуйте теговане кешування з унікальним ключем для кожного регіону:

$regionTag = 'region_' . \Bitrix\Sale\Location\LocationTable::getCurrentRegionCode(); $cacheId = 'catalog_section_' . $sectionId . '_' . $regionTag; 

Це дозволяє роздавати різний контент для Києва та регіонів без збоїв кешу. Без правильного кешування середнє навантаження на сервер зростає в 3–4 рази при 500+ одночасних відвідувачах.

Що робити при помилках синхронізації з 1С?

Помилки синхронізації регіональних цін з 1С виникають через некоректне відображення типів цін у CommerceML. Переконайтеся, що в 1С кожному регіону відповідає окремий тип ціни з унікальним ідентифікатором. При імпорті використовуйте подію OnSuccessCatalogImport1C для перевірки прив'язки цін до регіональних груп. Ми рекомендуємо вести лог імпорту та звіряти кількість оновлених цін після кожної синхронізації.

Що входить в налаштування

В рамках роботи ви отримуєте:

• Аудит поточної конфігурації каталогу та типів цін.
• Створення необхідних типів цін, правил торгівлі та географічних груп.
• Реалізацію механізму визначення регіону (IP / ручний вибір / кука).
• Інтеграцію з 1С через CommerceML з маппінгом типів цін.
• Тестування всіх сценаріїв та замір продуктивності.
• Впровадження тегованого кешування з регіональним ключем.
• Документацію з налаштування та подальшої підтримки.
• Передачу доступів та навчання співробітників.

Процес роботи

1. Аналіз поточного каталогу — виявлення використовуваних типів цін і груп користувачів.
2. Проєктування — створення відсутніх типів цін і правил торгівлі.
3. Розробка механізму визначення регіону (IP / ручний вибір / кука).
4. Реалізація — написання обробників і прив'язка регіонів до груп.
5. Інтеграція з 1С — налаштування обміну через CommerceML з маппінгом типів цін.
6. Тестування — перевірка цін для різних груп, заміри продуктивності.
7. Оптимізація кешування — впровадження тегованого кешу з регіональним ключем.
8. Передача документації та доступів.

Терміни орієнтовно

Вартість розраховується індивідуально після аудиту проєкту. При оцінці ми враховуємо кількість регіонів, глибину каталогу, наявність інтеграції з 1С та вимоги до швидкості відгуку. Для проєктів з більш ніж 50 000 SKU обов'язковим стає навантажувальне тестування з емуляцією перемикання регіонів через JMeter або k6 — інакше кеш прогріву не покаже реальних цифр під піковим навантаженням. Також фіксуємо сценарій відкату: якщо після релізу помітні розбіжності цін, включаємо режим fallback на базовий тип і повідомляємо менеджерів через bitrix24-бота.

Для оптовиків додатково рекомендуємо пов'язувати регіон з методом доставки і складом відвантаження — інакше при спробі купити зі складу в Харкові київський клієнт отримує помилку резерву. Реалізується через обробник OnSaleOrderBeforeSaved з перевіркою відповідності регіону користувача та залишків на складі. Цей же механізм використовуємо для автоматичного підбору кур'єрських служб Нова Пошта, Укрпошта та Meest під конкретний регіон, що знижує кількість ручних коригувань замовлення менеджерами приблизно на 70%.

Типові помилки при налаштуванні

• Не прив'язаний регіон до групи користувачів — ціни не змінюються.
• Використовується прямий запит GetList без фільтра по групах — отримується базова ціна.
• Не налаштоване кешування — сторінки завантажуються повільно (до 5 сек при 1000 товарів).
• У CommerceML не зіставлені типи цін — при імпорті ціни перезаписуються базовими.

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