Двустороннюю синхронизацию нужно проектировать на уровне отдельных полей, а не выбирать одну «главную систему» для всей карточки. Финансовые реквизиты могут принадлежать учётной системе, контактные предпочтения — CRM. Для полей, доступных к изменению с обеих сторон, заранее устанавливают правила конфликтов и порядок ручного решения.
Опишите владельца каждого значения
Составьте таблицу: объект, поле, источник истины, направление передачи, разрешённые действия и ответственный. Для названия компании, адреса доставки и юридического адреса правила могут различаться. Одинаковое название поля в двух системах не гарантирует одинаковый смысл.
Различайте пустое значение, отсутствие поля в сообщении и явную команду очистить. Иначе неполная выгрузка может стереть корректные реквизиты. Правило преобразования справочников тоже относится к договорённости: неизвестный код следует отправить на проверку, а не незаметно заменить ближайшим вариантом.
Выберите правило для одновременных изменений
Простой принцип «побеждает последнее изменение» допустим только при понимании его последствий. Время на серверах может различаться, доставка бывает отложенной, а свежая правка не обязательно правильная. По возможности используют версии объекта и проверку ожидаемой предыдущей версии.
Для критичных полей полезнее отклонить конфликтующее обновление и показать обе версии человеку. Для менее значимых полей можно согласовать приоритет системы. Решение должно следовать бизнес-смыслу: автоматическое перетирание условий оплаты имеет другую цену ошибки, чем изменение внутреннего комментария.
Не допускайте бесконечного эха
Изменение из CRM приходит в учётную систему, которая отправляет уведомление обратно. Без признака происхождения обе стороны могут бесконечно переотправлять одну правку. Для защиты используют идентификатор операции, источник изменения и проверку фактического различия значений.
Одного поля «изменено интеграцией» обычно недостаточно для сложной цепочки. Нужно проследить конкретную операцию и её версию. Если принимающая система нормализовала значение, правило нормализации согласуют заранее, иначе разные форматы будут постоянно считаться новыми изменениями.
Условный пример с адресами
Предположим, менеджер исправил адрес доставки заказа в CRM, а бухгалтер одновременно обновил юридический адрес компании в учётной системе. Эти изменения не конфликтуют: поля имеют разные смыслы и разных владельцев. Объединение их в одно поле «адрес» создало бы искусственную проблему.
Другой случай: два сотрудника изменили один адрес доставки. Интеграция видит две версии после общего исходного состояния и останавливает автоматическую запись. Ответственный сверяет подтверждение клиента, выбирает актуальный вариант и фиксирует причину. Следующая доставка использует уже согласованную версию, сохраняя историю обеих попыток.
Учитывайте удаления и закрытые объекты
Удаление карточки не должно автоматически означать удаление во всех связанных системах. Объект мог попасть в архив, сменить подразделение или стать недоступным из-за прав. Согласуйте отдельные состояния деактивации и правила восстановления связей.
Для закрытых периодов или завершённых заказов допустимые изменения часто уже, чем для активной сделки. Это проектируемое бизнес-ограничение нужно проверять отдельно от технической возможности API записать поле. Базовые вопросы обмена перечислены в статье об интеграции CRM и 1С.
Проверка на конфликтных сценариях
До запуска воспроизведите одновременную правку, запоздалое сообщение, очистку поля, смену версии справочника и повтор уже обработанного события. Зафиксируйте ожидаемую итоговую карточку для каждой комбинации.
Приёмка успешна, когда правила дают предсказуемый результат, конфликт сохраняет обе исходные версии, а повтор не запускает новый круг изменений. Если сотрудник способен понять, откуда взялось значение и кто разрешил спорную правку, двусторонний обмен остаётся управляемым и после запуска.
Применить в вашей компании
Обсудим вашу задачу?
Поможем разобраться с процессом, данными и настройками. Работаем удалённо с компаниями по всей России.