Запрос от клиента звучит просто: хотим, чтобы заказы из Bitrix24 сами попадали в 1С. За этой фразой прячется десяток решений, и от выбора зависит, будет интеграция работать годами или ломаться каждую неделю.
Вебхук или приложение: с чего начинать интеграцию 1С и Bitrix24
Вебхук это адрес, на который Bitrix24 отправляет события, а ваш сервис их принимает и обрабатывает. Приложение с авторизацией через OAuth устроено сложнее и умеет больше. Что выбрать, зависит от того, сколько у вас сценариев и порталов:
| Что важно | Вебхук | Приложение с OAuth |
|---|---|---|
| Сценарии | немного однотипных событий | несколько разных сценариев |
| Работа с данными | принимает события | принимает события и читает данные портала |
| Сколько порталов | один | больше одного |
| Настройка | около часа | заметно дольше, закладывать в план сразу |
Разница в трудоёмкости заметная, поэтому решать надо до начала, а не переделывать потом, когда на вебхук уже навесили 3 сценария, для которых он не предназначен.
Почему интеграция создаёт задвоенные заказы
Самый частый способ сделать интеграцию хрупкой: обработать вебхук синхронно, прямо в момент запроса. 1С в этот момент может быть недоступна, может обновляться или просто отвечать медленно. Bitrix24 не дождётся ответа, посчитает доставку неудачной и повторит отправку, а дальше вы получаете задвоенные заказы и разбираетесь, какой из них настоящий.
Правильно так: принять событие, положить в очередь и сразу ответить Bitrix24, что приняли. Обработкой занимается отдельный процесс, который умеет ждать 1С, повторять попытки и складывать неудачи в отдельный список для разбора.
Как защититься от повторной доставки событий
К очереди обязательно идёт идемпотентность. Это свойство обработчика, при котором повторная обработка того же события ничего не меняет: у каждого события есть идентификатор, и если он уже обрабатывался, второй заказ не создаётся. Без этого очередь не спасёт, потому что повторная доставка от Bitrix24 будет, и каждая снова приведёт к дублям.
Как сопоставлять товары, контрагентов и скидки в 1С и Bitrix24
1С и Bitrix24 по-разному смотрят на одни и те же вещи. Строка документа реализации в 1С превращается в товарную позицию сделки в Bitrix24, и соответствие между ними не всегда однозначное. Проблемные места примерно одни и те же от проекта к проекту:
- Номенклатура: по какому полю сопоставлять (артикул, код или название) и что делать, если совпадения нет.
- Контрагенты: один и тот же клиент часто заведён в обеих системах, и реквизиты у него там разные.
- Скидки и цены: в Bitrix24 скидка может быть на позицию, а в 1С на весь документ.
- Валюты и НДС, если вы работаете не только по России.
Эти правила надо описать словами до написания кода. Обычно в этот момент выясняется, что единого мнения о том, как правильно, в компании нет, и договориться об этом важнее любой технической детали.
Что писать в журнал, чтобы найти потерянный заказ
Когда через месяц выяснится, что заказ не доехал до 1С, разбираться придётся по журналу. Поэтому в нём должно быть:
- Каждое входящее событие целиком, в сыром виде: восстановить причину сбоя можно будет только по нему.
- Результат обработки и причина отказа. Список неудачных событий должен быть виден человеку, а не лежать в логе на сервере.
- Время обработки: его рост обычно первый признак того, что скоро что-то сломается.
Как мы делаем интеграцию 1С и Bitrix24
Закрываем такие интеграции полным циклом: разбор бизнес-процесса, выбор архитектуры обмена, написание сервиса-посредника и его сопровождение. Со стороны учёта это работа по 1С, со стороны CRM по Битрикс24, и когда обе стороны ведёт один подрядчик, не приходится выяснять, чья половина обмена сломалась. Про выбор между разными инструментами автоматизации есть отдельный разбор: парсер, бот, сервис или агент.
Пришлите нам список того, что должно ехать из Bitrix24 в 1С и обратно, или опишите, как обмен работает сейчас. На созвоне скажем, хватит ли вебхука или нужно приложение, а в смете до старта отдельными строками распишем очередь, правила сопоставления и журнал ошибок. Доплат по ходу без согласования не будет.