Налаштування зон доставки на 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 проектів з доставки).

Інтеграція доставки: від розрізнених API до єдиного калькулятора за 5 днів

Покупець кидає кошик на етапі доставки — не бачить розрахунку або бачить свідомо невірну ціну. Кожен такий випадок втрачає конверсію. Автоматизація логістики в 1С-Бітрікс вирішує цю проблему: ми підключаємо служби доставки так, щоб ціна показувалася миттєво, а трекінг оновлювався без участі менеджера. Більше 50 реалізованих проєктів з каталогами від 500 до 100 000 SKU, досвід понад 8 років. Середній час підключення однієї транспортної компанії — 4 дні.

Як прискорити підключення служб доставки до 1С-Бітрікс?

Головна складність — не сам виклик API, а адаптація до логіки кожного перевізника. СДЕК, Boxberry, Нова пошта, ПЕК, DPD — у кожного свій формат запиту, тарифікація та обробка помилок. Ми використовуємо готові адаптери під кожну ТК, що скорочує час інтеграції втричі порівняно з реалізацією з нуля. Розгорнутий кейс: інтернет-магазин товарів для дому (15 000 товарів) — підключили СДЕК та Boxberry за 5 днів, автоматизували розрахунок та створення замовлень. Звернення до підтримки з доставки знизилися на 60%, середній чек зріс на 8% за рахунок індикатора безкоштовної доставки.

Чому API кожної транспортної компанії — окремий квест?

СДЕК — об'ємна вага та карта ПВЗ

API v2 (/api/v2/calculator/tarifflist) приймає габарити, вагу та адреси — повертає всі доступні тарифи. Підводні камені: об'ємна вага розраховується за формулою (Д × Ш × В) / 5000. Якщо фізична вага 2 кг, а об'ємна 8 кг — СДЕК бере по об'ємній. Не врахуєте в калькуляторі — покупець побачить одну ціну, а заплатить іншу. Карта ПВЗ завантажується через /deliverypoints. Віджет СДЕК можна вбудувати, але він конфліктує зі стилями Бітрікс — малюємо свою карту на Яндекс.Картах. Автоматичне створення замовлення через /api/v2/orders — при оформленні заявка летить у СДЕК, повертається трек-номер. Друк накладних та етикеток з адмінки — через /api/v2/print/orders. Тарифи: склад-склад, склад-двері, двері-двері, експрес, постамат.

Boxberry — широка мережа ПВЗ в регіонах

Найширша мережа пунктів видачі в малих містах. API простіше, ніж у СДЕК, але є нюанси з післяплатою та частковим викупом. Типові помилки при інтеграції: відсутність фільтрації ПВЗ за ознакою onlyPrepaid → помилки при післяплаті; ігнорування параметра partialReturn → ламає частковий викуп. API повертає код міста у форматі "770000000000" — потрібне маппінг на index міста.

Нова пошта — лідер українського ринку

Для України — обов'язкове підключення Нової пошти через API v2. Розрахунок вартості, створення ЕН, друк накладної, трекінг. Карта відділень з фільтрацією (поштомати, прийом платежів). Асинхронне оновлення статусів через агент Бітрікс кожні 15 хвилин.

ПЕК — важкі вантажі та збір

Коли потрібно відправити диван або обладнання. Розрахунок збірних вантажів, страхування, обрешітка. Доставка до терміналу та від дверей до дверей. Індекси терміналів ПЕК підвантажуємо в інфоблок для автопідстановки.

DPD — експрес-доставка з часовими слотами

DPD по Україні та за кордон. Доставка у вибраний часовий інтервал, повернення підписаних документів. У розрахунку враховуємо об'ємну вагу за формулою (Д×Ш×В)/4000 — відмінність від СДЕК. Документація DPD: volumetric weight factor 4000.

Як об'єднати різні ТК в єдиному калькуляторі?

Використовуємо гібридний підхід: модуль-агрегатор, який маршрутизує запити до різних API та нормалізує відповіді. Він обробляє запити в 5 разів швидше, ніж окремі інтеграції, завдяки паралельним викликам через curl_multi. У відповіді модуля — єдина структура: назва тарифу, ціна, термін, тип доставки. Кешування теговане: при зміні налаштувань модуля очищується лише кеш розрахунку для обраного міста, решта залишається. Подію OnBeforeDeliveryCalculate вішаємо на кастомний обробник — так підміняємо стандартну логіку доставки.

Розрахунок вартості: які граблі зустрічаються?

