Статусы заказов в Битрикс: настройка на живом примере

В интернет-магазине на 1С-Битрикс заказ часто проходит больше этапов, чем «новый» и «выполнен». Если смешать оплату, сборку и доставку в один список статусов, менеджеры начнут менять их вручную, отчёты потеряют смысл, а автоматические письма будут уходить не в тот момент. Ниже разберём на живом сценарии магазина электроники: заказ создаётся на сайте, оператор проверяет наличие, склад собирает товар, служба доставки получает отправление, а клиент забирает покупку. Пример рассчитан на интерфейс «1С-Битрикс: Управление сайтом» редакций 24.x–25.x; названия пунктов могут немного отличаться в зависимости от обновления и настроек модуля Интернет-магазин.

Сценарий: пять этапов вместо одного «в работе»

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

Для этого вводим такие статусы:

• Новый — заказ создан, но его ещё не проверил оператор.
• Проверка — оператор подтвердил состав заказа, наличие и контактные данные.
• Сборка — заказ передан на склад.
• Передан в доставку — отправление собрано и передано курьеру или транспортной компании.
• Выполнен — покупатель получил товар, а заказ закрыт.
• Отменён — заказ не будет исполнен: клиент отказался, товар недоступен или оплату не удалось подтвердить.

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

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

Статус заказа^[1] — значение, которое показывает этап обработки заказа в модуле Интернет-магазин. Это не то же самое, что статус оплаты, доставки или отгрузки.

Какие статусы выбрать и как не усложнить схему

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

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

Настройка в административной части

1. Проверьте текущую схему

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

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

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

2. Создайте статусы по процессу

Добавьте недостающие статусы и задайте короткие названия: «Проверка», «Сборка», «Передан в доставку». Не используйте в названии внутренние сокращения вроде «ОП», «РЦ-2» или «ВПР»: клиент может увидеть название в письме, а новый сотрудник не поймёт его без расшифровки.

Для каждого статуса проверьте язык, сортировку и доступность в текущем сайте. Если сайт многоязычный, заполните подписи для нужных языков, иначе часть интерфейса может показывать пустое или техническое значение.

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

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

3. Настройте права переходов

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

Конкретные права зависят от групп пользователей и установленной конфигурации Битрикс. Проверьте их в настройках групп и в параметрах самого модуля, не ограничиваясь тем, что сотрудник видит кнопку изменения статуса. Видимость заказа, доступ к заказам и право менять статус могут настраиваться раздельно.

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

4. Привяжите письма к переходам

Для клиента полезны не все внутренние этапы. После создания заказа можно отправить подтверждение, после передачи в доставку — сообщение с информацией об отправлении, после выполнения — уведомление о закрытии. Письмо о статусе «Проверка» нужно только тогда, когда клиент действительно должен что-то сделать или ждать дополнительного звонка.

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

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

Два способа организовать переходы

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

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

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

Что ломается чаще всего

• Статус означает сразу несколько вещей. «Оплачен и собран» неудобен для фильтров и писем. Разделите этап заказа и состояние оплаты.
• Статус меняют до фактического события. Переход в «Передан в доставку» должен происходить после реальной передачи, а не после печати накладной.
• Удаляют старый статус сразу. Сначала проверьте исторические заказы, письма и обмены. Для старых заказов безопаснее оставить статус или подготовить контролируемое преобразование данных.
• Автоматизация зацикливает переходы. Обновление заказа может снова вызвать обработчик, который повторяет то же действие. Для такого сценария нужны тестовый контур, журнал событий и ограничение повторной обработки.
• Клиент получает внутренние названия. Проверьте шаблоны писем и страницу личного кабинета под тестовым пользователем, а не только административный интерфейс.

Где такая схема перестаёт работать

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

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

Что делать дальше

После настройки возьмите 20–30 последних заказов и вручную пройдите весь маршрут в тестовой копии или на тестовом заказе. Проверьте права, письма, фильтры, отображение в личном кабинете и передачу данных во внешние системы. Затем неделю измеряйте две вещи: сколько заказов находится в каждом статусе и сколько времени заказ проводит между переходами. Если заказы скапливаются на одном этапе, менять нужно не название статуса, а процесс, который за ним стоит.

^[1] В интерфейсе Битрикс рядом могут использоваться статусы заказа, статусы оплаты, доставки и отгрузки. Перед настройкой уточните, к какой именно сущности относится поле, которое вы меняете.