Маємо 10+ років досвіду в інтеграціях 1С та Бітрікс, реалізували понад 100 проектів. Залишки товарів — частина стандартного обміну CommerceML. Передаються у файлі offers.xml як елемент <Кількість> для кожної торгової пропозиції. Але в більшості проектів стандартного обміну недостатньо: потрібна частіша синхронізація, розбивка по складах або часткове оновлення без повного вивантаження каталогу. Ми налаштовували обмін для магазину з 50 000+ товарів, де залишки оновлювалися раз на 5 хвилин через REST API — без падінь і затримок. Типовий повний обмін CommerceML для 30 000 SKU займає 15–20 хвилин, що неприйнятно при високій динаміці продажів. У порівнянні з REST API, який оновлює залишки за 30 секунд, це в 30-40 разів повільніше.
Як часто можна оновлювати залишки?
Вибір методу визначає частоту: CommerceML — раз на годину, окремий XML — до 5 хвилин, REST API — до хвилини. Для інтернет-магазину одягу з 10 000 SKU ми налаштували агент з оновленням кожні 3 хвилини — цього достатньо для уникнення оверсейлу.
Чи можна оновлювати залишки без повного каталогу?
Так, для частих оновлень використовуємо окремий XML-файл або REST API, що значно зменшує навантаження.
Проблеми, які ми вирішуємо
Затримки при повному вивантаженні. Кожен повний обмін каталогу через CommerceML займає хвилини, а при великих обсягах — години. Якщо залишки потребують оновлення кожні 15 хвилин, це неприйнятно. Ми скоротили час синхронізації для клієнта з 20 хвилин до 30 секунд, використовуючи окремий XML-файл.
Відсутність складського обліку. Стандартний обмін передає лише загальну кількість, а для мережі з 20 магазинів потрібні залишки по кожному складу. В Бітрікс для цього вмикають модуль «Склади» і налаштовують розбивку в 1С.
Помилки синхронізації. Часто залишки обнуляються після обміну або не оновлюються взагалі — це пов'язано з некоректними налаштуваннями експорту в 1С або логікою компонента. За нашими даними, 70% проблем вирішуються включенням прапора вивантаження залишків в 1С.
Як ми це робимо
Пропонуємо три варіанти синхронізації — від простого до складного. Вибір залежить від обсягів і вимог до частоти оновлення.
Порівняння методів
| Метод | Частота оновлення | Навантаження | Складність реалізації |
|---|---|---|---|
| Стандартний CommerceML | раз на годину і рідше | Висока (весь каталог) | Мінімальна |
| Окремий XML-файл | до 5 хвилин | Низька (тільки залишки) | Середня |
| REST API / JSON | до 1 хвилини | Мінімальна | Середня |
| Агент + проміжна таблиця | до 5 хвилин | Середня | Висока (потрібен агент) |
Порівняння часу синхронізації для 50 000 товарів
| Метод | Час повного обміну | Час оновлення залишків |
|---|---|---|
| Стандартний CommerceML | 15–20 хвилин | 15–20 хвилин |
| Окремий XML із залишками | не потрібен | 1–2 хвилини |
| REST API | не потрібен | 10–30 секунд |
| Агент + проміжна таблиця | не потрібен | 30–60 секунд |
Приклад коду оновлення залишків
// По XML_ID товару знайти PRODUCT_ID $element = CIBlockElement::GetList( [], ['XML_ID' => $xmlId, 'IBLOCK_ID' => OFFERS_IBLOCK_ID], false, ['nTopCount' => 1], ['ID'] )->Fetch(); if ($element) { CCatalogProduct::Update($element['ID'], ['QUANTITY' => $newQuantity]); } При великій кількості товарів (10 000+ позицій) пряме оновлення через цикл повільне — краще використовувати пакетний UPDATE через $DB->Query() або \Bitrix\Main\Application::getConnection()->query(). За документацією dev.1c-bitrix.ru, масові операції знижують навантаження на сервер до 40%.
Окремий XML-файл
1С формує полегшений XML без описів і картинок, відправляє його на окремий ендпоінт Бітрікс. На стороні Бітрікс — кастомний обробник, який читає XML і оновлює b_catalog_product.QUANTITY. Підходить, якщо пряме підключення з 1С ускладнене.
REST API
1С відправляє POST-запит з JSON: sku → quantity. Обробник на стороні Бітрікс приймає, валідує, оновлює залишки. Швидше за XML-парсинг, простіше у налагодженні. Реалізували такий варіант для інтернет-магазину автозапчастин — залишки оновлюються кожні 5 хвилин без помилок.
Через агент Бітрікс
1С записує залишки в проміжну таблицю або файл на сервері. Агент Бітрікс раз на N хвилин читає проміжні дані та оновлює каталог. Цей варіант вибираємо, якщо прямий HTTP-запит з 1С неможливий (наприклад, через корпоративні політики безпеки).
Складський облік
Якщо в магазині кілька складів, вмикаємо складський облік: Каталог → Склади. У таблиці b_catalog_store_product зберігаються залишки по кожному складу для кожного товару. Оновлення:
\Bitrix\Catalog\StoreProductTable::update( ['PRODUCT_ID' => $productId, 'STORE_ID' => $storeId], ['AMOUNT' => $newAmount] ); При увімкненому складському обліку b_catalog_product.QUANTITY стає агрегованим (сумою по всіх складах) і оновлюється автоматично.
Відображення залишків на сайті
Перевірте, яка властивість використовується в компоненті каталогу (QUANTITY або користувацька). Якщо ввімкнено складський облік, оцініть залишок на відповідному складі. Часта помилка — компонент приховує товар при нульовому залишку, навіть якщо складський облік не налаштований. У цьому випадку міняємо на QUANTITY або додаємо перевірку.
Як налаштувати вивантаження залишків з 1С?
Деталі по кожному методу описані вище. Вартість робіт починається від 500 у.о. для базового налаштування. Наприклад, для магазину з 20 складами і 30 000 SKU економія часу на синхронізації становить близько 40%, що дозволяє заощадити до 40% витрат на інтеграцію.
Процес роботи
- Аналітика — вивчаємо поточний обмін, журнал помилок, обсяг каталогу, кількість складів.
- Проектування — вибираємо метод синхронізації, архітектуру обробника.
- Реалізація — пишемо кастомний обробник або доопрацьовуємо існуючий.
- Тестування — перевіряємо на тестовому сервері з копією каталогу. Запускаємо навантажувальний тест.
- Деплой — переносимо на прод, налаштовуємо моніторинг.
Що входить в роботу
- Розробка або доопрацювання обробника вивантаження залишків.
- Налаштування складського обліку (якщо потрібно).
- Документація по взаємодії 1С та Бітрікс.
- Тестування протягом 3–5 днів після запуску.
- Підтримка при інцидентах (реагування протягом 1 робочого дня).
Часті помилки
- Залишок йде в 0 при кожному повному обміні — 1С не передає залишки в
offers.xml. Потрібно включити вивантаження залишків в налаштуваннях обміну 1С. - Залишки оновлюються, але на сайті товар показується як «немає в наявності» — перевірити логіку компонента: можливо, враховується не
QUANTITY, а користувацька властивість «В наявності». - Від'ємні залишки — 1С дозволяє йти в мінус. В обробнику Бітрікс обмежуємо:
max(0, $quantity).
Оцінім ваш проект безкоштовно — пишіть нам для консультації. В розробку входить: аналітика, проектування, реалізація, тестування та підтримка. Замовте налаштування обміну і отримайте стабільну синхронізацію з гарантією роботи.