Статусы заказов в Битрикс: частые ошибки новичков

Настройка статусов заказа в 1С-Битрикс занимает около 20–30 минут, если заранее определить этапы, права и уведомления. В конце у вас будет последовательная схема от нового заказа до завершения, а менеджеры не смогут случайно переводить заказы в неподходящие состояния.

Что подготовить до начала

Инструкция рассчитана на 1С-Битрикс: Управление сайтом 24.x. Названия пунктов могут немного отличаться в редакциях и после обновления административной панели.

• доступ администратора или сотрудника с правом изменять настройки магазина;
• список реальных этапов обработки: например, «Новый», «Подтверждён», «Передан в доставку», «Выполнен»;
• описание того, кто меняет каждый статус: оператор, склад, бухгалтер или служба доставки;
• резервная копия базы данных перед изменениями, если магазин уже работает.

Важно: статус заказа и статус оплаты — не одно и то же. Первый описывает этап обработки заказа, второй показывает состояние платежа. Не создавайте статус «Оплачен» только потому, что хотите отметить успешную оплату.

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

Шаг 1. Откройте список статусов

В административной панели перейдите в раздел магазина и найдите пункт, связанный со статусами заказов. В типовой установке это раздел «Настройки магазина» → «Статусы заказов». Откроется список стандартных и созданных вами статусов.

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

Проверка: вы видите таблицу статусов, их названия, сортировку и действия редактирования.

Шаг 2. Определите короткие идентификаторы

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

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

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

Шаг 3. Оставьте только рабочую последовательность

Создайте статусы в порядке, который повторяет реальный процесс. Например:

1. Новый — заказ поступил и ещё не проверен.
2. Подтверждён — менеджер связался с покупателем или проверил данные.
3. Комплектуется — склад собирает товар.
4. Передан в доставку — заказ покинул склад.
5. Выполнен — товар доставлен и обязательства магазина завершены.
6. Отменён — заказ прекращён до выполнения.

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

Проверка: новый сотрудник может пройти цепочку слева направо и понять, что делать на каждом этапе.

Шаг 4. Заполните свойства статуса

Откройте форму добавления или редактирования. Укажите название, идентификатор и сортировку. Если в форме есть описание, напишите короткое правило перехода: «Ставить после подтверждения состава заказа и способа доставки».

Для финальных состояний используйте отдельные статусы «Выполнен» и «Отменён». Не пытайтесь обозначить оба результата одним статусом «Закрыт»: отчёты и фильтры потеряют смысл, а менеджер не увидит, был заказ доставлен или прекращён.

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

Шаг 5. Настройте права на изменение

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

Названия и детализация прав зависят от версии и настроек проекта. Ориентируйтесь не на должность, а на действие: кто может установить статус, кто только видит его и кто имеет право вернуть заказ на предыдущий этап.

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

Шаг 6. Проверьте уведомления

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

Используйте тестовый заказ с адресом, к которому у вас есть доступ. Не проверяйте настройки на реальном заказе клиента: письмо может уйти покупателю, а изменение статуса попадёт в рабочую отчётность.

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

Шаг 7. Проведите полный тестовый заказ

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

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

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

Частые ошибки новичков

Дублирование стандартных статусов

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

Слишком подробная воронка

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

Один статус для оплаты и доставки

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

Изменение идентификатора после запуска

Название «Передан в доставку» можно сделать короче без изменения логики. Идентификатор — другое поле. Если его уже использует обмен с CRM, шаблон или обработчик, после смены интеграция может перестать узнавать статус.

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

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

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

Если статус не работает

• Статус не появляется в списке. Проверьте, сохранилась ли форма, заполнены ли обязательные поля и нет ли дубликата идентификатора.
• Статус есть, но его нельзя выбрать. Проверьте права группы пользователя и ограничения переходов в настройках магазина.
• Клиент не получил письмо. Проверьте почтовое событие, активность шаблона, адрес получателя и журнал отправки. Также убедитесь, что проблема не на стороне SMTP.
• Заказ сам переходит в другой статус. Ищите автоматизацию, обработчик, обмен с CRM, платёжную систему или настройку службы доставки. Ручное изменение статуса не всегда единственный источник перехода.
• В отчёте появились отдельные группы заказов. Проверьте, не созданы ли два статуса с одинаковым смыслом и не отличаются ли их внутренние идентификаторы.

Где подход ломается

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

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

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

Через неделю после запуска выгрузите список заказов по каждому статусу и найдите этапы, где заказы задерживаются дольше всего. Если статус не менялся несколько дней, это сигнал проверить инструкцию сотрудника, интеграцию или сам процесс, а не просто переименовать этап.

Затем зафиксируйте схему в коротком регламенте: кто меняет статус, при каком условии, какое уведомление получает клиент и что делать при ошибке. После обновления 1С-Битрикс повторите тестовый заказ: административные формы и связанные настройки могут измениться.

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