Синхронизация заказов связывает витрину на Битрикс и обработку в RetailCRM в один процесс. Новый заказ с сайта попадает в CRM, а изменения статуса, оплаты и состава возвращаются обратно. Ключ к чистому обмену — точное соответствие статусов и способов оплаты между двумя системами.
Как устроен обмен заказами
Модуль intaro.retailcrm обменивается заказами в двух направлениях. Новый заказ с сайта отправляется в CRM через обработчик события OnSaleOrderSaved практически сразу, а последующие изменения (смена статуса, оплата, правка позиций) синхронизируются механизмом истории изменений по расписанию.
RetailCRM ведёт собственную историю по каждому заказу, где помечает источник каждой правки. Модуль скачивает эту историю и применяет изменения на сайте, а изменения с сайта — отправляет в CRM. Так обе системы приходят к согласованному состоянию.
Передача новых заказов с сайта
Когда покупатель оформляет заказ на Битрикс, модуль собирает его в структуру RetailCRM: позиции, покупатель, доставка, оплата, комментарий. Чтобы заказ ушёл полностью, на сайте должны быть заполнены и сопоставлены:
- Свойства заказа — ФИО, телефон, email, адрес доставки привязаны к полям клиента и заказа CRM.
- Способ оплаты — платёжная система сайта сопоставлена с типом оплаты CRM.
- Способ доставки — служба доставки сайта сопоставлена со службой CRM.
- Товары — позиции найдены в каталоге CRM по внешнему ID (артикулу из ICML).
Соответствие статусов
Статусная модель у Битрикс и RetailCRM разная: в Битрикс это плоский список статусов заказа, в CRM — статусы, сгруппированные в группы (новый, согласование, комплектация, доставка, выполнен, отменён). Задача маппинга — связать их в обе стороны.
| Статус Битрикс | Статус RetailCRM | Группа CRM |
|---|---|---|
| Принят, ожидает оплаты | Новый | Новый |
| Оплачен | Согласован | Согласование |
| Передан в доставку | Передан в доставку | Доставка |
| Выполнен | Выполнен | Выполнен |
| Отменён | Отменён | Отменён |
Маппинг задаётся в настройках модуля отдельно для направления «сайт → CRM» и «CRM → сайт». Незамапленный статус — главная причина, по которой изменения не долетают.
Оплаты, доставка и признак оплаченности
Помимо статуса заказа синхронизируется факт оплаты. В Битрикс это флаг «оплачен» на платёжной системе, в RetailCRM — отдельная сущность оплаты с типом и статусом. Чтобы они совпадали:
- Сопоставьте каждую платёжную систему сайта с типом оплаты CRM.
- Настройте передачу признака оплаты, чтобы онлайн-оплата на сайте помечала заказ оплаченным в CRM.
- Сопоставьте службы доставки, чтобы стоимость и способ доставки не терялись.
Если у вас подключена онлайн-касса на сайте, следите, чтобы двойного пробития не возникало: договоритесь, какая система является источником фискализации. Обмен передаёт данные оплаты, но пробитие чека должно происходить в одном месте.
История изменений и расписание
Обратная синхронизация (из CRM на сайт) работает через выгрузку истории изменений. Её нужно запускать регулярно по cron:
*/5 * * * * php -f /home/site/public_html/bitrix/modules/intaro.retailcrm/cron/history.php
Скрипт забирает из RetailCRM список изменений с прошлого запуска и применяет их на сайте: меняет статусы, отмечает оплаты, обновляет состав. Частота 3–5 минут обеспечивает почти онлайн-синхронизацию статусов, при этом не создаёт заметной нагрузки.
| Скрипт | Что делает | Интервал |
|---|---|---|
| history.php | Синхронизация изменений заказов | 3–5 мин |
| icml.php | Генерация каталога | 15–60 мин |
Отладка расхождений
Когда заказ или статус не синхронизировался, диагностику ведут по шагам:
- Заказ не ушёл в CRM — проверьте логи модуля и права API-ключа; частая причина — незамапленный статус или пустое обязательное поле.
- Статус не вернулся на сайт — проверьте, что history.php запускается по cron и что статус CRM сопоставлен со статусом сайта в направлении «CRM → сайт».
- Оплата не отобразилась — проверьте соответствие типов оплаты и передачу признака оплаченности.
- Дубли заказов — обычно следствие повторной первичной выгрузки без контроля уже переданных заказов.
Итог
Синхронизация заказов Битрикс и RetailCRM работает предсказуемо, когда сделаны три вещи: сопоставлены статусы в обе стороны, увязаны типы оплаты и службы доставки и запущен history.php по cron для обратного обмена. Большинство «пропаж» статусов лежит именно в этих трёх точках.
Мы в B2Bsite настраиваем двусторонний обмен заказами под ключ: выстраиваем статусную модель, сопоставляем оплаты и доставки, запускаем обмен по расписанию и проверяем всю цепочку от оформления до отмены. Если статусы теряются или заказы дублируются — найдём причину и наладим синхронизацию.
Частые вопросы
В какую сторону идёт обмен заказами?
В обе. Новые заказы уходят с сайта в CRM, а изменения статусов, оплат и состава возвращаются из CRM на сайт через выгрузку истории изменений.
Почему статус из CRM не появляется на сайте?
Две частые причины: не запущен по cron скрипт history.php или статус CRM не сопоставлен со статусом сайта в направлении CRM → сайт.
Где менеджерам менять статусы — на сайте или в CRM?
Как правило, в RetailCRM: там группы статусов, триггеры и задачи. На сайт возвращаются укрупнённые статусы для покупателя.
Что будет, если товара из заказа нет в каталоге CRM?
Позиция передастся как товар вне каталога. Заказ пройдёт, но пострадают аналитика и остатки, поэтому сначала настраивают выгрузку ICML.
Как передаётся факт оплаты?
Через сопоставление платёжных систем сайта с типами оплаты CRM и передачу признака оплаченности. Онлайн-оплата на сайте помечает заказ оплаченным в CRM.
Как избежать двойного пробития чека?
Определите единственный источник фискализации. Обмен передаёт данные оплаты, но пробитие чека должно происходить только в одной системе.
Откуда берутся дубли заказов?
Обычно из повторной первичной выгрузки без контроля уже переданных заказов. Первичный перенос делают аккуратно, по плану и на тестовых данных.
Поможем с настройкой и поддержкой RetailCRM
Поможем с настройкой, доработкой и поддержкой RetailCRM.