Інтеграція 1С-Бітрікс з 1С:Підприємство
CommerceML: чому стандартний обмін — це і порятунок, і пастка
Модуль обміну на базі CommerceML 2.0 — перше, що підключають. І правильно: з типовим Управлінням торгівлею або Комплексною автоматизацією він запускається за день-два. Товари, ціни, залишки, замовлення — все через XML-файли за розкладом. Для магазину на 3 000 позицій з парою оновлень на добу цього вистачає з запасом.
Проблеми починаються, коли каталог перевищує 30 000 SKU.
bitrix_1c_exchange.php генерує XML на стороні Бітрікса, 1С його забирає і парсить. На великих каталогах парсер починає активно писати у тимчасову таблицю b_xml_tree — і ось тут MySQL може зупинитися. Ми бачили проєкт, де стандартний обмін 180 000 товарів тривав 6 годин і повністю блокував сервер: ні адмінка, ні фронт не відкривались.
Рішення — інкрементальний обмін. У налаштуваннях вузла обміну на стороні 1С ставимо «Вивантажувати лише змінені» та розбиваємо вивантаження на пакети по 500–1000 елементів. На стороні Бітрікса — кастомний обробник, який не перестворює b_xml_tree кожного разу, а працює через CIBlockXMLFile::ReadXMLToDatabase() з контролем порцій. Каталог на 200 000 SKU починає оновлюватись за 8–12 хвилин.
Ще одна класична пастка — EXTERNAL_ID. Під час повторного імпорту товарів Бітрікс зіставляє елементи інфоблоків за зовнішнім кодом. Якщо в 1С товар було видалено та створено заново з новим GUID, на сайті з'являється дубль. Зі старими відгуками на одній картці та нульовими — на іншій. Лікується жорсткою прив'язкою за артикулом через кастомний обробник події OnBeforeIBlockElementAdd.
Коли CommerceML вже не витягує
Сильно доопрацьована 1С — це не виняток, це норма. «У нас типова конфігурація» — каже кожен другий клієнт, а потім ми відкриваємо базу і бачимо 200 кастомних обробок, перейменовані реквізити та саморобні документи реалізації.
CommerceML працює з фіксованою структурою XML. Якщо в 1С змінили склад реквізитів номенклатури або додали нестандартний документ — обмін мовчки пропускає ці дані. Або падає з незрозумілою помилкою в журналі реєстрації 1С, а в Бітріксі взагалі нічого не пишеться.
У таких випадках робимо кастомне вивантаження. На стороні 1С пишемо обробку, яка формує JSON (не XML — парсити швидше, дебажити простіше) і відправляє через REST API Бітрікса. Повний контроль: які поля беремо, як трансформуємо, що робимо при конфлікті. Для зовсім важких випадків — D7 API з прямою роботою через \Bitrix\Catalog\ProductTable та \Bitrix\Sale\Order.
Ціни, залишки та мультисклад
Стандартний обмін вміє передавати один тип ціни. У реальності їх може бути 15: роздрібна, оптова, дилерська, акційна, регіональна, валютна. Плюс у кожної — своя група покупців і пріоритет. Маппінг між ціновими групами 1С та групами користувачів Бітрікса — окрема інженерна задача. Особливо весело, коли знижки перетинаються і потрібно визначити, яка ціна перемагає.
Мультисклад додає ще один рівень: товар є на складі в одному місті, немає в іншому, і «під замовлення» в третьому. На сайті потрібно показати наявність по кожній точці, підключити вибір пункту самовивозу та розрахувати доставку від найближчого складу, де товар фізично є. Стандартний модуль складського обліку Бітрікс (catalog.store) справляється з відображенням, але логіку «звідки відвантажувати» пишемо окремо.
Замовлення та документообіг
Замовлення з сайту летить в 1С, формується реалізація, товар резервується. Статуси повертаються назад. На папері — просто. На практиці — нюанси.
Головний: часткове відвантаження. Клієнт замовив 5 позицій, 3 є на складі, 2 прийдуть через тиждень. 1С формує два документи реалізації. Бітрікс з коробки не вміє розбивати одне замовлення на кілька відвантажень — доопрацьовуємо обробник OnSaleOrderSaved, який створює дочірні замовлення та синхронізує статуси по кожному.
Документи в особистому кабінеті — рахунки, акти, накладні з 1С — віддаємо через REST, PDF генерується на стороні 1С і кешується на CDN. Покупець завантажує не з 1С напряму (це вбило б сервер), а з кешу.
Моніторинг: не «налаштував і забув»
Обмін може зламатися тихо. Скрипт відпрацював, помилок у лозі немає, але 200 товарів не оновились через невалідний UTF-8 у назві. Або 1С змінила формат дати в черговому оновленні, і всі ціни прийшли нульовими.
Мінімальний набір, який ставимо на кожному проєкті:
- Алерт у Telegram, якщо час обміну зріс у 3+ рази від середнього
- Перевірка розходження залишків: скрипт порівнює
b_catalog_product.QUANTITYз тим, що віддає 1С, і сигналізує при дельті більше 5% - Дашборд: остання синхронізація, кількість оброблених позицій, черга, помилки
Для проєктів із високим навантаженням додаємо асинхронні черги на Redis або RabbitMQ. Обмін не блокує веб-сервер, дані не втрачаються при короткочасному падінні 1С.
Зв'язка з Бітрікс24
Якщо крім сайту є корпоративний портал на Бітрікс24 — пов'язуємо і його. Контрагенти з CRM летять в 1С, рахунки з 1С з'являються в картці угоди. Менеджер бачить дебіторку та взаєморозрахунки, не перемикаючись між вікнами. Закрили угоду — документи сформувались самі.
Оплата надійшла в 1С → логіст отримує задачу на відвантаження в Бітрікс24. Товар відвантажено → менеджер бачить сповіщення. Автоматичні задачі за подіями з 1С — через вебхуки Бітрікс24 REST API.
Вартість
Типовий обмін каталогом та замовленнями через CommerceML — від 50 000 ₽, запускається за 1–2 тижні. Розширений обмін із мультискладом, типами цін та контрагентами — від 120 000 ₽. Повна кастомна інтеграція 1С + сайт + Бітрікс24 — від 250 000 ₽, термін 1–2 місяці. Окупається за 2–6 місяців: магазин із 5 000 товарів економить 40–80 годин ручної роботи оператора на місяць, а автоматична синхронізація залишків прибирає ситуації «замовив — а товару немає».