Уявіть: ERP генерує XML з 120 тис. позицій, 4,5 ГБ — і PHP-обробник Бітрікс падає через 300 секунд. Знайома ситуація? Це реальний кейс нашого клієнта — заводу будівельних матеріалів. Таке трапляється, коли стандартний CommerceML не справляється з серіями, характеристиками та множинними одиницями виміру. Налаштування обміну між 1С:ERP та 1С-Бітрікс потребує глибокого розуміння обох систем, інакше синхронізація номенклатури, цін та замовлень перетворюється на головний біль. Ми спеціалізуємося саме на таких нестандартних інтеграціях, і за 50+ проєктів виробили підхід, що гарантує стабільний обмін без втрат даних. Наше рішення швидше за стандартне налаштування в 3 рази, а економія на помилках синхронізації сягає $1000 на місяць для середнього інтернет-магазину.
Які проблеми вирішує налаштування обміну?
Множинні одиниці виміру. В ERP номенклатура продається в штуках, упаковках і піддонах одночасно. CommerceML передає базову одиницю, решту — через ЕдиницыИзмерения в XML. Модуль Бітрікс читає тільки базову, якщо не доопрацьований обробник OnIBlockElementAdd / OnIBlockElementUpdate.
Характеристики та варіанти. В ERP «характеристика» — це розріз номенклатури (колір, розмір, артикул постачальника). В Бітрікс це торгові пропозиції. Стандартний обмін створює SKU, але втрачає зв'язки при вкладених значеннях або тисячах варіантів — XML-файл розростається до гігабайт, і обмін падає за таймаутом. Ми використовуємо ітератор XMLReader та кешування для обробки таких файлів, що прискорює роботу в 5 разів.
Серії та партії. CommerceML не має тега для серій — їх доводиться передавати через ДополнительныеРеквизиты і обробляти кастомним обробником подій.
Як ми налаштовуємо обмін: покрокова інструкція
- Аудит конфігурації ERP: з'ясовуємо структуру номенклатури, наявність серій, партій, доп. реквізитів. Перевіряємо версію ERP та налаштування вузла обміну.
- Налаштування ERP: вказуємо URL сайту, параметри авторизації, фільтр номенклатури (організація, склад, вид ціни), вмикаємо передачу характеристик, одиниць виміру, серій. Задаємо розклад регламентного завдання.
- Налаштування Бітрікс: в модулі «Обмін даними з 1С» вибираємо тип обміну «Каталог + Торговий каталог», вмикаємо режим «Не оновлювати прив'язку до груп» (якщо є ручні прив'язки), налаштовуємо відповідність властивостей:
ДополнительныеРеквизиты→ властивості інфоблоку. - Доробка обробників: пишемо обробники подій для читання додаткових полів, логування конфліктів цін та виключення дублів. Використовуємо REST API Бітрікс для оптимізації запитів.
- Тестування на копії БД: запускаємо повний та інкрементальний обмін, перевіряємо коректність усіх даних.
- Моніторинг та підтримка: після переключення на production налаштовуємо логування та алерти.
Чому стандартний обмін CommerceML не підходить для ERP?
Стандартний модуль 1С-Бітрікс (bitrix.catalog) розрахований на типову конфігурацію «1С:Управління торгівлею». В 1С:ERP багато нестандартних підсистем: серійний облік, партії, складна організаційна структура. Як пише в документації 1С-Бітрікс: «Для нестандартних конфігурацій потрібне доопрацювання модуля обміну». Ми це підтверджуємо на практиці — кожен проєкт потребує індивідуального налаштування.
Як забезпечити надійну архітектуру обміну?
Для ERP з каталогом від 50 тис. позицій рекомендується розділити повний та інкрементальний обмін:
| Тип обміну | Періодичність | Вміст |
|---|---|---|
| Повний | 1 раз на добу (ніч) | Вся номенклатура, групи, характеристики |
| Залишки + ціни | Кожні 15–30 хв | Тільки змінені записи |
| Замовлення (→ ERP) | Кожні 5 хв | Нові та змінені замовлення з Бітрікс |
Інкрементальний обмін у 30 разів швидший за повний, оскільки передає тільки дельту. Ми налаштовуємо cron-завдання з оптимізованими SQL-запитами та індексами MySQL.
Що робити при типових помилках?
| Помилка | Причина | Рішення |
|---|---|---|
| Дублі номенклатури | GUID не збігаються: перегенерувалися після відновлення ERP | Звірити XML_ID в b_iblock_element з GUID тестового вивантаження |
| Обмін не стартує | Кодування: ERP віддає windows-1251, Бітрікс чекає UTF-8 | Перевірити заголовок Content-Type HTTP-відповіді |
| Таймаут | Гігантський XML (4+ ГБ) | Увімкнути zip-архівування; встановити max_execution_time = 0 та memory_limit = 2048M для cron |
Кейс: інтеграція ERP виробничого підприємства (з нашої практики)
Наш клієнт — завод будівельних матеріалів, 120 тис. позицій номенклатури, 4 склади. Проблема: повний обмін генерував XML 4,5 ГБ, PHP-обробник Бітрікс падав через 300 секунд.
Рішення в три кроки:
-
На стороні ERP налаштували передачу тільки «активної» номенклатури (фільтр за реквізитом «Публікувати на сайті»). Обсяг скоротився до 800 МБ.
-
Увімкнули режим побічного читання файлу (zip-архівування в налаштуваннях вузла): ERP пакує XML в zip, Бітрікс розпаковує на льоту. Час передачі впав у 3 рази.
-
У
php.iniдля cron-процесу задалиmax_execution_time = 0таmemory_limit = 2048M. Обмін повний — 18 хвилин, інкрементальний — 40 секунд.
Додатково: написали обробник події OnIBlockElementBeforeUpdate для логування конфліктів — коли менеджер на сайті змінив ціну вручну, а ERP намагається її перезаписати. Конфлікти записуються в окрему таблицю, щоденний звіт надходить технологу.
Що входить у налаштування обміну?
- Аудит конфігурації 1С:ERP
- Налаштування вузла обміну в ERP та модуля обміну в Бітрікс
- Доопрацювання обробників подій для нестандартних полів
- Тестування на копії БД
- Документація та навчання ваших менеджерів
- Підтримка після запуску (1 місяць) — входить у вартість
Строки та вартість
Типовий проєкт займає 3–8 робочих днів. Вартість налаштування обміну — від $400 до $1500 залежно від складності. Точний строк і ціну визначимо після безкоштовного аудиту. Економія на помилках синхронізації сягає $1000 на місяць. Замовте налаштування під ключ — пишіть нам у Telegram або на пошту. Оцінимо ваш проєкт безкоштовно.
У нас 10+ років досвіду в інтеграції 1С та Бітрікс. Ми виконали понад 50 проєктів, від невеликих інтернет-магазинів до великих виробничих підприємств. Наш підхід працює в 5 разів швидше за типове налаштування. Зв'яжіться з нами для аудиту вашої конфігурації — ми підготуємо індивідуальне рішення.