Сквозной обмен данными между CRM, сайтом и учётной системой: с чего начать

Сквозной обмен данными - это когда заявка, клиент, заказ и оплата автоматически переходят между сайтом, CRM и учётной системой без повторного ввода, и по каждому объекту заранее известно, какая система главная. Начинать стоит не с подключения, а с карты потоков: что передаётся, в какую сторону, по какому общему идентификатору и что делать при расхождении.

Сквозной обмен легко спутать со сквозной аналитикой, но это разные задачи: сквозная аналитика отвечает на вопрос, какая реклама привела к оплате, а сквозной обмен переносит сами записи между системами. Ниже - метод, по которому карту обмена можно составить самому до разговора с подрядчиком: пять вопросов к каждому объекту и таблица-шаблон, которую остаётся заполнить.

Что такое сквозной обмен и чем он отличается от набора отдельных интеграций

Целевая картина выглядит так. Клиент оставил заявку на сайте - она стала сделкой в CRM. После согласования сделка ушла заказом в учётную систему, там выставили счёт и приняли оплату. Статус вернулся в CRM, и менеджер видит, что деньги пришли. Никто не перепечатывает телефон и сумму, а руководитель смотрит на одну картину, а не на три разные.

Когда к этому идут кусками - сначала форма сайта, потом обмен с 1С, потом склад, - каждая связка может работать по своим правилам: сайт создаёт клиента по телефону, учётная система - по ИНН, CRM - по имени из формы. В итоге один клиент живёт в трёх версиях, и неясно, какая правильная.

Сквозной обмен отличается не количеством подключений, а тем, что у всех связок общие правила. Технически данные передаются через интерфейс программирования (API) - способ, которым одна программа читает и меняет данные другой без участия человека. Ещё один инструмент - вебхук: уведомление, которое система сама отправляет другой системе в момент события.

Карта потоков: какие данные, откуда и куда

Карта потоков - это таблица, где одна строка соответствует одному объекту: заявке, клиенту, товару, цене, остатку, заказу, счёту, оплате. По каждой строке нужно ответить на пять вопросов: какая система главная, в какую сторону идут данные, в какой момент, по какому общему ключу записи сопоставляются и кто разбирает ошибку. Пустая клетка в таблице - это вопрос, который иначе всплывёт уже после запуска.

Таблицу удобнее заполнять вместе: руководитель продаж знает, где рождается клиент, бухгалтер - где выставляется счёт. Если на какой-то строке мнения разошлись, это и есть место будущих расхождений в данных.

В каком порядке подключать

Порядок подключения следует из карты. Сначала поток «сайт → CRM»: он короткий, ошибки в нём видны сразу, а без него заявки теряются ещё до продажи. Почему часть заявок всё равно уходит мимо системы, разобрано в статье «Форма на сайте и CRM», а как подключают сайт - на странице интеграции с сайтом. Потом обмен «CRM ↔ учётная система»: в нём больше объектов и участников, поэтому его запускают, когда первый поток стабилен (интеграция с 1С). Способы подключения для Битрикс24 собраны в обзоре интеграций Битрикс24, а пример того, как метод ложится на пару amoCRM и 1С, - в статье «Интеграция amoCRM с 1С».

Какая система главная по каждому объекту: клиент, товар, цена, заказ, оплата

Главная система (её ещё называют источником правды) - та, где объект создают и меняют, остальные получают копию. У каждого объекта ровно одна главная система. Вариант «главная везде CRM» или «везде 1С» обычно не подходит: продажи и бухгалтерия отвечают за разные данные.

Главная система может меняться по ходу жизни объекта. Заказ до согласования принадлежит CRM: менеджер меняет состав и скидку. После передачи в учёт правки идут уже там, а CRM только показывает статус. Запишите это в карту явно, иначе менеджер поправит сумму в CRM после отгрузки, и системы разойдутся без единой ошибки в журнале.

Для склада логика та же. В статье про amoCRM и МойСклад разобрано, кто отвечает за остатки и резерв, когда продажи и склад живут в разных системах. Какие именно объекты 1С: Бухгалтерии и УНФ участвуют в обмене с CRM, - тема отдельной статьи «Интеграция CRM с 1С: Бухгалтерией и УНФ». Здесь 1С - только пример учётной системы.

Общий ключ: как системы понимают, что это одна и та же запись

Дубли при обмене могут появляться не по вине менеджера. Причина в том, что у систем нет общего ключа. Когда учётная система получает заказ, она должна понять, знает она этого клиента или нет. Если искать по названию, «ООО Ромашка» и «Ромашка ООО» станут двумя контрагентами. Если по телефону, клиент со сменившимся номером превратится в нового.

