Роздрібна мережа стикається з трьома потоками замовлень одночасно: інтернет-магазин Бітрікс, POS-термінали в магазинах і телефонні дзвінки. Без синхронізації залишки резервуються кілька разів паралельно — до 15% замовлень скасовуються через нестачу товару. Ми, інженери з 10+ років досвіду, забезпечуємо двосторонній обмін замовленнями та залишками між Бітрікс і 1С у реальному часі. Це означає: оплата онлайн миттєво резервує товар на складі, POS-продаж одразу зменшує залишки в інтернеті, конфлікти відсутні. Під ключ — від вибору архітектури схеми до навчання персоналу.
Чому три ізольовані потоки замовлень убивають складський облік?
Типовий сценарій: клієнт оплачує онлайн товар, який уже проданий через POS 10 хвилин тому. Бітрікс списує залишок тільки після формування замовлення, а POS-продаж уже зменшила фізичний залишок. У результаті онлайн-замовлення приймається, але відвантажити нічого. Впровадження синхронізації скорочує втрати від подвійних продажів на 15-20%.
Як вибрати майстра синхронізації?
| Критерій | 1С як майстер | Бітрікс як майстер | Гібрид (не рекомендується) |
|---|---|---|---|
| Джерело правди | 1С | Бітрікс | Немає єдиного |
| Замовлення онлайн | Передаються в 1С | Обробляються в Бітрікс | Дублюються |
| Офлайн-продажі | Фіксуються в 1С | Створюються в Бітрікс через API | Втрата замовлень |
| Залишки | Синхронізуються в Бітрікс | Синхронізуються в 1С | Перезаписуються |
| Конфлікти при паралельних продажах | Вирішуються в 1С | Вирішуються в Бітрікс | Виникають в обох системах |
80% конфліктів минають, якщо вибрати майстра до початку розробки. Проконсультуйтеся з нашими спеціалістами на етапі аудиту.
Архітектура синхронізації: протоколи та схема
1С як майстер
1С є джерелом істини щодо замовлень і залишків. Бітрікс передає онлайн-замовлення в 1С, офлайн-продажі фіксуються там же, залишки синхронізуються назад.
Бітрікс як майстер
Усі замовлення (онлайн і офлайн через POS) збираються в Бітрікс, 1С отримує дані для бухгалтерії.
Синхронізація через CommerceML
Стандартний обмін 1С-Бітрікс (/bitrix/admin/1c_exchange.php) покриває базовий сценарій. Налаштування в модулі sale. Як зазначено в документації 1С-Бітрікс, стандартний обмін через CommerceML підходить для пакетного обміну замовленнями та залишками. Обмеження: пакетний раз на N хвилин. Для реального часу потрібні вебхуки або черги.
REST API та черга повідомлень
| Протокол | Швидкість | Складність реалізації | Підходить для |
|---|---|---|---|
| CommerceML | Пакетний (раз на N хвилин) | Середня | Базовий обмін з 1С |
| REST API | Реальний час | Висока | Нестандартні POS, вебхуки |
| Черга повідомлень (RabbitMQ) | Мілісекунди | Дуже висока | Великі мережі, highload |
Для великих мереж і highload підходить черга на RabbitMQ із затримкою не більше 2 секунд.
Реалізація: резервування та конфлікти
Офлайн-замовлення з POS
Коли касир оформлює продаж через POS, потрібно створити замовлення в Бітрікс з API або тільки списати залишки?
Приклад створення замовлення через REST API:
// Створення офлайн-замовлення в Бітрікс \Bitrix\Main\Loader::includeModule('sale'); \Bitrix\Main\Loader::includeModule('catalog'); $order = \Bitrix\Sale\Order::create(SITE_ID, $userId); $order->setField('CURRENCY', 'RUB'); $order->setField('USER_DESCRIPTION', 'Продаж у магазині: ' . $storeName); $basket = \Bitrix\Sale\Basket::create(SITE_ID); foreach ($items as $item) { $basketItem = $basket->createItem('catalog', $item['PRODUCT_ID']); $basketItem->setFields([ 'QUANTITY' => $item['QUANTITY'], 'CURRENCY' => 'RUB', 'LID' => SITE_ID, 'PRODUCT_PROVIDER_CLASS' => '\CCatalogProductProvider', ]); } $order->setBasket($basket); // Позначаємо джерело замовлення $order->setField('STATUS_ID', 'F'); // Виконано — офлайн-продаж завершено $order->setField('ADDITIONAL_INFO', json_encode([ 'source' => 'offline', 'store' => $storeId, 'pos_transaction_id' => $transactionId, ])); $result = $order->save(); Резервування залишків при онлайн-замовленні
Критична точка — момент резервування. Бітрікс управляє резервами через b_catalog_store_product і b_sale_product_reserve. Для Click & Collect резервуємо на конкретному складі.
Синхронізація залишків у реальному часі
Зміна залишків на будь-якій стороні має миттєво відображатися. Використовуємо чергу подій:
// При зміні залишків — додаємо в чергу \Bitrix\Main\EventManager::getInstance()->addEventHandler( 'catalog', 'OnProductUpdate', function (\Bitrix\Main\Event $event) { $productId = $event->getParameter('ID'); $fields = $event->getParameter('FIELDS'); if (isset($fields['QUANTITY'])) { // Ставимо в чергу синхронізації з 1С \Local\Queue\InventorySync::push([ 'product_id' => $productId, 'quantity' => $fields['QUANTITY'], 'timestamp' => time(), ]); } } ); Конфлікти паралельних продажів
Рішення — атомарне списання на рівні БД:
-- Атомарне списання з перевіркою UPDATE b_catalog_store_product SET QUANTITY = QUANTITY - 1 WHERE PRODUCT_ID = ? AND STORE_ID = ? AND QUANTITY >= 1; -- Якщо affected_rows = 0 — залишку немає, відхиляємо замовлення У Бітрікс реалізується через CCatalogProductProvider.
Як ми це робимо: кейс мережі з 10 000 SKU
Наш клієнт — мережа з 12 точок: 3 онлайн-потоки та офлайн-продажі через 1С:Роздріб. Стандартний CommerceML давав затримку 15 хвилин. Рішення: черга на RabbitMQ + кастомний агент із затримкою не більше 2 секунд. Конфлікти вирішуються за принципом «хто перший зафіксував транзакцію». Результат — 99.9% актуальність залишків. Окупився за 2 місяці.
Що входить у роботу та процес
- Аудит поточної архітектури
- Вибір майстер-системи та протоколу
- Налаштування обміну замовленнями, статусами, залишками
- Розробка кастомних агентів
- Тестування під навантаженням
- Документація та навчання
- Підтримка 1 місяць
Процес: аналітика (1-2 дні) → проектування (1-2) → реалізація (3-5) → тестування (2-3) → деплой (1). Терміни — від 5 до 10 робочих днів.
Гарантія: роботи виконуються з використанням офіційної документації Бітрікс і 1С. Застосовуємо асинхронну обробку для мінімізації втрат.
Зв'яжіться з нами для безкоштовного аудиту вашої схеми. Отримайте план синхронізації для вашого бізнесу. Замовте інтеграцію та забудьте про проблеми із залишками.