Обмен статусами заказов в обе стороны

Статус заказа — это состояние, которое видит и клиент на сайте, и менеджер в 1С. Чтобы они не расходились, обмен должен переносить изменение статуса в обе стороны: с сайта в 1С при оформлении и обратно, когда заказ собрали, оплатили или отгрузили.

Как статусы ходят между системами

В типовой связке 1С-Битрикс и 1С:Управление торговлей обмен заказами идёт по протоколу CommerceML через файл sale.xml. Сайт выгружает новые и изменённые заказы, 1С их забирает, обрабатывает и в ответном пакете возвращает те же документы с обновлёнными реквизитами — в том числе со статусом.

Важно понимать разделение ролей: сайт — источник факта оформления заказа, 1С — источник факта его исполнения. Поэтому статус в 1С-Битрикс (сущность STATUS_ID в таблице заказов) и статус документа «Заказ покупателя» в 1С — это два разных справочника, которые нужно связать правилом соответствия.

• Сайт → 1С: передаётся сам заказ, состав, покупатель, выбранный статус на момент выгрузки.
• 1С → сайт: возвращаются флаги оплаты и отгрузки, а также новый статус, если менеджер сменил его в учётной системе.

Два справочника статусов и зачем их сопоставлять

Статусы заказа на сайте настраиваются в разделе Магазин → Настройки → Статусы заказа. По умолчанию их два — N (принят, ожидает обработки) и F (выполнен), но обычно магазин добавляет промежуточные: «Комплектуется», «Готов к выдаче», «Передан в доставку».

В 1С у документа заказа свой набор статусов и признаков (например, «К обеспечению», «В работе», «Закрыт»). Между этими наборами нет автоматической логики — их значения не совпадают ни по коду, ни по смыслу. Поэтому первый шаг настройки двустороннего обмена статусами — это таблица соответствия.

Маппинг задаётся либо в правилах обмена на стороне 1С (регистр соответствия статусов), либо обработчиком события на стороне Битрикс — в зависимости от того, где вам удобнее держать логику.

Флаги оплаты и отгрузки как отдельный слой

Помимо статуса, в заказе есть два независимых булевых признака: оплачен (PAYED) и отгружен/разрешена доставка (DEDUCTED / ALLOW_DELIVERY). В CommerceML они приходят из 1С отдельными реквизитами документа, а не через справочник статусов.

Это удобно, потому что оплата и отгрузка меняются в 1С по факту проведения соответствующих документов: «Поступление на расчётный счёт» ставит признак оплаты, «Реализация товаров» — признак отгрузки. При приёме ответного sale.xml Битрикс проставляет эти флаги, а уже привязанные к ним статусы могут переключаться автоматически.

• Флаг PAYED = Y обычно триггерит смену статуса на «Оплачен» и запускает бизнес-процессы (уведомление клиента, резерв).
• Флаг DEDUCTED = Y списывает резерв и переводит заказ ближе к завершению.

Порядок выгрузки и кто «главный» по статусу

Двусторонний обмен статусами почти всегда рождает вопрос: чьё изменение победит, если статус поменяли и на сайте, и в 1С между сеансами обмена? Ответ зависит от настройки, но практическое правило простое: после запуска заказа в работу главной по статусу становится 1С.

Пока заказ новый, менеджер часто ещё не открыл его в 1С, и клиент может, например, отменить заказ на сайте — тогда сайт диктует статус. Как только заказ проведён в учётной системе, дальнейшие переходы («комплектуется», «отгружен») идут из 1С, а сайт их только принимает и отображает.

1. Сайт выгружает заказ и текущий статус в sale.xml.
2. 1С импортирует, менеджер обрабатывает заказ, меняет статус и признаки.
3. В ответном пакете 1С возвращает документ; Битрикс обновляет STATUS_ID, PAYED, DEDUCTED.
4. Клиент видит актуальное состояние в личном кабинете.

Настройки самого сеанса задаются в Магазин → Настройки → Настройки обмена с 1С, где включается обмен заказами и указывается, разрешено ли 1С менять статусы уже выгруженных заказов.

События и доработка логики переходов

Когда стандартного маппинга мало (например, нужно отправлять письмо только при определённом переходе или запрещать откат статуса назад), логику вешают на события модуля sale. Ключевое — OnSaleStatusOrderChange / OnSaleOrderSaved: они срабатывают, когда обмен применил статус из 1С к заказу.

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

• Фиксируйте, что изменение пришло именно из обмена, а не от менеджера в админке — по контексту вызова, чтобы не зациклить обратную выгрузку.
• Логируйте каждый переход: это спасает при разборе спорных заказов.

Диагностика рассинхрона статусов

Самая частая жалоба — «в 1С заказ отгружен, а на сайте всё ещё комплектуется». Проверять нужно последовательно, от файла обмена к настройкам маппинга.

• Дошёл ли пакет. Смотрите служебные файлы обмена и логи в /bitrix/managed_cache/ и журнал обмена — вернула ли 1С документ с новым статусом.
• Есть ли соответствие. Если статус из 1С не описан в таблице маппинга, Битрикс его проигнорирует — заказ «застынет».
• Права 1С на статус. Проверьте, что в настройках обмена разрешено изменение статусов ранее выгруженных заказов.
• Конфликт правил. Обработчик события может откатывать переход обратно — временно отключите кастомную логику и повторите обмен.

Полезно поднять подробный лог обмена и открыть сам sale.xml: если в XML статуса нет, проблема на стороне 1С; если есть, но на сайте не применился — проблема в маппинге или обработчиках Битрикс.

Итог

Двусторонний обмен статусами — это не одна галочка, а связка из трёх вещей: таблицы соответствия статусов сайта и 1С, штатных флагов оплаты и отгрузки и понятного правила, чья сторона главная на каждом этапе жизни заказа. Когда это настроено, клиент в личном кабинете и менеджер в учётной системе всегда видят одно и то же состояние, а спорных заказов почти не возникает.

Мы в B2Bsite настраиваем такой обмен под конкретный воркфлоу магазина: описываем маппинг, вешаем безопасные обработчики переходов, включаем логирование и мониторинг сеансов. Если статусы у вас уже расходятся или обмен заказами только предстоит запустить — поможем свести сайт и 1С в единую картину.