Общий ключ - это номер записи из одной системы, сохранённый в другой. Надёжная схема выглядит так: при первой передаче система-получатель создаёт запись и возвращает свой номер, а система-отправитель его сохраняет. Дальше записи сопоставляются по этому номеру, а не по похожести названий. Номер в обе стороны хранят либо в полях самих систем, либо в таблице соответствий интеграции.

Поиск по телефону и почте полезен как страховка перед созданием нового клиента, но ключом быть не может: у компании несколько телефонов, сотрудник клиента меняет почту. Для юрлиц в материалах интеграторов часто советуют сопоставлять клиентов по ИНН и КПП. Это распространённая практика, но у физических лиц ИНН в данных обычно нет, поэтому номер записи всё равно нужен. Как разбирать уже накопившиеся дубли, рассказано в статье «Дубли контактов и сделок в amoCRM».

Отдельный риск - переустановка модуля обмена: в справке Битрикс24 по коннектору с 1С разобран случай, когда после неё появились дубликаты настроек или данные перестали синхронизироваться. Таблица соответствий ключей - такие же ценные данные, как сами клиенты, и её копию стоит сохранить до работ с модулем.

Направление и момент обмена: в одну сторону, в обе, по событию или по расписанию

Направление определяют по главной системе: данные идут от главной к остальным. Односторонний обмен нужен, когда объект правят только в одном месте, а остальные системы его показывают. Пример - цены и остатки из учёта в CRM. Двусторонний нужен, когда разные части объекта меняются в разных системах: заказ создаёт CRM, а счёт, оплату и отгрузку возвращает учёт.

Двусторонний обмен не «лучше» одностороннего. Он нужен, где без него менеджер не узнает о важном событии, и опасен, где одни и те же поля правят с двух сторон. В публичном разборе ошибок интеграции Битрикс24 и 1С на vc.ru правка одних данных в обеих системах названа среди причин дублей и расхождений.

Момент обмена - второе решение: по событию (сразу, например вебхуком) или по расписанию (раз в N минут или ночью). Важная деталь: событие доходит не всегда. В документации Битрикс24 сказано, что если обработчик не ответил или вернул ошибку, сервер очередей зафиксирует сбой, но не отправит событие повторно. amoCRM ждёт ответа на вебхук не больше двух секунд, при ошибке делает ещё несколько попыток с паузами, а после большого числа неудачных ответов может отключить вебхук. Если в эту минуту учётная система обновлялась или сервер интеграции перезагружался, оплата в CRM не появится, и без сверки никто об этом не узнает.

Поэтому надёжная схема - по событию и сверка по расписанию, а не одно из двух. У платформ для этого есть свои механизмы. Коннектор 1С ↔ Битрикс24 умеет обмен в реальном времени, когда синхронизацию запускают изменения на любой из сторон, и по расписанию, например раз в день. В Битрикс24 это офлайн-события: изменения копятся в очереди, а внешняя система забирает их сама, когда готова. В очереди хранится текущее состояние объекта, а не история всех правок. В 1С механизм «план обмена» отмечает изменённые данные и снимает отметку только после того, как получатель подтвердил приём. Общий принцип для любой пары систем: запись считается переданной, когда получатель подтвердил, что её принял.

Почему бы просто не перекачивать всё каждые пять минут? Мешают лимиты запросов. У amoCRM - не больше 7 запросов в секунду на одну интеграцию, а при многократных превышениях блокируют весь аккаунт, и страдают все его интеграции. У Битрикс24 базовый лимит - 2 запроса в секунду, отдельно учитывается время выполнения тяжёлых методов. Полная выгрузка тысяч товаров упирается в эти ограничения, поэтому сверку строят на изменённых записях и передают их пачками. Условия меняются - перед работой сверяйте со справкой разработчика.

Конфликт данных: правило «кто прав» и поля, которые правят только в главной системе

Конфликт - это когда одно и то же поле изменили в двух системах между обменами. Условный пример: менеджер в CRM поправил юридическое название клиента, а бухгалтер в учёте в тот же день обновил реквизиты и тоже исправил название, но иначе. При следующем обмене одна из версий перезапишет другую, и важно заранее знать, какая.

Правило выбирают при составлении карты, а не после первого спора:

• Главная система побеждает. Значение из неглавной системы перезаписывается при следующем обмене. Самое предсказуемое правило, если сотрудники знают, где править.
• Побеждает последнее изменение. Звучит справедливо, но зависит от точного времени в обеих системах и от того, кто позже нажал «сохранить», а не от того, кто прав.
• Ручной разбор. Расхождение уходит в журнал, владелец данных решает сам. Подходит для редких и важных полей: реквизиты, сумма заказа после отгрузки.

