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

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

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

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

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

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

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

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

Определите, где создают и изменяют каждую запись

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

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

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

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

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

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

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

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

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

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

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

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

Опишите:

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

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

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

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

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

Для каждого сценария опишите событие запуска и результат. Например: после согласования заявка передаётся в 1С, подтверждение оплаты возвращается в CRM, а исправленные реквизиты приходят только из системы, где разрешено их менять.

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

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

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

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

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

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

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

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

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

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

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

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

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

Заполненный пример карты обмена

Рассмотрим пример: менеджер ведёт продажу в CRM, а учётные документы оформляются в 1С. Таблица помогает согласовать направление обмена. Возможность реализовать каждое правило проверяют для выбранного способа интеграции.

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

Приёмка обмена: контрольная партия из шести записей

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

Затем в согласованной тестовой среде проверьте, что будет при недоступности второй системы и повторной отправке. Корректные записи должны дойти без дублей, ошибочные — остаться в журнале для исправления. Сотрудник должен знать, кому передать сообщение об ошибке.

Ограничения коннекторов: проверять до обещания цены

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

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

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