Проброс статусов — это обратный поток данных: заказ ушёл в CRM и склад, а назад на сайт возвращаются признаки оплаты, отгрузки и трек-номер. Разберём, как корректно замапить статусы и не рассинхронизировать заказ на витрине с учётом.
Зачем пробрасывать статусы обратно
Пока заказ живёт только в CRM или складе, покупатель в личном кабинете на сайте не видит, что происходит. Обратный проброс статусов закрывает этот разрыв: клиент видит «оплачен», «собран», «передан в доставку» и трек-номер без звонка менеджеру.
В 1С-Битрикс у заказа есть несколько независимых измерений состояния, и путать их нельзя:
- Статус заказа (
STATUS_ID) — этап обработки (N, P, F и пользовательские). - Оплата — флаг
PAYEDна объекте оплаты (Payment). - Отгрузка — флаг
DEDUCTEDи статус на объекте доставки (Shipment).
Маппинг статусов между системами
Статусы во внешней системе и на сайте почти никогда не совпадают один в один. Нужна таблица соответствия, которую согласуют с бизнесом.
| Статус во внешней системе | Действие на сайте |
|---|---|
| Оплачен | Payment.PAYED = Y |
| Собран / в сборке | STATUS_ID = «Комплектуется» |
| Отгружен | Shipment.DEDUCTED = Y, статус «Отгружен» |
| Передан в доставку | Записать трек-номер, статус «В пути» |
| Доставлен | STATUS_ID = F (выполнен) |
| Отменён | STATUS_ID = отменён, снять резерв |
Пользовательские статусы заводятся в админке: Магазин → Настройки → Статусы заказа. Их символьные коды и используются в маппинге. Хардкодить русские названия в обработчике нельзя — только коды.
Проброс статуса оплаты
Отметка оплаты приходит из двух источников: платёжной системы (напрямую или через CRM) и учётной системы, где оплату проводит бухгалтер. Важно определить мастера, чтобы флаг не мигал.
- Онлайн-оплата — мастер платёжная система, её колбэк ставит
PAYED = Y. - Оплата по счёту / наличными — мастер учётная система, флаг приходит из неё.
Программно оплата проставляется через объект заказа D7:
$payment->setPaid('Y'); $order->save();
Важно не только выставить флаг, но и корректно провести оплату, чтобы сработали связанные события (списание бонусов, отправка чека по 54-ФЗ, уведомления). Прямое обновление поля в БД в обход API оставит заказ в неконсистентном состоянии.
b_sale_order_payment запросом мимо API ломает бизнес-логику: не уходит чек, не пересчитываются суммы, не срабатывают обработчики.Проброс отгрузки и трек-номера
Отгрузка отмечается на объекте Shipment. При проведении отгрузки Битрикс списывает товар с резерва и уменьшает остаток (если включено управление складом), поэтому операция должна идти через API.
- Найти заказ по внешнему номеру (свойство заказа).
- Получить коллекцию отгрузок
$order->getShipmentCollection(). - Проставить
$shipment->setField('DEDUCTED', 'Y')и сохранить. - Записать трек-номер в свойство отгрузки или заказа (
TRACKING_NUMBER).
Трек-номер часто приходит отдельным событием позже отгрузки. Его пишут в TRACKING_NUMBER отгрузки — тогда покупатель видит ссылку на отслеживание в личном кабинете, а Битрикс может дёргать статус у службы доставки.
Идемпотентность и порядок статусов
Обратные статусы приходят вебхуками или опросом, и повторы неизбежны. Обработчик обязан быть идемпотентным и уважать порядок жизненного цикла заказа.
- Повтор. Если оплата уже проставлена, повторное событие не должно ломать заказ или слать чек второй раз.
- Обратный переход. Пришёл устаревший статус «в сборке» после «отгружен» — его нужно игнорировать, а не откатывать заказ назад.
- Неизвестный статус. Статуса нет в маппинге — логируем и не применяем, а не падаем.
Практичный приём — хранить в свойстве заказа метку последнего применённого статуса и его времени. Событие применяется, только если оно новее последнего обработанного.
Уведомления клиенту при смене статуса
Проброс статуса — хороший триггер для коммуникации. Но уведомления должны срабатывать только на реальную смену, а не на каждый повторный вебхук.
- Смена статуса заказа штатно шлёт письмо через почтовые события Битрикса (
SALE_STATUS_CHANGED_*). - Оплату и отгрузку можно связать с SMS или мессенджером через свои обработчики событий.
- Дедупликация: не слать уведомление, если статус не изменился фактически.
Чтобы не завалить клиента письмами при массовом обмене, уведомления ставят в очередь и отправляют пачкой либо с задержкой, отсекая промежуточные технические переходы.
Итог
Корректный проброс статусов оплаты и отгрузки строится на понимании модели заказа Битрикса (отдельные Payment и Shipment), на согласованном маппинге статусов по кодам, работе через API вместо прямых запросов в БД и на идемпотентных обработчиках, которые уважают порядок жизненного цикла заказа.
Мы в B2Bsite настраиваем двусторонний обмен заказами и обратные статусы для магазинов на 1С-Битрикс: маппим статусы под ваши процессы, аккуратно проводим оплату и отгрузку через API, подключаем трек-номера и уведомления. Если статусы на сайте отстают от реальности — синхронизируем их с учётом и CRM.
Частые вопросы
Чем статус заказа отличается от статуса оплаты в Битриксе?
Статус заказа (STATUS_ID) описывает этап обработки, а оплата и отгрузка — это отдельные сущности Payment и Shipment со своими флагами PAYED и DEDUCTED. Проброс должен работать со всеми тремя измерениями отдельно.
Можно ли проставить оплату прямым запросом в базу?
Нельзя. Обновление таблиц заказа в обход API ломает бизнес-логику: не уходит фискальный чек, не пересчитываются суммы, не срабатывают обработчики. Оплату проводят только через объект заказа D7.
Куда записывать трек-номер?
В поле TRACKING_NUMBER объекта отгрузки. Тогда покупатель видит ссылку на отслеживание в личном кабинете, а Битрикс может автоматически запрашивать статус у службы доставки.
Что делать с повторными вебхуками статусов?
Сделать обработчик идемпотентным: хранить метку последнего применённого статуса и времени, применять событие только если оно новее, и не повторять уведомления и отправку чека.
Как заказ на сайте находит свой обратный статус?
По внешнему идентификатору. В свойство заказа Битрикса записывают ID сделки CRM или номер во внешней системе, и обратные события прицеливаются именно по нему.
Кто мастер статуса оплаты — платёжка или учёт?
Зависит от способа оплаты. Для онлайн-оплаты мастер — платёжная система, её колбэк ставит флаг. Для оплаты по счёту или наличными — учётная система, откуда приходит подтверждение.
Как не задублировать уведомления клиенту?
Отправлять письмо или SMS только на фактическую смену статуса, а не на каждый повторный вебхук. Промежуточные технические переходы отсекают, уведомления ставят в очередь.
Поможем с настройкой и поддержкой Интеграции и связки систем
Поможем с настройкой, доработкой и поддержкой Интеграции и связки систем.