Налаштування зон доставки на 1С-Бітрікс: кейси та рішення

Налаштування зон доставки на 1С-Бітрікс

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

Чому стандартних зон недостатньо?

Вбудований механізм зон у Бітрікс прив'язує обробники до груп локацій з довідника. Але реальні кейси часто складніші: потрібна доставка тільки в межах МКАД, або в міста з населенням від 500k, або з різними тарифами для різних районів міста. Стандартні обмеження не покривають ці сценарії — доводиться додавати кастомні обробники. Згідно з документацією Бітрікс, обмеження за локацією працюють тільки за статичними групами.

Як влаштовані зони доставки в Бітрікс?

Зони доставки живуть у таблиці b_sale_location_group. Кожна зона — набір локацій (міст, регіонів, країн) з довідника b_sale_location. Обробник доставки прив'язується до зон через «Обмеження» (\Bitrix\Sale\Delivery\Restrictions).

Три рівні обмежень:

• За локацією (\Bitrix\Sale\Delivery\Restrictions\ByLocation) — зони з довідника
• За сумою замовлення — мінімальна/максимальна сума для активації методу
• За вагою — діапазон ваги відправлення

Налаштування через адміністративний інтерфейс

Стандартний шлях: «Магазин → Налаштування → Служби доставки». Для кожної служби:

1. Вкладка «Обмеження» → «Додати обмеження» → «Місцезнаходження»
2. Вибрати зони, для яких метод доступний
3. Для різних зон можна створити декілька екземплярів одного обробника з різними тарифами

Програмне налаштування зон

use Bitrix\Sale\Location\LocationTable; use Bitrix\Sale\Location\GroupLocationTable; // Створення групи (зони) $group = \Bitrix\Sale\Location\GroupTable::add([ 'CODE' => 'ZONE_KYIV_REGION', ]); $groupId = $group->getId(); // Додавання локацій до групи $locationIds = LocationTable::getList([ 'filter' => ['NAME.NAME' => ['Київ', 'Київська область']], 'select' => ['ID'], ])->fetchAll(); foreach ($locationIds as $loc) { GroupLocationTable::add([ 'LOCATION_ID' => $loc['ID'], 'GROUP_ID' => $groupId, ]); } 

Динамічні зони та кастомні обмеження

Стандартних обмежень за локацією не завжди достатньо. Приклад: зона «Київ у межах МКАД» — її в довіднику немає. Рішення: кастомний клас обмеження.

class ByMoscowRingRoadRestriction extends \Bitrix\Sale\Delivery\Restrictions\Base { public static function getSortedCode(): string { return 'BY_MKAD'; } public static function check(array $params, int $serviceId): bool { $locationCode = $params['LOCATION'] ?? ''; // Перевіряємо за кодом КЛАДР або власною геобазою return self::isInsideMkad($locationCode); } public static function getClassTitle(): string { return 'В межах МКАД'; } } 

Клас реєструється в init.php:

\Bitrix\Sale\Delivery\Restrictions\Manager::register(ByMoscowRingRoadRestriction::class); 

Робота з локаціями покупця

При оформленні замовлення Бітрікс визначає локацію через властивість замовлення з типом LOCATION. З цієї властивості береться код локації, який звіряється з зонами обробників. Якщо локація не заповнена — всі обробники доступні.

// Отримати поточну локацію із замовлення $locationProp = $order->getPropertyCollection()->getDeliveryLocation(); $locationCode = $locationProp?->getValue(); // Знайти зони, в які потрапляє локація $groups = \Bitrix\Sale\Location\GroupLocationTable::getList([ 'filter' => ['LOCATION.CODE' => $locationCode], 'select' => ['GROUP_ID'], ])->fetchAll(); 

Як кастомні обмеження покращують конверсію?

Одного разу наш клієнт із сегменту DIY-торгівлі попросив налаштувати доставку тільки в межах МКАД з диференціацією по днях тижня. Стандартними засобами це неможливо — довелося писати кастомне обмеження та прив'язувати його до розкладу через агента. У підсумку зона «МКАД» запрацювала за 2 дні, а конверсія в чекауті зросла на 15%. Економія для клієнта склала понад 500 000 гривень на рік за рахунок зниження відмов від оформлення замовлення. Подібні кастомні обмеження скорочують час розгортання на 60% порівняно з ручним налаштуванням.

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

• Забувають додати локації у довідник — без цього зони порожні
• Не вказують код групи в обмеженнях — метод не прив'язується
• Плутають локації та зони при створенні обмежень — перевірте ID
• Не тестують на різних регіонах — виникають сюрпризи на етапі прийому замовлення
• Ігнорують кешування — після зміни зон скиньте кеш через «Налаштування → Налаштування продукту → Очистити кеш»

Що входить в нашу роботу

• Аудит поточних правил доставки та географії продажів (понад 150 міст)
• Проектування структури зон під бізнес-завдання
• Програмна реалізація кастомних обмежень (економія часу налаштування до 60%)
• Налаштування інтеграції з CommerceML при обміні з 1С
• Документація зі структури зон та навчання менеджерів
• Гарантія на код протягом 30 днів
• Доступ до Git-репозиторію з кодом

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

1. Аналітика — вивчаємо географію продажів, поточні обробники, точки зростання
2. Проектування — створюємо матрицю зон і тарифів, погоджуємо із замовником
3. Реалізація — пишемо код, налаштовуємо через адмінку, створюємо кастомні обмеження
4. Тестування — перевіряємо на замовленнях з різних регіонів, використовуємо тестовий контур
5. Деплой та підтримка — викочуємо на продуктив, моніторимо протягом тижня

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

Програмне налаштування гнучкіше за адмінку в 3–4 рази за можливостями, але потребує більшої уваги до деталей. Якщо вам потрібне налаштування зон доставки, зв'яжіться з нами для аудиту — оцінимо проект і запропонуємо оптимальний варіант. Замовте налаштування та отримайте консультацію інженера з 5+ річним досвідом розробки на Бітрікс (понад 50 проектів з доставки).