Интеграция CRM и интернет-магазина: статусы заказов в обе стороны

Редакция Romanov Lab · Опубликовано 13 октября 2026

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

Разделите независимые состояния

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

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

Составьте карту переходов, а не словарь названий

Соответствие «Новый» = «Новая сделка» полезно только для начала. Для каждого перехода запишите инициатора, условия, результат, отказ и обратное уведомление. Одно и то же слово «Отменён» может означать отказ покупателя, закрытие дубля или завершение возврата. Эти причины нельзя автоматически объединять.

Запрос отмены из CRM

Допустим до передачи в исполнение либо передаётся на разбор, если исполнение уже началось. Результат возвращается в CRM отдельным подтверждением.

Подтверждение отгрузки

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

Отметка оплаты

Устанавливается по проверенному платёжному результату. Комментарий менеджера «клиент оплатил» может запускать проверку, но не подменять её.

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

Свяжите идентификаторы и версии

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

В предлагаемом контракте изменение содержит идентификатор операции, объект, ожидаемую ревизию и желаемый переход. Получатель проверяет, что исходное состояние ещё актуально. Если API поддерживает условные запросы If-Match, их можно использовать для защиты от потерянного изменения. В другом API ищут документированный механизм версий; произвольное поле version без серверной проверки ничего не гарантирует.

Учебный конфликт: отмена пересеклась со сборкой

CRM показывает заказ K-90 в ревизии 6 как подтверждённый. Менеджер отправляет запрос отмены с ожиданием ревизии 6. Пока запрос идёт, склад начинает сборку, и основная система фиксирует ревизию 7. Без проверки версии отмена затрёт факт начала исполнения.

1. Получатель обнаруживает несовпадение ожидаемой и текущей ревизий.
2. Интеграция перечитывает актуальный заказ.
3. Правило процесса определяет, разрешена ли отмена после начала сборки.
4. Если требуется решение сотрудника, конфликт сохраняется и виден обеим сторонам.
5. Если отмена разрешена, выполняется новая согласованная операция с актуальными условиями.

Самое позднее время на часах одной системы не разрешает этот конфликт по смыслу. Выбор «последняя запись победила» подходит далеко не каждому полю и особенно опасен для переходов с реальными последствиями.

Уберите циклы обратной синхронизации

Магазин обновил CRM, CRM прислала событие изменения, магазин обновился снова. Так появляется эхо, которое иногда бесконечно запускает уведомления и пересчёты. Для собственных связующих компонентов полезны идентификатор исходной операции, источник изменения и сохранённая связь с отправленным результатом.

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

Частичная отгрузка и возврат требуют отдельных объектов

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

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

Найдите расхождения вне событийного потока

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

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

Критерии приёмки

• Каждый разрешённый переход проходит в обе стороны с понятным подтверждением.
• Запрещённый переход сохраняет исходные факты и объясняет отказ.
• Одновременная отмена и начало исполнения дают предусмотренный конфликт.
• Обратное событие собственного обновления не запускает бесконечное эхо.
• Частичная отгрузка не закрывает невыполненный остаток заказа.
• Повтор после потери ответа не создаёт вторую сущность или вторую операцию.
• Сверка обнаруживает пропущенное изменение и не запускает финансовые действия.

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