Статусы заказа Битрикс из коробки закрывают базовый цикл: заказ принят, оплачен, отправлен, выполнен, отменён. На практике этого хватает на первую неделю после запуска магазина, а дальше владелец просит завести отдельный статус для брони товара, для передачи заказа в СДЭК или для сверки с бухгалтерией. Дальше расскажу, как я добавляю свои статусы заказов в 1С-Битрикс, настраиваю переходы между ними, привязываю почтовые уведомления и делаю так, чтобы статус менялся сам при поступлении оплаты через эквайринг или при передаче посылки в доставку.
Какие статусы заказа есть в Битриксе по умолчанию
Список статусов лежит в административном разделе, в настройках интернет-магазина, рядом со способами оплаты и доставки. В типовой поставке там уже настроено пять-семь статусов: заказ принят, принимается, оплачен, выполняется, отгружен, выполнен, отменён - формулировки немного отличаются от версии к версии, но логика одна: путь заказа от создания до закрытия.
Для витрины с десятком заказов в месяц этого достаточно. Как только подключается склад, курьерская служба и бухгалтерия, стандартного набора не хватает: непонятно, на каком этапе заказ завис у сборщика, кто отвечает за возврат, и почему в отчёте по выручке «висят» заказы без оплаты. Здесь и заводятся свои статусы.
Создание своих статусов заказа: пошаговая настройка
Добавляю новый статус прямо в административном разделе, без правки кода - Битрикс даёт для этого обычную форму:
- Захожу в настройки статусов заказа и нажимаю «Добавить статус».
- Указываю символьный код - латиницей, коротко и с намёком на смысл: например, CDEK_TRANSIT для «Передан в СДЭК» или WAIT_STOCK для «Ждём поступления». Этот код потом ловлю в обработчике события, когда настраиваю автоматику.
- Пишу название для каждого языка сайта, если магазин мультиязычный - иначе в личном кабинете покупателя вылезет пустое поле.
- Задаю сортировку - от неё зависит порядок статуса в общем списке и в воронке заказов.
- Отмечаю, относится ли статус к группе «оплачен» или «отменён» - от этой отметки зависят цифры в отчётах по продажам, а не только подпись в интерфейсе.
- Сохраняю и сразу иду настраивать переходы, иначе новый статус просто не появится в списке доступных при смене состояния заказа.
На одном проекте с несколькими складами я заводил статусы не по этапам доставки, а по ответственному отделу: «На сборке», «Ждёт курьера», «В пути», «Проблема с адресом». Менеджерам стало проще фильтровать заказы по своей зоне ответственности, чем разбираться в общей воронке.
Переходы между статусами и права менеджеров
У каждого статуса в Битриксе есть список разрешённых переходов - в какие статусы заказ может попасть дальше. Если не ограничить эту матрицу, менеджер одним кликом переведёт заказ из «Отменён» сразу в «Выполнен», и в отчёте по выручке появится заказ, которого фактически не было.
Обычно я собираю переходы в такую схему:
| Текущий статус | Разрешённый переход | Кто меняет |
|---|---|---|
| Принят | Оплачен, Отменён | Менеджер, автоматика оплаты |
| Оплачен | На сборке, Отменён (с комментарием) | Менеджер |
| На сборке | Передан в доставку | Кладовщик |
| Передан в доставку | Выполнен, Проблема с адресом | Автоматика СДЭК, курьер |
Права на смену статуса привязываю к группам пользователей отдельно от прав на просмотр заказов: кладовщику незачем видеть суммы и телефоны клиентов, но менять статус на «Собран» он должен уметь.
Автоматические уведомления по email при смене статуса заказа
Почтовые уведомления в Битриксе не пишутся отдельным кодом под каждый статус - они собираются в разделе «Оповещения о заказах», где для условия выбирается «Статус заказа» и нужное значение, а дальше подставляется шаблон письма из визуального редактора.
На практике завожу отдельный шаблон под каждый значимый статус, а не один универсальный на все случаи:
- «Заказ принят» - клиенту, с составом заказа и номером.
- «Оплачен» - клиенту с чеком или ссылкой на закрывающие документы, если магазин работает с юрлицами.
- «Передан в доставку» - клиенту с трек-номером СДЭК и ссылкой на отслеживание.
- «Проблема с адресом» - менеджеру, а не клиенту, чтобы он сам связался и уточнил детали.
Перед запуском проверяю каждый шаблон тестовой отправкой на реальном заказе. Типовая ошибка при настройке в том, что шаблон подставляют один раз и не проверяют на статусах, для которых в письме нет нужных полей, например трек-номера, если доставка ещё не передана курьеру.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Уведомления в Telegram и вебхуки при смене статуса
Email закрывает часть сценариев, но менеджеры быстрее реагируют на сообщение в Telegram, чем на письмо, которое открывают раз в час. Готового модуля «уведомление в Telegram при смене статуса» в типовой поставке нет, поэтому я вешаю обработчик на событие смены статуса заказа и отправляю запрос во внешний сервис.
Схема, которую я обычно собираю:
- Обработчик события в Битриксе при смене статуса заказа формирует короткое сообщение с номером заказа, старым и новым статусом и суммой.
- Запрос уходит на вебхук в n8n - туда же, где уже настроена настройка автоматизации уведомлений в n8n для других процессов на проекте.
- Внутри сценария n8n логика разбирает статус и решает, куда слать: в общий чат менеджеров, персонально ответственному сотруднику или в отдельный бот на aiogram, если у клиента есть личный кабинет в Telegram.
Если под задачу уже есть Telegram-бот на aiogram, можно обойтись без n8n и слать запрос прямо из обработчика события в Bot API - но тогда вся логика фильтрации и маршрутизации остаётся в коде на стороне Битрикса, и её сложнее менять без разработчика. n8n в этом смысле удобнее: часть логики правится в визуальном сценарии без деплоя.
Отдельно слежу, чтобы в теле запроса не улетали лишние персональные данные клиента - только то, что реально нужно для уведомления, и хранение переписки идёт на серверах в России, а не в стороннем облачном сервисе.
Автоматическая смена статуса при оплате и при передаче в доставку
Самая частая автоматика - смена статуса без участия менеджера, по сигналу от внешней системы.
При оплате интегрирую эквайринг, например T‑Bank, через приём вебхука об успешном платеже. Как только банк подтверждает оплату, обработчик меняет статус заказа на «Оплачен» и запускает связанное с этим статусом письмо клиенту. Для сравнения, в WooCommerce похожая логика собирается через хуки перехода статуса заказа в коде темы или плагина, а в Битриксе для базового сценария хватает интерфейса «Оповещения», код нужен только для нестандартной логики вроде частичной оплаты.
При передаче в доставку СДЭК отдаёт статус посылки и трек-номер через свой API. Забираю это по расписанию агентом Битрикса, фоновой задачей по крону, и обновляю статус заказа на «Передан в доставку», а при получении отметки о вручении - на «Выполнен». Это снимает с менеджера рутину открывать личный кабинет СДЭК и вручную сверять посылки с заказами.
Здесь же обычно всплывает вопрос отчётности: если статус «Оплачен» не привязан к нужной группе, как описано в разделе про создание статусов, заказ не попадёт в отчёт по выручке, даже если деньги реально пришли. Это чаще всего забывают при первой настройке.
Частые ошибки при настройке статусов заказа
- Слишком много статусов «про запас» - когда их больше пятнадцати, менеджеры путаются и переводят заказы наугад.
- Статус не привязан к группе «оплачен» или «отменён», из-за чего отчёты по продажам расходятся с реальностью.
- Матрица переходов не ограничена, и заказ можно вернуть из финального статуса в любой другой одним кликом.
- Уведомление настроено на статус, но не протестировано на заказе без нужных полей - трек-номера или суммы возврата, письмо уходит с пустыми полями или вовсе не отправляется.
- Обработчик на смену статуса не защищён от повторных вызовов - если Битрикс или внешняя система один раз отправит запрос дважды, клиент получит два одинаковых уведомления подряд.
Если нужно завести статусы, переходы и уведомления с нуля на уже работающем магазине, обычно это укладывается в разовую доработку, а дальше - в постоянную техподдержку (от 15 000 ₽/мес), если правила приходится подстраивать по ходу сезона.
1С-Битрикс регулярно обновляется, поэтому перед внедрением я сверяюсь с актуальной документацией.
Частые вопросы
Сколько статусов заказа стоит заводить в Битриксе?
На практике комфортный предел - от восьми до двенадцати статусов на магазин среднего размера. Больше пятнадцати обычно сигнал, что часть статусов дублирует друг друга или их правильнее развести по ответственным отделам, а не плодить в одном списке.
Можно ли переименовать стандартные статусы вместо того, чтобы создавать новые?
Технически да, у стандартных статусов можно поменять название и цвет в том же интерфейсе. Я так не делаю: символьный код у типового статуса завязан на логику ядра и других модулей, и если поменять только подпись, через полгода никто не вспомнит, что скрывается за формулировкой. Проще завести новый статус со своим кодом и понятным названием, а старый оставить как есть или скрыть из списка активных.
Как узнать символьный код статуса, чтобы использовать его в обработчике события?
Код статуса виден прямо в форме редактирования статуса в административном разделе, в поле рядом с названием. Для собственных статусов я задаю его сам при создании, для типовых - смотрю в том же списке настроек, а не в документации, потому что в разных редакциях и версиях набор стандартных кодов может отличаться.
Что делать, если уведомление о смене статуса не приходит клиенту?
Сначала проверяю, привязано ли вообще оповещение к нужному статусу и не ушло ли письмо в спам - это самая частая причина. Дальше смотрю лог отправленных писем в административном разделе: если письмо там есть, но не дошло, вопрос к почтовому сервису или к spf/dkim настройкам домена. Если письма в логе нет вообще, значит оповещение либо выключено, либо условие по статусу настроено неверно.