Интеграция Bitrix24 с 1С обычно ломается не потому, что «API плохой». Проблема начинается раньше: никто не договорился, где создаётся клиент, кто имеет право менять цену, какая система отвечает за оплату и что делать, если одна сторона недоступна. Ниже — схема, с которой стоит начинать ещё до установки модуля или написания собственного обмена.
- Понять, какие сущности действительно нужны в обмене
- Назначить источник истины по каждому объекту
- Заложить ID, журнал ошибок и повторные попытки до запуска
Сначала ответьте на один вопрос: зачем нужен обмен
Не начинайте со списка из пятидесяти полей. Зафиксируйте рабочий сценарий сотрудника. Например: менеджер ведёт сделку в Bitrix24, выбирает товары, отправляет заказ в 1С, а после оплаты и отгрузки видит фактический статус обратно в CRM. Такая формулировка сразу отделяет нужные данные от «давайте синхронизируем всё».
Официальная интеграция Bitrix24 и 1С поддерживает работу с контактами и компаниями, сделками и счетами, реквизитами, товарами, ценами, остатками, заказами, оплатами и отгрузками. Но полный набор нужен далеко не каждому проекту.
Чем меньше сущностей входит в первый рабочий контур, тем проще проверить качество обмена и понять, где возникает ошибка.
Какие данные обычно передают
Это не универсальная матрица. В некоторых компаниях заказ создаётся в 1С, а в CRM только отображается. В других — наоборот. Правильное направление определяется процессом, а не возможностью коннектора.
| Сущность | Частое направление | Зачем бизнесу |
|---|---|---|
| Контакты и компании | Bitrix24 ↔ 1С | Одинаковые контрагенты и реквизиты в продажах и учёте |
| Сделки / заказы | Bitrix24 → 1С | Передать согласованный заказ из CRM в учётную систему |
| Товары, цены, остатки | 1С → Bitrix24 | Менеджер работает с актуальным каталогом и доступностью |
| Счета и оплаты | 1С → Bitrix24 | Продажи видят факт денег без ручной сверки |
| Отгрузки | 1С → Bitrix24 | В карточке клиента понятен фактический статус исполнения |
| Печатные формы | 1С → Bitrix24 | Документы доступны сотруднику прямо из CRM |
Источник истины: правило, которое спасает интеграцию
По каждой сущности назначьте одну систему, которая имеет последнее слово. Цена и остаток чаще живут в 1С. Активность менеджера и стадия продажи — в CRM. Факт оплаты — в учётной системе. Если обе стороны могут независимо менять одно и то же поле, конфликт неизбежен.
Хорошая схема обмена прямо отвечает: что происходит при одновременном изменении, какое значение побеждает и кто увидит конфликт.
Внешний ID и антидубли
ФИО, телефон или название компании — плохой технический идентификатор. Телефон меняется, название пишут по-разному, а у одной группы компаний может быть несколько юридических лиц. Для устойчивого обмена нужен внешний ID и понятные правила первичного сопоставления.
Для компаний полезно дополнительно проверять ИНН/КПП, для товаров — код или внешний идентификатор номенклатуры. Но даже эти поля не заменяют системный ID после того, как объекты уже связаны.
Что должно происходить при сбое
Временная ошибка сети не должна превращаться в потерянный заказ. Событие сохраняется в очередь, получает номер попытки и повторяется. После нескольких неудач оно попадает в отдельный список ошибок, а ответственный получает сигнал.
Самая неприятная интеграция — та, которая «обычно работает». Сотрудник узнаёт о проблеме через два дня, когда клиент спрашивает, почему нет счёта. Поэтому журнал обмена — часть продукта, а не технический бонус.
- время события и направление обмена
- тип объекта и его внешний ID
- статус: успешно / повтор / ошибка
- текст ошибки без секретов и токенов
- число попыток и время следующего retry
Штатный модуль или кастомная интеграция
Не нужно писать собственную интеграцию только ради слова «кастомная». Если штатный сценарий закрывает задачу и его можно нормально сопровождать, это обычно лучший старт. Кастом имеет смысл там, где появляется реальное бизнес-правило, которого нет в готовом обмене.
| Сценарий | Что разумнее |
|---|---|
| Типовой обмен стандартными сущностями | Начать со штатных возможностей 1С + Bitrix24 |
| Большой объём данных и свои правила сопоставления | Добавить middleware / очередь / контроль |
| Собственная ERP или сильно доработанная 1С | Проектировать кастомный обмен через API |
| Нужны нестандартные бизнес-события | Webhooks + REST API + журнал |
Как принять интеграцию перед запуском
Если эти тесты нельзя пройти руками и получить однозначный результат, обмен ещё рано считать готовым.
- Создать нового клиента в одной системе и проверить вторую
- Изменить реквизиты и убедиться, что правило приоритета работает
- Передать заказ с несколькими товарами и скидкой
- Проверить оплату и частичную отгрузку
- Искусственно отключить одну сторону и убедиться, что событие не потерялось
- Повторить одно событие и проверить, что дубль не появился
Перед тем как закрыть задачу
- ✓Есть схема источников истины
- ✓Для объектов определены внешние ID
- ✓Понятно, что происходит при конфликте
- ✓Есть журнал и повторные попытки
- ✓Составлены тест-кейсы на сбой и дубль
Рабочая интеграция Bitrix24 и 1С начинается не с кнопки «Установить модуль», а с архитектуры данных. Сначала определите, что именно должен видеть сотрудник в своём рабочем окне. После этого становится понятно, какие сущности передавать, в какую сторону и как проверить, что обмен не потерял данные.
