Настроить статусы заказов в Битрикс: что проверить заранее

Новый статус в Битрикс можно добавить за несколько минут, но ошибка в настройке способна остановить весь заказ: менеджер не увидит кнопку оплаты, письмо уйдёт раньше времени, а автоматическая отгрузка не запустится. Ниже — пошаговая настройка для «1С-Битрикс: Управление сайтом 24.x»: от проверки резервной копии до тестового заказа. На подготовку обычно достаточно 20–40 минут, если у вас есть доступ к административной панели.

Что нужно иметь до начала

Сначала соберите исходные данные. Не начинайте с добавления статуса в админке: сначала определите, какое событие он должен обозначать и какие действия разрешены на этом этапе.

• Доступ к административной части с правами на настройку интернет-магазина.
• Резервную копию базы данных и файлов сайта либо подтверждённую точку восстановления на хостинге.
• Список этапов заказа от создания до завершения: например, «Новый», «Подтверждён», «Оплачен», «Передан в доставку», «Выполнен».
• Описание переходов: кто меняет статус — менеджер, платёжная система, служба доставки или обработчик.
• Тестовый способ оплаты и тестовую доставку, если они подключены к магазину.
• План проверки писем, резервирования товара, отмены и возврата денег.

Проверьте версию продукта в административной панели и учитывайте установленные обновления модулей. Названия разделов и набор полей могут отличаться в редакциях и после обновления модуля «Интернет-магазин».

Сначала разделите статусы по смыслу

В Битрикс статус заказа описывает этап обработки, но не заменяет состояние оплаты, доставки или отгрузки. Если свести всё к одному списку «Оплачен — отправлен — возвращён», сотрудники начнут использовать статус как универсальный флаг, а интеграции будут получать противоречивые данные.

Статус заказа — значение, которое показывает этап обработки заказа и может использоваться правами доступа, уведомлениями и бизнес-логикой. Он не обязан автоматически означать, что заказ оплачен или отгружен.

Хороший статус отвечает на один вопрос: что сейчас должен сделать сотрудник или система.

Пошаговая настройка статуса

Шаг 1. Зафиксируйте схему переходов

Запишите статусы в порядке движения заказа и укажите допустимые переходы. Например, заказ может перейти из «Новый» в «Подтверждён», затем в «Оплачен» и «Передан в доставку». Отдельно определите, может ли менеджер вернуть его назад и кто отвечает за отмену.

Не создавайте статус для каждого внутреннего комментария. «Клиенту позвонили» или «Ждём ответ склада» чаще лучше хранить в комментарии, поле заказа или задаче, а не в основном жизненном цикле.

Проверка: для каждого статуса есть понятный следующий шаг и ответственный.

Шаг 2. Проверьте стандартные статусы

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

Не переименовывайте стандартный статус без проверки интеграций. Внешние модули и обработчики могут ориентироваться не на текст «Выполнен», а на идентификатор статуса.

Проверка: вы видите список текущих статусов и понимаете, какие из них используются на реальных заказах.

Шаг 3. Добавьте новый статус

Создайте статус через кнопку добавления. Заполните короткое название, понятное менеджеру, и подробное описание: когда ставить статус, кто это делает и какое действие следует дальше.

Символьный идентификатор выбирайте один раз и не меняйте после запуска. Используйте латинские символы в том виде, который разрешает ваша версия Битрикс. Если форма ограничивает длину или набор знаков, не обходите это ограничение — уточните правило в справке вашей версии.

Задайте порядок сортировки так, чтобы этапы шли в рабочей последовательности. Поле уведомления включайте только после проверки шаблонов писем: сам статус не гарантирует, что клиент получит корректное сообщение.

Проверка: новый статус отображается в списке, у него есть уникальный идентификатор, название и описание.

Шаг 4. Настройте права для групп пользователей

Определите, кто может видеть статус, устанавливать его и переводить заказ дальше. Менеджеру магазина обычно не нужны права администратора, а оператору кол-центра может быть нельзя вручную отмечать заказ как выполненный.

