Задача и границы решения
CRM и учётная система часто используют разные понятия заказа, контрагента и оплаты. Прямое копирование полей без согласования процесса создаёт конфликты.
Как подойти к задаче
Назначьте владельца каждого атрибута и опишите идентификаторы связи. Согласуйте, где создаётся контрагент, кто меняет реквизиты и какое событие запускает передачу. Отдельно рассмотрите удаление и объединение записей.
Что проверить на практике
Пройдите цепочку от новой сделки до оплаты с повторной доставкой событий. Проверьте исправление реквизитов и частичную оплату. Итоговая сверка должна объяснять расхождения и показывать зависшие операции.
Какой ошибки избежать
Ошибка — включать двустороннее обновление всех полей. Это создаёт циклы и перезапись актуальных значений. Лучше явно ограниченный контракт и журнал изменений, чем обещание полной синхронизации без правил.
Пример для проверки на вашем проекте
Бухгалтер исправляет реквизиты в учёте, а менеджер почти одновременно редактирует компанию в CRM. Если обе стороны перезаписывают всё целиком, часть изменения потеряется. Для реквизитов можно назначить один источник, а для комментария менеджера — другой. Такое разделение фиксируется по полям. Исключения должны быть видны ответственному, а не разрешаться случайным порядком прихода запросов.
Контракт обмена
Для интеграции определяем события, поля, идентификаторы и направление передачи. Уточняем полномочия подключения и ограничения актуального API. Предусматриваем повторную доставку, журнал результата и ручной разбор исключений. Обмен должен оставаться понятным, когда одна система временно недоступна или ответ на запрос потерялся.
Что проверяем перед запуском
Набор сценариев включает успешную операцию, дубль события, отсутствие обязательного поля, отказ доступа и восстановление после паузы. Контроль выполняется на тестовых данных. Передачу реальных записей начинаем с ограниченного объёма и сверяем результат в обеих системах. Секреты подключения не включаются в инструкции и журналы.