Автоматичний калькулятор підсумовує фізичну та об'ємну вагу товарів у кошику, додає вагу упаковки, обирає найбільшу. Звучить просто, але:

• Габарити мають бути заповнені у кожного товару. Немає габаритів — немає розрахунку. На каталозі в 10 000 SKU обов'язково знайдуться товари без розмірів — для них заводимо дефолтні значення (наприклад, 0.1×0.1×0.1 м) і попереджаємо менеджера через поштову подію.
• Промоакції та пороги безкоштовної доставки — гнучке налаштування: за сумою замовлення, для VIP-клієнтів, при конкретному способі оплати. Реалізуємо через користувацькі властивості кошика.
• Індикатор «До безкоштовної доставки залишилося N» — проста річ, але піднімає середній чек на 5–12%. Обчислюємо за сумою кошика та найближчим порогом, виводимо в шаблоні кошика.

Як автоматизувати трекінг, самовивіз та кур'єрську доставку?

Трекінг. Автоматичне опитування API транспортних компаній — агент Бітрікс кожні 30 хвилин перевіряє статуси замовлень, у яких STATUS_DELIVERY != 'DELIVERED'. При зміні — оновлення статусу замовлення в системі та повідомлення покупцеві (email, SMS, push). Вбудована сторінка трекінгу в особистому кабінеті — покупцю не потрібно йти на сайт ТК. Карта з поточним місцезнаходженням, прогнозована дата доставки, можливість переадресації.

Самовивіз. Власні точки видачі на карті: адреси, графік, контакти. Пошук найближчої за адресою покупця. Перевірка наявності в реальному часі, бронювання до певної години. QR-код для швидкого отримання та SMS про готовність до видачі.

Кур'єрська доставка. Зони доставки з різною вартістю. 2-годинні слоти, управління розкладом кур'єрів, обмеження замовлень на слот. Доставка день у день — прийом до 14:00, експрес за 2-4 години з націнкою за терміновість. Інтеграція з навігацією для оптимізації маршрутів.

Мультисклад. Декілька складів з адресами та зонами обслуговування. Автоматичний вибір складу відвантаження за адресою покупця — пріоритет найближчому, де є всі товари замовлення. Якщо на одному складі всього немає — розділення замовлення по складах (мультидоставка). Синхронізація залишків через 1С або WMS (CommerceML), використовуємо події OnBeforeBasketAdd для перевірки доступності.

Порівняння транспортних компаній

Етапи підключення служб доставки

1. Аналіз логістики (1–2 дні) — географія, середня вага, обсяг замовлень, інтеграція з 1С. Рекомендуємо комбінацію ТК.
2. Підключення API (3–5 днів на ТК) — налаштування розрахунків, карт ПВЗ, автоматичне створення замовлень через агенти та події.
3. Налаштування трекінгу (1–2 тижні) — агенти оновлення статусів, шаблони повідомлень, сторінка трекінгу.
4. Тестування (2–3 дні) — перевірка на реальних адресах, порівняння тарифів, контроль помилкових розрахунків, навантажувальне тестування.
5. Деплой та навчання (1 день) — вивантаження модуля, передача доступів, навчання менеджерів.
6. Гарантійна підтримка (1 місяць) — виправлення багів, коригування конфігурацій, доналаштування кешування.

Що входить у вартість інтеграції

• Документація зі схемою обміну (логістичні маршрути, тарифні зони).
• Налаштовані доступы до API кожної ТК, ключі, вебхуки.
• Шаблони повідомлень (email, SMS, push) для статусів доставки.
• Навчання менеджерів: робота з адмінкою, друк документів, обробка помилок.
• Півроку технічної підтримки після запуску.

Орієнтовні терміни реалізації

Терміни залежать від кількості ТК, складності каталогу та необхідності інтеграції з 1С/ERP. Вартість розраховується індивідуально — орієнтуйтеся на економію: зниження операційних витрат на доставку до 40% та скорочення звернень до підтримки на 60%. Наприклад, один із клієнтів з магазином електроніки (20 000 товарів) повернув інвестиції за 3 місяці за рахунок зменшення кількості «забутих» замовлень. Середня економія наших клієнтів — 15 000 грн на місяць на логістиці.

Готові прискорити логістику вашого інтернет-магазину? Зв'яжіться з нами — допоможемо підібрати оптимальну комбінацію ТК під ваш асортимент та бюджет. Замовте консультацію — і ми підготуємо пропозицію за 1 робочий день.