Проверьте права не только своей учётной записью. Откройте тестовый заказ под ролью менеджера и под ролью оператора. Так вы увидите, не появились ли лишние действия в карточке заказа.

Проверка: каждая роль видит только разрешённые действия, а кнопки перехода соответствуют регламенту.

Шаг 5. Свяжите статус с письмами и автоматизацией

Проверьте почтовые события, шаблоны, бизнес-процессы, роботов и обработчики, которые реагируют на изменение статуса. В одном проекте письмо может отправляться при смене статуса, в другом — при отдельном событии оплаты или отгрузки.

Особенно внимательно проверьте интеграции с платёжной системой, CRM, складом и доставкой. Если обработчик ожидает конкретный идентификатор, новое значение не начнёт работать автоматически только потому, что его название похоже на старое.

Проверка: тестовая смена статуса создаёт только те письма и действия, которые предусмотрены схемой.

Шаг 6. Проведите сквозной тест

Создайте тестовый заказ с реальным товаром, но безопасными контактными данными и тестовым способом оплаты. Пройдите весь маршрут: создание, изменение статуса, оплату, отмену, отгрузку и возврат, если эти сценарии используются.

Проверьте заказ с компьютера менеджера и в мобильной административной панели, если сотрудники работают с ней. После каждого перехода смотрите историю заказа, письма и изменения оплаты или отгрузки.

Проверка: заказ проходит маршрут без ручного исправления базы данных, повторных писем и расхождений между статусом, оплатой и отгрузкой.

Что часто ломается

Новый статус не появляется в форме заказа

Проверьте, сохранена ли запись, права пользователя и кэш административной части. Если отображается сообщение вроде «Доступ запрещён» или раздел не открывается, проблема, скорее всего, в правах группы, а не в самом статусе. Формулировка сообщения зависит от версии и настроек проекта.

Письмо клиенту не отправилось

Проверьте, действительно ли письмо привязано к изменению статуса, активен ли почтовый шаблон и настроена ли отправка почты с сайта. Отправьте тестовое письмо отдельно: так вы отделите проблему статуса от проблемы SMTP или очереди отправки.

Статус меняется обратно

Причиной часто бывает фоновый обмен, обработчик оплаты или интеграция с CRM. Сравните время изменения в истории заказа с журналом обмена и логами интеграции. Не исправляйте результат вручную, пока не найден источник повторного изменения.

Оплаченный заказ остаётся в старом статусе

Оплата и статус заказа могут обновляться разными событиями. Проверьте настройки платёжной системы и обработчик уведомления, а также убедитесь, что тестовый платёж действительно завершён, а не только создан.

После обновления исчезли переходы

Сверьте резервную копию, настройки прав и изменения модуля «Интернет-магазин». Если проект использует кастомный код, проверьте его на привязку к старым идентификаторам и названиям статусов. Обновление на рабочем сайте сначала стоит повторить на копии.

Где схема статусов ломается

Проблемы начинаются, когда статус используют как складской флаг, признак оплаты и команду для доставки одновременно. Один заказ может быть оплачен, но ещё не собран; отгрузка может быть создана, но курьер ещё не получил посылку. Для таких состояний нужны отдельные сущности и поля, а не длинная цепочка из десятков статусов.

Не удаляйте статус, который уже встречается в заказах. Сначала найдите связанные заказы, отчёты, шаблоны и обработчики. Безопаснее вывести статус из рабочего сценария или переименовать его после проверки, чем удалять запись и оставлять старые заказы без понятного состояния.

Что сделать после настройки

Оформите короткий регламент на одну страницу: значение каждого статуса, ответственный, допустимые переходы и действие при ошибке. Через несколько дней проверьте отчёт по заказам и историю изменений: ищите ручные возвраты статуса, заказы без оплаты на поздних этапах и повторные письма.

После этого перенесите настройку на рабочий сайт по принятой процедуре релиза и сохраните список идентификаторов статусов. Дальше мониторьте не только количество заказов, но и время между переходами, долю ручных исправлений и расхождения между оплатой, отгрузкой и статусом.