Подготовка интеграции Битрикс24 и 1С: что решить до разработки

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

Конкретная реализация зависит от конфигурации и версии 1С, редакции Битрикс24, доступных интерфейсов и инфраструктуры. Поэтому до оценки разработки нужен короткий этап обследования.

Сформулируйте деловую цель

Фраза «синхронизировать всё» не помогает проектированию. Назовите действия, которые должны стать проще или надёжнее.

Примеры целей без привязки к реализации:

• исключить повторный ввод согласованных реквизитов;
• передавать в CRM подтверждённый статус учётной операции;
• показывать менеджеру данные, необходимые для коммуникации с клиентом;
• передавать одобренную заявку в учётный контур;
• связывать записи двух систем по устойчивому идентификатору.

Для каждой цели укажите пользователя результата. Если передаваемое поле никто не использует в процессе или отчёте, возможно, его не нужно включать в первый этап.

Определите владельца каждого объекта

Один и тот же клиент, заказ или товар может присутствовать в обеих системах, но одна из них должна считаться источником конкретного типа данных.

Реестр объектов обмена

Составьте таблицу объектов:

• контрагент;
• контакт;
• товар или услуга;
• заказ;
• счёт;
• платёжный статус;
• договор;
• подразделение;
• пользователь;
• другие необходимые сущности.

Для каждого объекта зафиксируйте, где он создаётся, где редактируется, какие поля передаются и кто отвечает за справочник. Владелец объекта и владелец отдельного поля могут различаться, но такое исключение должно быть обосновано.

Проведите инвентаризацию полей

Названия полей в двух системах не гарантируют одинаковый смысл. «Статус», «сумма» или «ответственный» могут рассчитываться и использоваться по-разному.

Для каждого передаваемого поля запишите:

• деловое назначение;
• тип и формат;
• обязательность;
• допустимые значения;
• источник;
• направление передачи;
• правило изменения;
• поведение при пустом значении;
• доступ пользователей;
• необходимость исторического переноса.

Особенно внимательно проверьте даты, денежные значения, ставки налогов, единицы измерения и составные реквизиты. Ошибку формата лучше обнаружить на таблице сопоставления, а не после загрузки данных.

Выберите устойчивые идентификаторы

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

Опишите:

• как связывается новая запись;
• где хранится идентификатор второй системы;
• что происходит при повторной отправке;
• как обнаруживается дубль;
• кто разбирает неоднозначное совпадение;
• можно ли безопасно восстановить связь после ошибки.

Операция повторной передачи не должна бесконтрольно создавать новую сущность. Это проверяется отдельным сценарием приёмки.

Определите направление и момент обмена

Для разных данных подходят разные правила. Одни передаются после подтверждённого события, другие обновляются по согласованному расписанию, третьи запрашиваются пользователем.

Не выбирайте режим обмена только по желанию видеть изменения «мгновенно». Учитывайте источник истины, допустимую задержку, нагрузку, доступность систем и последствия повторной обработки.

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

Спроектируйте обработку ошибок

Ошибка обмена не должна исчезать в техническом журнале, недоступном владельцу процесса. Нужно определить, кто получает сигнал, какие данные доступны для диагностики и как выполняется повтор.

Разберите как минимум:

• недоступность одной из систем;
• неверный формат;
• отсутствие обязательного справочного значения;
• конфликт изменений;
• потерю связи между объектами;
• частичное выполнение операции;
• повторную доставку одного сообщения;
• недостаток прав технической учётной записи.

В сообщениях не следует раскрывать лишние персональные или финансовые данные. Для поддержки достаточно идентификатора, типа операции, времени и понятного кода причины.

Подготовьте данные до запуска

Интеграция не исправляет автоматически дубли, устаревшие реквизиты и разные правила заполнения. До первой загрузки назначьте ответственных за очистку и утвердите критерии качества.

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

Составьте сценарии приёмки

Проверка должна охватывать не только успешную передачу.

• Создание новой записи.
• Обновление разрешённого поля.
• Повторная отправка того же события.
• Запись с неполными данными.
• Несуществующее справочное значение.
• Временная недоступность системы.
• Исправление ошибки и повтор.
• Запрет изменения в системе, которая не владеет полем.
• Проверка доступа и отсутствия лишних данных.
• Сверка результата с исходной записью.

Пакет для предварительной оценки

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

Страница решения «Интеграция с 1С» описывает общий подход. Связанные отраслевые задачи собраны для производства и оптовой торговли. Начать обследование можно с диагностики.