Розробка інтеграції Bitrix24 з ERP-системами
Bitrix24 — фронт-офіс: CRM, завдання, комунікації. ERP (SAP, 1С:ERP, Microsoft Dynamics, Odoo, Oracle) — бек-офіс: виробництво, фінанси, склад, закупівлі. Інтеграція між ними потрібна, щоб менеджер у CRM бачив реальні залишки, а виробництво отримувало замовлення без ручного перенесення. Але це одне з найскладніших завдань у корпоративній автоматизації — ERP-системи архітектурно не призначені для частих зовнішніх запитів, а обсяги даних обчислюються мільйонами записів.
Типові сценарії синхронізації
Довідники контрагентів. Клієнт створюється в Bitrix24 (лід → компанія) і має з'явитися в ERP для виставлення рахунку. Або навпаки — постачальник із ERP потрібен у CRM для роботи менеджера із закупівель. Майстер-дані (картка контрагента, реквізити) зберігаються в одній системі, друга є споживачем.
Товарний каталог та залишки. ERP — джерело правди щодо залишків та цін. Bitrix24 отримує актуальні дані: менеджер при створенні угоди бачить реальний залишок складу, а не дані вчорашнього дня.
Замовлення. Угода переходить у статус «Договір підписано» — в ERP автоматично створюється замовлення на виробництво або відвантаження. Статус виконання замовлення з ERP оновлює стадію угоди в CRM.
Фінансові документи. Рахунок із Bitrix24 → ERP для обліку та формування первинної документації. Платіж з ERP (факт оплати) → CRM для закриття угоди.
Архітектурні підходи
Пряма peer-to-peer інтеграція (Bitrix24 ↔ ERP) — антипаттерн для складних систем. Правильна архітектура включає проміжний шар.
Інтеграційна шина (ESB/iPaaS). Bitrix24 і ERP спілкуються через посередника: Apache Kafka, RabbitMQ, або iPaaS-платформу (1С-інтегратор, Mulesoft, WSO2). Шина нормалізує формати даних, забезпечує гарантію доставки, зберігає історію повідомлень. Це стандарт для enterprise.
Мікросервіс-адаптер. Власний сервіс (PHP/Python/Go), який знає обидва API. Приймає події від Bitrix24 через webhook, трансформує дані, викликає API ERP. І у зворотний бік. Простіший у реалізації, гірше масштабується при зростанні кількості інтегрованих систем.
Файловий обмін через FTP/S3. Працює з ERP-системами, які не надають API (застарілі версії SAP R/2, окремі конфігурації 1С). ERP вивантажує XML/CSV за розкладом, адаптер забирає файл, парсить, завантажує до Bitrix24. Надійно, але є лаг у кілька хвилин.
Інтеграція з 1С:ERP
Найпоширеніший кейс. Технічні варіанти:
Через REST API Bitrix24 + HTTP-сервіс 1С. 1С:ERP підтримує публікацію HTTP-сервісів (аналог REST-ендпоінтів). Адаптер викликає HTTP-сервіс 1С для отримання даних та REST API Bitrix24 для їх запису. Напрямок ініціації запиту важливий: для синхронних операцій (перевірити залишок) — Bitrix24 ініціює запит до 1С. Для асинхронних подій (замовлення виконано) — 1С через HTTP-запит сповіщає Bitrix24-webhook.
Через штатний обмін. Якщо вже налаштований обмін 1С ↔ сайт на Bitrix (CommerceML), його розширюють для потреб CRM. Це компроміс — протокол CommerceML заточений під інтернет-магазин, для CRM-даних його доводиться адаптувати.
Через проміжну БД. 1С записує зміни до окремої БД (PostgreSQL, MySQL), адаптер читає звідти і публікує в Bitrix24. Повільніше, але ізолює ERP від навантаження прямих API-запитів.
Трансформація даних
Головна технічна складність — невідповідність моделей даних. Приклад: в ERP контрагент — це юридична особа з ЄДРПОУ/ІПН, розрахунковими рахунками, кількома договорами. У Bitrix24 — це crm.company з набором полів та прив'язаними контактами. Потрібен маппінг:
| ERP-сутність | Bitrix24-сутність | Ключ зв'язку |
|---|---|---|
| Контрагент | crm.company | ЄДРПОУ (UF_INN) |
| Договір | crm.deal (тип «Договір») | Номер договору (UF_CONTRACT_ID) |
| Номенклатура | Товар каталогу (crm.product) | Код 1С (XML_ID) |
| Замовлення покупця | crm.deal | Номер замовлення ERP (UF_ERP_ORDER_ID) |
| Рахунок на оплату | crm.invoice | Номер рахунку ERP (UF_ERP_INVOICE_ID) |
Ключі зв'язку (зовнішні ідентифікатори) зберігаються в користувацьких полях UF_*. Це дозволяє ідемпотентно оновлювати записи без дублювання: перед створенням шукаємо за ключем, якщо знайшли — оновлюємо, ні — створюємо.
Управління конфліктами
При двосторонній синхронізації конфлікти неминучі: той самий запис змінюється в обох системах одночасно. Стратегії:
- Майстер-система. Для кожного типу даних призначається джерело правди. Ціни та залишки — з ERP, коментарі та історія комунікацій — з Bitrix24. Запис у майстер-системі завжди пріоритетний.
- Timestamp-based merge. Перемагає пізніший запис. Працює для простих полів, ламається при одночасних змінах.
- Блокування. Після відправки даних в одну систему поле позначається як «у синхронізації», доки не надійде підтвердження. Складно реалізувати, але надійно.
Моніторинг та налагодження
Інтеграція з ERP — довготривала система. Потрібен моніторинг:
- Черга повідомлень: розмір черги, кількість необроблених повідомлень
- Помилки трансформації: невідповідність типів даних, відсутні довідкові значення
- Лаг синхронізації: час між зміною в джерелі та появою в цільовій системі
- Дашборд за метриками — у Grafana або через вбудовані звіти Bitrix24
Етапи проєкту
| Етап | Зміст | Термін |
|---|---|---|
| Аналітика і ТЗ | Карта даних, сценарії, вибір архітектури | 2–3 тижні |
| Прототип адаптера | Один сценарій (наприклад, синхронізація контрагентів) | 1–2 тижні |
| Розробка основних сценаріїв | Повний набір інтеграційних потоків | 3–6 тижнів |
| Маппінг довідників | Приведення НДІ до єдиного вигляду | 1–2 тижні |
| Тестування | Граничні випадки, навантаження, конфлікти | 1–2 тижні |
| Міграція історичних даних | Перенесення накопиченої бази | 1–3 тижні |
| Пілот та стабілізація | Робота на обмеженому обсязі даних | 1–2 тижні |
Проєкт інтеграції з ERP — це не разова розробка, а довгострокова система, яку потрібно підтримувати при оновленні будь-якої з платформ. Це треба закладати в бюджет із самого початку.