Вторая часть правила - список полей, которые правят только в главной системе. В неглавной системе такое поле можно закрыть для правки правами, если платформа это позволяет, вынести в отдельный блок с подписью «из учёта» или хотя бы закрепить запрет в регламенте. Условный пример: цена товара приходит в CRM из учёта, менеджер даёт скидку в пределах правила, но базовую цену не меняет.

Когда записи в системах сходятся, их можно собирать на общую панель показателей: продажи и деньги перестают спорить друг с другом в отчётах руководителя.

Журнал ошибок и ответственный: как узнать о сбое раньше клиента

Любой обмен однажды ошибётся: учётная система обновилась, поле переименовали, получатель не ответил. Вопрос не в том, будут ли сбои, а в том, кто узнает о них первым - сотрудник или клиент, которому не пришёл счёт.

Журнал ошибок - место, куда интеграция записывает каждую неудачную передачу: что, куда, когда, с каким ключом и почему не прошло. В модуле коннектора 1С ↔ Битрикс24 такой журнал есть штатно: по справке, он фиксирует сбои и оповещает пользователей об ошибках. У индивидуальной интеграции журнал закладывают в проект отдельно, иначе ошибки останутся в технических записях сервера, которые никто не читает.

У журнала должен быть владелец - конкретный человек со стороны компании, а не «подрядчик посмотрит». Он получает уведомления, разбирает ошибки в данных, а технические сбои передаёт тому, кто сопровождает интеграцию. И заводите интеграцию на служебную учётную запись, а не на личную: входящий вебхук Битрикс24, например, работает с правами сотрудника, который его создал. В разборе на vc.ru привязка к личной учётной записи и отсутствие мониторинга тоже названы среди типичных ошибок.

Если обмен уже работает, а дубли и расхождения всё равно появляются, начните с признаков из статьи «Как понять, что текущая интеграция CRM работает нестабильно».

С чего начать: четыре шага до разговора с подрядчиком

1. Составьте карту потоков. Выпишите объекты и заполните таблицу-шаблон хотя бы для заявки, клиента, заказа и оплаты.
2. Назначьте главную систему по каждому объекту и запишите поля, которые правят только в ней, и правило конфликта.
3. Проверьте, как каждая система отдаёт и принимает данные: есть ли у неё интерфейс программирования, готовый модуль обмена или только выгрузка файлом. У распространённых CRM и учётных систем способы обмена описаны в документации, а у самописного сайта или доработанной конфигурации 1С это нужно проверять отдельно.
4. Подключайте по очереди: сначала «сайт → CRM», потом «CRM ↔ учёт». Следующий поток - когда журнал предыдущего пуст или разобран.

Понять, какой обмен нужен именно вам, поможет тест о выборе обмена данными. А если подрядчик обещает «настроить любые интеграции» и не спрашивает о главной системе и ключах, стоит насторожиться - почему это плохой признак.

Частые вопросы

Вывод

Сквозной обмен держится не на модуле, а на договорённостях: у каждого объекта одна главная система, записи узнают друг друга по общему ключу, событие страхуется сверкой по расписанию, а у журнала ошибок есть владелец. Эти правила помещаются в одну таблицу, и её можно заполнить до разговора с подрядчиком.

С готовой картой разговор становится предметным. Разбор систем и потоков входит в диагностику: по её итогам в паспорте перехода видно, что и в каком порядке подключать. Сам обмен оцениваем после разбора процессов: проверяем готовые решения и, если их не хватает, проектируем индивидуальную интеграцию. Подробнее - на странице интеграций.

Источники

• Битрикс24: добавление сделки, поля ORIGINATOR_ID и ORIGIN_ID
• Битрикс24: добавление контакта, поля привязки к внешней системе
• Битрикс24: добавление компании, поле ORIGIN_ID
• Битрикс24: поиск дублей по телефону и почте
• Битрикс24: события и их повторная отправка
• Битрикс24: офлайн-события
• Битрикс24: входящие и исходящие вебхуки
• Битрикс24: ограничения REST API
• Битрикс24: коннектор к 1С, режимы синхронизации
• Битрикс24: коннектор к 1С, настройка модуля и журнал ошибок
• Битрикс24: частые вопросы по коннектору к 1С
• amoCRM: контакты, поля модели
• amoCRM: сделки, поля модели и комплексное добавление
• amoCRM: контроль дублей для интеграций
• amoCRM: формат вебхуков и повторная доставка
• amoCRM: рекомендации и ограничения по API
• 1С: протокол обмена с сайтом
• 1С: механизм «План обмена»
• 1С: REST-интерфейс платформы
• vc.ru: ошибки при интеграции Битрикс24 и 1С (колонка интегратора)