Синхронизация заказов — сердце интеграции сайта с RetailCRM: новые заявки уходят в CRM, а изменения статусов, оплаты и доставки возвращаются на сайт. Разберём, как настроить обмен так, чтобы не было потерянных заказов и дублей.
Направления обмена заказами
Обмен заказами двусторонний, и важно понимать, какая система «главная» по каждому полю. Обычно сайт — источник новых заказов, а RetailCRM — центр их обработки.
- Сайт → CRM: создание нового заказа с составом, покупателем, оплатой и доставкой;
- CRM → сайт: смена статуса, факт оплаты, трек-номер, изменения состава оператором;
- Двусторонне: комментарии, контактные данные покупателя.
Создание заказа на стороне CRM
Новый заказ передаётся в RetailCRM методом API orders/create. В теле запроса — номер, состав, суммы, способ оплаты и доставки, данные покупателя. Ответ содержит внутренний id заказа в CRM, который сайт сохраняет для дальнейших обновлений.
- Покупатель оформляет заказ на сайте;
- Модуль или скрипт формирует запрос и вызывает
orders/create; - RetailCRM возвращает id заказа;
- Сайт запоминает связку своего номера и id CRM.
Каждой позиции важно проставить offer.externalId или артикул, совпадающий с ICML-выгрузкой, — иначе товар не свяжется со справочником.
Дедупликация клиентов
Вместе с заказом создаётся или обновляется карточка покупателя. RetailCRM ищет клиента по телефону и e-mail и, если находит, привязывает заказ к существующему контакту. Это защищает от размножения дублей.
| Ситуация | Поведение RetailCRM |
|---|---|
| Клиент найден по телефону | заказ привязан к карточке |
| Новый телефон и e-mail | создаётся новая карточка |
| Совпал только e-mail | по правилам объединения — привязка или дубль |
Правила объединения настраиваются в CRM. Чтобы дедупликация работала, сайт должен передавать телефон в едином формате (например, +7XXXXXXXXXX).
Возврат статусов и оплаты на сайт
Обратное направление настраивается через сопоставление статусов и, как правило, вебхуки RetailCRM. При смене статуса CRM уведомляет сайт, и тот обновляет заказ в личном кабинете покупателя.
- Статусы сайта и CRM сопоставляются один к одному в настройках интеграции;
- Факт оплаты передаётся отдельным флагом, а не статусом;
- Трек-номер и стоимость доставки возвращаются, если подключена интеграция со службой доставки.
Вебхуки и обмен по расписанию
Есть два механизма доставки изменений из CRM на сайт: вебхуки (мгновенно) и периодический опрос по API (по расписанию).
| Механизм | Плюсы | Минусы |
|---|---|---|
| Вебхуки | мгновенно, без лишних запросов | нужен публичный HTTPS-адрес |
| Опрос по cron | работает без входящих запросов | задержка и нагрузка на API |
Для большинства магазинов оптимальны вебхуки на события заказа, а опрос оставляют как страховку на случай пропущенного уведомления.
Отладка и защита от потерь
Надёжная синхронизация — это не только настройка, но и контроль. Ведите журнал обмена и предусмотрите повтор при сбоях.
- Заказ не ушёл в CRM — сохраните его в очередь и повторите отправку, а не теряйте при первой ошибке API;
- Дубли заказов — ищите заказ по
externalIdи делайтеorders/editвместо повторного создания; - Статус не вернулся — проверьте регистрацию вебхука и обратный маппинг;
- Расхождение сумм — сверьте, как передаются скидки и стоимость доставки.
Итог
Стабильная синхронизация заказов держится на четырёх опорах: чёткое разделение «владельцев» полей, надёжная отправка в orders/create с повторами, дедупликация клиентов по телефону и корректный обратный маппинг статусов через вебхуки. Отдельное внимание — статусам отмены и защите от дублей по externalId.
Мы настраиваем двусторонний обмен заказами под конкретную связку сайта и RetailCRM, выстраиваем маппинг и очереди повторов, а затем сопровождаем интеграцию, чтобы заказы не терялись.
Частые вопросы
Что делать, если заказ не ушёл в RetailCRM из-за ошибки API?
Заказ нужно ставить в очередь и повторять отправку, а не терять при первом сбое. Надёжные интеграции хранят неотправленные заказы и досылают их автоматически.
Как избежать дублей заказов в CRM?
Сохраняйте связку номера сайта и id CRM, ищите заказ по externalId и обновляйте его методом orders/edit вместо повторного создания.
Почему клиенты множатся дублями?
Обычно телефон приходит в разном формате. Приведите его к единому виду перед отправкой и настройте правила объединения контактов в RetailCRM.
Как передать на сайт факт оплаты?
Оплата в RetailCRM — это отдельный флаг платежа, а не статус. Его нужно возвращать отдельно от статуса заказа, иначе логика оплаты на сайте сломается.
Вебхуки или опрос по расписанию — что выбрать?
Для большинства магазинов лучше вебхуки: изменения приходят мгновенно. Опрос по cron оставляют как страховку на случай пропущенного уведомления.
Почему отменённый в CRM заказ снова активен на сайте?
Не настроено соответствие статуса отмены. Сопоставьте «Отменён» в обе стороны, иначе заказ вернётся на сайт как действующий.
Как ловить расхождения между сайтом и CRM?
Настройте ежедневную сверку: скрипт сравнивает заказы за период в двух системах и подсвечивает несовпадения по сумме, статусу и составу.
Поможем с настройкой и поддержкой RetailCRM
Поможем с настройкой, доработкой и поддержкой RetailCRM.