Чому сайт показує невірні залишки?
Ми стикалися з ситуацією, коли інтернет-магазин на 1С-Бітрікс показує 10 одиниць товару, а на фізичному складі вже давно пусто. Клієнт робить замовлення, ми передаємо його в 1С, а там — відмова. Overselling з'їдає до 20% виручки, а збитки можуть перевищувати 200 000 гривень щомісяця. Стандартна синхронізація через CommerceML запускається раз на 15–60 хвилин. Цього недостатньо при інтенсивних продажах: розбіжність накопичується. Наші інженери вирішують це завдання за допомогою вебхуків та документообігу в реальному часі.
Які підходи до синхронізації існують?
Порівняємо два основних методи:
| Метод | Частота оновлення | Затримка | Підходить для |
|---|---|---|---|
| CommerceML | За розкладом (15-60 хв) | Висока | Невеликі інтернет-магазини |
| Вебхуки | В реальному часі | Секунди | Магазини з високими продажами |
CommerceML — стандартний протокол обміну з 1С, описаний в CommerceML. Він надійний, але не підходить для сценаріїв, де залишки змінюються швидко. Вебхуки оновлюють дані за 1-2 секунди — це в 30 разів швидше, ніж CommerceML. Наш досвід — понад 50 проєктів з вебхуками — показує, що окупність такого рішення настає за пів року.
Як ми реалізуємо оновлення в реальному часі?
Для мінімізації розбіжності — інтеграція каси з Бітрікс в реальному часі. При кожному продажу на офлайн-касі негайний webhook у Бітрікс. Кроки реалізації:
- Створити endpoint на PHP, що приймає JSON від каси.
- Перевірити дані та знайти товар за SKU.
- Створити складський документ типу «S» (продаж) через
DocumentTable. - Провести документ викликом
conduct()— це автоматично оновить залишки вb_catalog_store_product. - Інвалідувати кеш товару.
Приклад реалізації вебхука
// /local/ajax/pos-sale-callback.php $data = json_decode(file_get_contents('php://input'), true); foreach ($data['items'] as $item) { $product = \CCatalogProduct::GetByID($item['sku']); if (!$product) continue; // Зменшуємо залишок на конкретному складі \Bitrix\Catalog\StoreProductTable::update( ['PRODUCT_ID' => $item['product_id'], 'STORE_ID' => $data['store_id']], ['AMOUNT' => new \Bitrix\Main\DB\SqlExpression('AMOUNT - ?', $item['quantity'])] ); // Перераховуємо сумарний залишок в b_catalog_product \CCatalogProduct::RecalcQuantity($item['product_id']); } RecalcQuantity() перераховує b_catalog_product.QUANTITY як суму по всіх складах у b_catalog_store_product. Після цього кеш товару має бути інвалідований — через BXClearCache(false, '/catalog/') або тегований кеш. Ми гарантуємо, що час оновлення не перевищує 2 секунд.
Як резервувати залишки для онлайн-продажів?
Часта практика для магазинів з кількома каналами продажів: виділити окремий «онлайн-склад» у b_catalog_store, залишки якого призначені тільки для інтернет-магазину. Фізично товар може бути на одному складі, але логічно розділений.
При цьому офлайн-продажі зменшують «фізичний склад», а онлайн-замовлення резервуються з «онлайн-складу». Вночі 1С поповнює онлайн-склад з фізичного за заданою пропорцією.
Фізичний склад: 100 одиниць Онлайн-квота: 30% = 30 одиниць → зберігається в b_catalog_store_product (STORE_ID = online_store) Офлайн-квота: 70% = 70 одиниць → не потрапляє в Бітрікс Це виключає ситуацію overselling, але знижує доступний залишок для онлайн-продажів. Ми підбираємо пропорцію індивідуально, спираючись на статистику продажів.
Як працює документообіг?
У Бітрікс модуль catalog підтримує складські документи: \Bitrix\Catalog\Document\DocumentTable. Типи документів: A — прихід, S — продаж, M — переміщення, R — повернення.
При проведенні документа через \Bitrix\Catalog\Document\DocumentController::conduct() автоматично перераховуються залишки в b_catalog_store_product. Це правильний спосіб рухати залишки — через документи, а не прямим UPDATE.
Для офлайн-продажів: при отриманні webhook від каси створюємо документ типу S з позиціями продажу та проводимо його. Це забезпечує повну історію руху товару та коректний складський облік.
Інвентаризація та звірка
Розбіжності між 1С та Бітрікс неминучі. Важливо вміти їх знаходити. Щодоби запускаємо агент-звіряльник:
// Отримуємо залишки з 1С через REST API $bx1cItems = get1cQuantities(); // Порівнюємо з b_catalog_store_product foreach ($bx1cItems as $sku => $qty) { $bitrixQty = StoreProductTable::getList([ 'filter' => ['PRODUCT.XML_ID' => $sku], 'select' => ['AMOUNT'], ])->fetch()['AMOUNT'] ?? 0; if (abs($bitrixQty - $qty) > 0) { logDiscrepancy($sku, $bitrixQty, $qty); } } Лог розбіжностей дозволяє прийняти рішення: коригувати Бітрікс за 1С (1С — майстер) або сигналізувати про проблему в інтеграції. Після впровадження економія для клієнта становить до 500 000 гривень на рік за рахунок усунення overselling та ручної звірки.
Що входить у налаштування під ключ
У кожному проєкті ми надаємо:
- Аудит поточної схеми складського обліку та точок інтеграції
- Вибір оптимального протоколу синхронізації (CommerceML або вебхуки)
- Розробку endpoint під вебхуки від кас та POS-терміналів
- Налаштування документообігу: прихід, продаж, переміщення, повернення
- Впровадження агента звірки залишків з логуванням розбіжностей
- Навчання персоналу роботі з оновленою системою
- Детальну документацію з інтеграції та налаштувань
- Технічну підтримку протягом місяця після запуску
Етапи та терміни робіт
| Етап | Тривалість | Результат |
|---|---|---|
| Аналітика | 2-3 дні | Схема інтеграції, вибір методу синхронізації |
| Проєктування | 3-5 днів | Технічне завдання, прототип |
| Розробка | 5-10 днів | Вебхуки, документи, агент звірки |
| Тестування | 3-5 днів | Перевірка на реальних даних, усунення помилок |
| Запуск | 1-2 дні | Деплой, навчання персоналу |
Терміни — від 2 до 4 тижнів. Інвестиції розраховуються індивідуально залежно від складності. Окупність — 4–6 місяців. Ми сертифіковані спеціалісти 1С-Бітрікс з досвідом понад 10 років. Гарантуємо, що після налаштування розбіжності залишків не перевищать 0.1% за умови стабільної роботи каналів зв'язку.
Якщо ви помітили розбіжності залишків у своєму магазині, замовте аудит та отримайте план синхронізації. Зв'яжіться з нами для консультації.