Перша промислова синхронізація каталогу з 1С:Підприємство з 50 000 SKU на 1С-Бітрікс часто обертається тайм-аутами та дублями. Начебто ввімкнув модуль інтернет-магазину, вказав адресу 1c_exchange.php — а насправді половина товарів не завантажилась, решта скопіювались по три рази. CommerceML — стандартний протокол обміну, але він не гарантує унікальності ІД. Ми — інтегратори з 10-річним досвідом і досвідом понад 500 проектів. Нижче — реальні схеми, які вирішують ці проблеми без переплат. Економія на ручній обробці дублів може сягати 600 000–800 000 гривень на рік, а окупність інтеграції — 2–3 місяці. Ручний контроль кожного замовлення та товару — втрата часу та грошей. Автоматичний обмін усуває людський фактор і прискорює роботу складу.
Як влаштований стандартний обмін через CommerceML
Протокол CommerceML версії 2.08 диктує два незалежні потоки: каталог (від 1С до сайту) та замовлення (від сайту до 1С).
Вивантаження каталогу (1С → сайт)
- 1С формує XML-файли
import*.xml(структура, товари, властивості) таoffers*.xml(ціни, залишки). - Файли надсилаються HTTP POST на
/bitrix/admin/1c_exchange.php. - Сайт парсить XML, оновлює інфоблок.
Обмін замовленнями (сайт → 1С)
- Сайт генерує XML із замовленнями за період.
- 1С забирає, створює «Замовлення покупця».
- 1С повертає статуси.
Точка входу — 1c_exchange.php, команди checkauth, init, file, import.
Чому стандартний CommerceML не справляється з великими каталогами?
Основне обмеження — монолітний XML. При кожному повному обміні обробляється весь каталог, що дає пікове навантаження на сервер. Для каталогів >10 000 SKU повний обмін триває 5–30 хвилин і з'їдає всі ресурси. Висновок: для великих проектів стандартний механізм годиться лише як база.
Дельта-оновлення в 5 разів знижує навантаження
Замість повного вивантаження щогодини — повне раз на добу (вночі) + оновлення цін і залишків щогодини. Це знижує навантаження в робочий час на 80%. Ми використовуємо такий підхід у всіх проектах із високою волатильністю залишків.
REST API в 3 рази швидше для точкових оновлень
Якщо потрібно оновити один товар або статус замовлення, REST API швидше за XML-вивантаження в середньому в 3 рази. Підходить для інтеграцій з WMS або пов'язаними системами.
Як уникнути дублювання товарів при обміні?
Дублі — наслідок зміни ідентифікаторів (ІД) після реструктуризації бази 1С. Стандартний CommerceML не вміє зіставляти старі та нові ІД. Наш кейс: будівельний магазин з 80 000 SKU на УТ 11.4. При кожному оновленні 3–5% товарів отримували нові ІД і створювались заново, старі деактивувались. Менеджери витрачали години на відновлення.
Рішення: middleware-скрипт, який перехоплює подію OnIBlockElementBeforeAdd. Перед створенням елемента він звіряє ІД з XML з таблицею відповідностей {old_id => new_id}. Якщо ІД змінився, але артикул збігається — товар оновлюється, а не створюється. Дублі зникли.
Деталі middleware-скрипту
Скрипт пише лог всіх замін ІД в окрему таблицю, що дозволяє відстежити історію змін. Також перевіряє завантаження SQL-запитів через EXPLAIN і при необхідності додає індекси.Типові проблеми першого запуску та їх рішення
Тайм-аут при великих файлах. Один XML на 50 000 товарів важить 200–400 МБ. На сервері розбір займає до 30 хвилин — PHP звалюється. Рішення: у 1С увімкнути «Вивантажувати файлами по N товарів» з порогом 1000–5000.
Кирилиця в іменах файлів. Файли з кириличними іменами не доходять до скрипта — використовуйте трансліт у налаштуваннях обміну.
Кодування. CommerceML 2.08 вимагає UTF-8. Старі конфігурації можуть видавати windows-1251. Перевіряйте заголовок <?xml version="1.0" encoding="UTF-8"?>.
Розмежування прав для облікового запису обміну
Не використовуйте адміністратора. Створіть окремого користувача з групою, що має права на запис в інфоблок каталогу та на компонент обміну. У 1c_exchange.php перевірка: користувач повинен належати до групи з правом iblock_admin на цільовий інфоблок. Це виключає випадкові зміни в інших розділах.
Періодичність обміну та навантаження
| Режим | Навантаження на сервер | Застосування |
|---|---|---|
| Повне вивантаження раз на добу | Пікове, 5–30 хв | Каталоги до 10 000 SKU |
| Повне + дельта-оновлення | Помірне | 10 000–100 000 SKU |
| Тільки залишки та ціни щогодини | Низьке | Високоволатильні склади |
| REST API + події 1С | Мінімальне | Критичні дані в реальному часі |
Що входить у нашу роботу
- Аналіз поточної структури каталогу та налаштувань обміну
- Налаштування стандартного або кастомного обміну (CommerceML / REST)
- Розробка middleware для виключення дублів
- Впровадження дельта-оновлення та планувальника
- Тестування на тестовому та бойовому контурах
- Навчання менеджерів
- Документація та гарантійна підтримка
Терміни інтеграції
| Задача | Термін |
|---|---|
| Стандартний обмін каталогом + замовленнями | 1–3 дні |
| + нестандартна структура характеристик | 3–5 днів |
| + вирішення проблем з ІД при перенесенні бази | 1–2 дні додатково |
| Кастомний обмін через REST API | 1–3 тижні |
Замовте аудит поточного обміну — виявимо вузькі місця та підберемо оптимальну схему. Отримайте консультацію з налаштування обміну: інженер проаналізує ваш проект і запропонує рішення. Економія часу менеджерів — до 40 годин на місяць, а вартість помилок при ручній обробці може сягати 200 000 гривень на квартал.