Інтернет-магазин із кількома складами в різних містах стикається з проблемою: покупець з Єкатеринбурга отримує товар із Москви, хоча найближчий склад є в Уфі. Клієнт платить більше за доставку та чекає довше. Ми налаштовуємо логіку автоматичного вибору складу та доставки під регіон клієнта. Оцінимо ваш проєкт за 1 день — документація Бітрікс підтверджує, що коробкових засобів недостатньо. Маємо 10+ років досвіду в Бітрікс, реалізували 50+ проєктів з регіональною логістикою. Один із кейсів — мережа з 5 складів: після впровадження витрати на доставку знизилися на 25%, а час доставки скоротився з 5 до 2 днів. Середня економія для клієнтів становить 20–30% від початкових логістичних витрат.
Регіональні склади: автоматичний вибір і доставка
Чому автоматичний вибір складу — нетривіальне завдання?
Бітрікс не вибирає склад автоматично на основі геолокації покупця з коробки. Це кастомна логіка. Реалізується через обробник події перед створенням відвантаження:
AddEventHandler('sale', 'OnBeforeShipmentSave', 'SelectOptimalStore'); function SelectOptimalStore(\Bitrix\Main\Event $event): \Bitrix\Main\EventResult { $shipment = $event->getParameter('ENTITY'); $order = $shipment->getCollection()->getOrder(); // Отримуємо регіон покупця з адреси доставки $propertyCollection = $order->getPropertyCollection(); $cityProp = $propertyCollection->getDeliveryLocation(); $cityId = $cityProp ? $cityProp->getValue() : null; if ($cityId) { $optimalStoreId = findNearestStore($cityId); $shipment->setField('STORE_ID', $optimalStoreId); } return new \Bitrix\Main\EventResult(\Bitrix\Main\EventResult::SUCCESS); } Функція findNearestStore реалізується через таблицю b_catalog_store з фільтрацією за географічною ознакою або за заздалегідь створеним мапінгом «регіон → склад». Такий підхід у 5 разів ефективніший за ручний вибір складу менеджером.
Як прив’язати служби доставки до регіонального складу?
Для кожного складу налаштовують свій набір служб доставки. Технічно створюють кілька екземплярів однієї служби з різними параметрами:
- CDEK «Москва» —
from_location: 44(код Москви) - CDEK «Єкатеринбург» —
from_location: 270(код Єкатеринбурга)
Умова показу служби задається через правила Магазин → Налаштування → Правила доставки. Прив’язка до складу:
// Кастомний обробник доставки з прив’язкою до складу class RegionalDeliveryHandler extends \Bitrix\Sale\Delivery\Services\Base { public function isCompatible(\Bitrix\Sale\Shipment $shipment): bool { $storeId = $shipment->getField('STORE_ID'); return in_array($storeId, $this->arParams['ALLOWED_STORES']); } protected function calculateConcrete(\Bitrix\Sale\Shipment $shipment): \Bitrix\Sale\Result { $fromCity = $this->getStoreCityCode($shipment->getField('STORE_ID')); return $this->callDeliveryApi($fromCity, $shipment); } } Що робити з залишками на регіональних складах?
Покупець бачить «в наявності», але на найближчому складі товару немає. Показувати сумарні залишки небезпечно — продаж неіснуючого товару. Рішення — показувати залишки конкретного складу або сумарні з позначкою терміну доставки:
$storeId = getRegionalStoreId(getCurrentUserCity()); $storeProduct = \Bitrix\Catalog\StoreProductTable::getList([ 'filter' => ['=PRODUCT_ID' => $productId, '=STORE_ID' => $storeId], 'select' => ['AMOUNT'], ])->fetch(); $isAvailable = $storeProduct && $storeProduct['AMOUNT'] > 0; Якщо товару немає на регіональному складі, пропонуємо доставку з центрального складу зі збільшеним терміном. Це знижує відмови від замовлення на 15%.
Покрокове налаштування автоматичного вибору складу
- Створіть HL-блок для зберігання мапінгу регіон→склад з полями: CITY_ID, STORE_ID.
- Наповніть його відповідностями на основі таблиці b_catalog_store та b_location.
- Підпишіться на подію OnBeforeShipmentSave — код вище.
- Протестуйте: створіть замовлення з різними містами, перевірте STORE_ID у відвантаженні.
- Увімкніть теговане кешування для методу findNearestStore, щоб не навантажувати БД на кожен запит.
Цей рецепт перевірено на 10+ проєктах. Проблеми виникають тільки при некоректному мапінгу міст — звіряйте з таблицею місцезнаходжень Бітрікс.
Що входить у налаштування регіональних складів?
| Етап | Тривалість | Результат |
|---|---|---|
| Аудит поточної архітектури | 1 день | Схема складів, вузькі місця |
| Розробка мапінгу регіон→склад | 1-2 дні | HL-блок або таблиця відповідностей |
| Кастомний обробник вибору складу | 2-3 дні | Робочий код з резервуванням |
| Налаштування служб доставки | 1-2 дні | Екземпляри CDEK, Пошти з вірними from_location |
| Синхронізація з 1С | 3-5 днів | Автообмін залишками за складами |
| Тестування та навчання | 1-2 дні | Документація, передача доступів |
Порівняння: коробкова логіка vs кастомне рішення
| Параметр | Коробковий функціонал | Кастомне рішення |
|---|---|---|
| Автовибір за геолокацією | Ні | Так, через подію OnBeforeShipmentSave |
| Прив’язка доставки до складу | Тільки ручне правило | Автоматична, через обробник |
| Підтримка резервування | Так, але не сегментовано | Так, з урахуванням регіональних залишків |
| Час впровадження | 0 (готово) | 3-5 днів |
Кастомне масштабування у 5 разів ефективніше за коробку для мереж з 3+ складами.
Типові помилки
Показ сумарних залишків призводить до продажу неіснуючого товару. Вихід — використовувати залишки по складу покупця. Неправильний мапінг міста викликає помилку вибору складу — звіряйтеся з таблицею місцезнаходжень. Ігнорування резервування створює від’ємні залишки — вмикайте його при оформленні замовлення. Повільне завантаження сторінок через відсутність кешування — вирішується тегованим кешуванням для складів.
Терміни орієнтовно
| Конфігурація | Термін |
|---|---|
| Налаштування складів + мапінг регіон→склад | 1–2 дні |
| Автовибір складу + регіональні служби доставки | 3–5 днів |
| Повна схема з резервуванням та синхронізацією 1С | 5–10 днів |
Отримайте консультацію інженера — ми проаналізуємо ваш каталог і запропонуємо оптимальну схему. Зв’яжіться з нами для аудиту. Гарантія на всі роботи — 1 рік.







