Мультискладовий обмін 1С та 1С-Бітрікс: налаштування під ключ

Після обміну 1С з Бітрікс залишки на сайті показують загальну кількість, хоча на складах в 1С облік ведеться окремо. Покупець з Ростова-на-Дону бачить товар «в наявності» на московському складі, замовляє, а доставка коштує як міжмісто — 5 днів і 800 гривень. Знайома ситуація? Ми стикалися з цим десятки разів. Налаштування мультискладового обміну — рутинна, але критична задача, без якої інтернет-магазин втрачає гроші на невірній логістиці та поверненнях.

Ми — команда сертифікованих інженерів з 10+ роками досвіду в Бітрікс. За цей час ми реалізували мультискладовий обмін для 50+ проєктів — від невеликих регіональних мереж до федеральних рітейлерів з десятками складів. Налаштовуємо все: від XML-ідентифікаторів до автоматичної прив'язки доставки за регіоном.

Попередні умови

Для роботи мультискладового обліку в Бітрікс потрібна редакція «Малий бізнес» або вище. У «Старті» управління складами недоступне — є лише один віртуальний склад.

В 1С має бути включений облік по складах:

• УТ 11: Адміністрування → Склад і доставка → Декілька складів: Так
• УТ 10: Сервіс → Налаштування параметрів обліку → Складський облік → Вести облік по складах

Налаштування складів та XML-ідентифікаторів

В 1С кожен склад має унікальний ідентифікатор (GUID). В Бітрікс кожен склад має поле «Зовнішній код (XML ID)». Збіг цих значень — умова коректного розподілу залишків:

Каталог → Склади → [склад] → Зовнішній код (XML ID) = GUID складу з 1С

Отримати GUID складу з 1С можна в конфігураторі, або через запит ВИБРАТИ Посилання.УнікальнийІдентифікатор ІЗ Довідник.Склади. Також можна взяти з XML-файлу обміну в тезі <ІдСкладу>. Згідно зі стандартом CommerceML «CommerceML — формат обміну даними між 1С та інтернет-магазинами», ідентифікатори мають бути унікальними.

Показ залишків по конкретному складу в картці товару

Якщо покупець має бачити «в наявності в Києві: 5 шт., в Харкові: 12 шт.» — кастомна доробка компонента картки товару. Дані беруться з \Bitrix\Catalog\StoreProductTable, описаного в офіційній документації:

$storeRests = \Bitrix\Catalog\StoreProductTable::getList([ 'filter' => ['=PRODUCT_ID' => $productId], 'select' => ['AMOUNT', 'STORE_ID', 'STORE.TITLE', 'STORE.ADDRESS'], 'order' => ['STORE.TITLE' => 'ASC'], ])->fetchAll(); foreach ($storeRests as $rest) { if ($rest['AMOUNT'] > 0) { echo $rest['STORE_TITLE'] . ': ' . $rest['AMOUNT'] . ' шт.'; } } 

Як прив'язати склад до доставки?

Зв'язка «склад → зона доставки» вирішує питання звідки везти. Якщо покупець з Харкова — запропонувати доставку з харківського складу з коротким терміном, а не з київського з 5-денним транзитом.

Реалізація у двох варіантах:

• Автоматично за регіоном покупця — при визначенні регіону по IP або виборі покупцем міста, пріоритетний склад береться з довідника «склад → регіони обслуговування»
• Через вибір пункту самовивозу — кожен пункт = склад, покупець явно вибирає звідки забрати

Перший варіант зручніший для інтернет-магазинів з доставкою по всій країні: покупцю не потрібно думати, система сама призначає найближчий склад. Другий — для мереж із самовивозом, коли важлива прозорість. При правильному налаштуванні компанія економить до 500 000 гривень на рік на невірних відвантаженнях.

Чому не синхронізуються залишки?

Типова причина — неспівпадіння XML-ідентифікаторів. Перевірте: GUID в 1С має бути точно рівний «Зовнішньому коду (XML ID)» складу в Бітрікс. Навіть зайвий пробіл або регістр ламають прив'язку. Друга за частотою причина — вимкнений облік по складах в 1С (див. попередні умови). Третя — помилки в правилах обміну CommerceML, коли вивантажуються залишки без вказівки складу.

Як налаштувати мультискладовий обмін: покрокова інструкція

1. Перевірте редакцію Бітрікс та включення обліку по складах в 1С.
2. Отримайте GUID складів з 1С і пропишіть їх в XML ID складів Бітрікс.
3. Налаштуйте прив'язку складів до зон доставки (автоматично або через вибір пункту самовивозу).
4. Протестуйте обмін: створіть замовлення з різними регіонами та перевірте залишки.

Звітність по мультискладу

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

SELECT e.ID, e.NAME, SUM(sp.AMOUNT) as total_amount, COUNT(DISTINCT sp.STORE_ID) as stores_count FROM b_iblock_element e LEFT JOIN b_catalog_store_product sp ON sp.PRODUCT_ID = e.ID WHERE e.IBLOCK_ID = :iblock_id GROUP BY e.ID, e.NAME ORDER BY total_amount ASC; 

Цей запит можна використовувати у звіті «Залишки на складах» через створення HL-блока або інтеграцію з BI-системами.

Типові помилки та їх вирішення

Що входить в роботу?

Підсумковий термін — від 1 до 4 днів залежно від складності кастомізацій. Вартість розраховується індивідуально після аудиту — зв'яжіться з нами для оцінки.

$storeRests = \Bitrix\Catalog\StoreProductTable::getList([ 'filter' => ['=PRODUCT_ID' => $productId], 'select' => ['AMOUNT', 'STORE_ID', 'STORE.TITLE', 'STORE.ADDRESS'], 'order' => ['STORE.TITLE' => 'ASC'], ])->fetchAll(); foreach ($storeRests as $rest) { if ($rest['AMOUNT'] > 0) { echo $rest['STORE_TITLE'] . ': ' . $rest['AMOUNT'] . ' шт.'; } } 

Наш досвід

Ми працюємо з мультискладовими конфігураціями вже більше 10 років. Брали участь у запуску обміну для мережі з 30 складів по всій Україні — тоді вручну прописували XML-ідентифікатори через SQL-запити. Зараз процес автоматизований, але ручна верифікація залишається обов'язковою: одна помилка в GUID — і залишки «з'їжджають». Ми гарантуємо точність прив'язки та надаємо документацію по всій конфігурації. Отримайте консультацію — ми допоможемо налаштувати обмін без втрат.

Терміни налаштування

Налаштування мультискладового обміну з прив'язкою XML-ідентифікаторів — 1 день. З кастомним показом залишків по складах і прив'язкою до зон доставки — 2–4 дні. Орієнтуйтеся на верхню межу, якщо потрібна інтеграція з нестандартними службами доставки або власною логістикою.

Якщо у вас вже є налаштування, але залишки не синхронізуються, — пишіть, проведемо аудит безкоштовно. Оцінимо проєкт протягом дня.