Інтеграція Бітрікс24 з 1С:Підприємство
Коли компанія виростає до 15–20 менеджерів, розрив між CRM і обліковою системою стає структурною проблемою. Дані про клієнтів, замовлення та оплати живуть у двох системах, які не розмовляють одна з одною. Менеджер бачить у Бітрікс24 угоду, але не знає, чи пройшла оплата в 1С. Бухгалтер бачить платіж, але не може прив'язати його до конкретної угоди без дзвінка менеджеру. Інтеграція Бітрікс24 з 1С:Підприємство — це не разове налаштування, а побудова двостороннього каналу обміну даними між двома системами.
Що саме синхронізується
Обсяг інтеграції залежить від бізнес-процесів компанії. На практиці виділяються три рівні:
Базовий — одностороння передача даних із 1С в Бітрікс24 (або навпаки):
- Контрагенти з 1С → компанії та контакти в CRM
- Номенклатура з 1С → каталог Бітрікс24
- Замовлення з Бітрікс24 → документи «Замовлення покупця» в 1С
Розширений — двостороння синхронізація зі зворотним зв'язком:
- Оплати з 1С → зміна стадії угоди в Бітрікс24
- Заборгованість контрагента з 1С → поле в картці компанії в CRM
- Відвантаження з 1С → оновлення статусу замовлення в Бітрікс24
Повний — синхронізація документообігу:
- Рахунки з Бітрікс24 → рахунки в 1С
- Акти виконаних робіт
- Накладні, рахунки-фактури
- Залишки товарів на складах у реальному часі
Технічні варіанти підключення
Архітектура інтеграції визначається насамперед тим, використовується хмарний або коробковий Бітрікс24, і яка конфігурація 1С.
REST API + webhooks — універсальний варіант. Бітрікс24 надає REST API для всіх об'єктів CRM. На стороні 1С розгортається HTTP-сервіс (web-сервіс 1С або зовнішній обробник на проміжному сервері). Працює як із хмарним, так і з коробковим Бітрікс24.
Стандартний модуль 1С-Бітрікс24 — вбудований у коробковий Бітрікс24. Обмінюється даними через протокол CommerceML або через COM-з'єднання (тільки для Windows-серверів). Основне призначення — синхронізація номенклатури та замовлень. Фінансові документи через стандартний модуль не передаються — потрібне доопрацювання.
Проміжна шина (ESB) — для складних сценаріїв із кількома юрособами, кількома базами 1С або нестандартними конфігураціями. У ролі шини використовуються рішення типу 1С:Конвертація даних 3.0 або власний middleware на PHP/Python.
| Варіант | Хмарний Б24 | Коробковий Б24 | Складність налаштування |
|---|---|---|---|
| REST API + webhooks | Так | Так | Середня |
| Стандартний модуль | Ні | Так | Низька (в базовому обсязі) |
| COM-з'єднання | Ні | Тільки Windows | Низька, але обмежено |
| ESB / middleware | Так | Так | Висока |
Синхронізація контрагентів: головний підводний камінь
На практиці саме синхронізація контрагентів викликає найбільше проблем. У 1С контрагент — юридична особа з ІПН. У CRM контакт — фізична особа, яка представляє компанію. Структура даних фундаментально різна.
Типові проблеми при злитті баз:
- Один і той самий клієнт заведений у 1С як «ТОВ Ромашка» і в Бітрікс24 як «Ромашка ТОВ» — без ІПН як ключа пошуку виникають дублі.
- У Бітрікс24 один контакт може бути прив'язаний до кількох компаній, у 1С — немає такої структури.
- Фізичні особи в CRM не мають ІПН, але можуть здійснювати покупки.
Рішення: ключ синхронізації — ІПН контрагента (для юросіб) або РНОКПП/телефон (для фізосіб). При первинному завантаженні запускається процедура дедублікації: знайти збіг за ІПН, при збігу — оновити, при відсутності — створити новий запис із виставленням XML_ID для подальшої ідентифікації.
Синхронізація номенклатури та залишків
Номенклатура передається з 1С в Бітрікс24 (або в обидві сторони, якщо в CRM створюються нові позиції). Для кожного товару критичні:
- Артикул (код товару) — ключ для ідентифікації. Артикул у 1С = XML ID товару в Бітрікс24.
- Одиниця виміру — маппінг одиниць ОКЕІ → одиниці в CRM.
- Ціни — якщо в 1С кілька типів цін (роздрібна, оптова, дилерська), потрібно визначити, яка ціна потрапляє в який прайс Бітрікс24.
- Залишки — за якими складами показувати, з якою періодичністю оновлювати.
Частота оновлення залишків залежить від обороту: для активної торгівлі — кожні 15–30 хвилин через регламентне завдання, для спокійного B2B — раз на годину достатньо.
Оплати та фінансові дані
Передача інформації про оплати з 1С в Бітрікс24 — ключова частина інтеграції для менеджерів. Менеджер має бачити в картці угоди:
- Чи надійшла оплата (так/ні)
- Сума оплаченого
- Дата оплати
- Залишок заборгованості
У 1С регламентне завдання перевіряє проведені документи «Надходження на розрахунковий рахунок» і «Прибутковий касовий ордер». Знайшовши прив'язаний до угоди Бітрікс24 платіж (за номером рахунку або замовлення), обробник викликає crm.deal.update і оновлює відповідні поля.
Кейс: оптово-роздрібна компанія, 3 юрособи
Компанія з трьома юридичними особами, 25 менеджерами та двома базами 1С (роздріб на 1С:Роздріб, оптовий напрямок на 1С:УТ 11). Завдання — єдиний Бітрікс24 для всіх менеджерів із видимістю фінансових даних з обох баз 1С.
Архітектурне рішення: проміжний PHP-сервіс агрегує дані з обох баз 1С і передає в Бітрікс24. Джерело даних кодується в кастомному полі угоди («Юрособа продавця»), що дозволяє обробнику в 1С зрозуміти, в яку базу записувати вхідні дані.
Окрема складність: взаєморозрахунки між юрособами. При переміщенні угоди між воронками різних юрособ потрібно було обнулити борг по одній і створити його по іншій. Реалізували через кастомну подію в бізнес-процесі Бітрікс24.
Строк повної реалізації: 3–4 місяці (включаючи 2 тижні на аудит даних і дедублікацію контрагентів, 6 тижнів на розробку та тестування, 2 тижні на поетапний перехід).
Підтримка та моніторинг інтеграції
Після запуску інтеграція потребує моніторингу. Типові збої:
- Зміна пароля API або ротація токенів Бітрікс24
- Оновлення платформи 1С, що змінює структуру OData
- Блокування IP проміжного сервера
- Помилки валідації даних при зміні форми в CRM (додали поле — зламали маппінг)
Мінімальний моніторинг: лог помилок обмінів із алертом по email при критичних збоях. Розширений — дашборд із метриками: кількість успішних/неуспішних синхронізацій за період, медіана часу передачі документа.