Заказ, который из «доставлен» вдруг вернулся в «новый». Клиент, получивший письмо об отправке дважды. Оплаченный заказ, который менеджер случайно перевёл в «ожидает оплаты», запустив ненужное напоминание. Всё это симптомы одной болезни: статусами заказа никто не управляет системно. Их можно менять как угодно и откуда угодно, и рано или поздно бардак выливается в деньги и нервы.
Лекарство известно давно и называется конечный автомат состояний. В этой статье разберём, как применить его к заказу интернет-магазина на 1С-Битрикс: спроектировать жизненный цикл, описать допустимые переходы, поставить обработчики событий стражем правил, согласовать модель с обменом 1С и завести историю статусов. Практику наведения такого порядка мы закрываем услугой автоматизации продаж и склада на 1С.
Коротко
- Бардак со статусами — это следствие отсутствия правил переходов, а не «человеческого фактора».
- Конечный автомат описывает разрешённые переходы и запрещает всё остальное явными правилами.
- Страж переходов в 1С-Битрикс — обработчики событий модуля продаж; там же живут побочные эффекты.
- Модель статусов согласуют с обменом 1С и подкрепляют историей переходов с источником изменения.
Почему статусы заказа выходят из-под контроля
В живом магазине статус заказа меняют многие: клиент в личном кабинете, менеджер в админке, платёжный шлюз колбэком, обмен с 1С, фоновые скрипты и агенты. Пока список статусов есть, а правил переходов нет, каждый из этих источников может выставить любой статус в любой момент.
Дальше включается энтропия. Один переводит заказ назад по воронке, другой выставляет флаг оплаты вручную, третий шлёт уведомление на статус, который уже был. Отдельные действия выглядят безобидно, но вместе дают несогласованное состояние: заказ формально «отгружен», но не оплачен; клиенту ушло три письма; в 1С один статус, на сайте другой. Корень проблемы не в людях, а в отсутствии формальных правил.
Что такое конечный автомат состояний
Конечный автомат состояний (state machine) — простая и мощная модель. У сущности есть конечный набор состояний, в каждый момент она находится ровно в одном, а переходы между состояниями разрешены только по заранее описанным правилам.
Для заказа это значит: есть список статусов и таблица допустимых переходов. Из «нового» можно в «подтверждён» или «отменён». Из «подтверждён» — в «в сборке» или «отменён». Но нельзя из «нового» сразу в «доставлен», и нельзя из «доставлен» вернуться в «новый». Всё, что не разрешено явно, — запрещено. Эта дисциплина превращает хаотичное множество статусов в предсказуемый жизненный цикл.
Как статусы устроены в 1С-Битрикс
В 1С-Битрикс жизненный цикл заказа складывается из нескольких измерений. Есть пользовательские статусы заказа, настраиваемые в модуле «Интернет-магазин». Есть флаги оплаты (заказ оплачен или нет) и отгрузки (собран, отгружен). В новой модели заказа оплата и доставка вынесены в отдельные сущности — Payment и Shipment — со своими состояниями.
Штатно платформа хранит статусы и позволяет их менять, но не навязывает правил переходов: почти из любого статуса заказ можно перевести в любой. То есть механизм состояний есть, а конечного автомата поверх него — нет. Наша задача — добавить эту дисциплину, не ломая штатную логику продаж. Про современную работу с сущностями заказа через ORM полезно прочитать в статье про D7 ORM в 1С-Битрикс.
Проектируем жизненный цикл заказа
Перед кодом — схема. Соберите реальные статусы вашего процесса и договоритесь, что каждый из них значит. Типовой каркас:
- Новый. Заказ оформлен, ждёт обработки.
- Подтверждён. Менеджер или система проверили заказ и наличие.
- Ожидает оплаты / оплачен. Состояние платежа для предоплатных схем.
- В сборке / отгружен. Состояние отгрузки на складе.
- Доставлен / завершён. Заказ выполнен.
- Отменён / возврат. Терминальные ветки для несостоявшихся заказов.
Важно отделить измерения: статус выполнения, состояние оплаты и состояние отгрузки часто живут параллельно. Не пытайтесь впихнуть всё в один линейный список статусов — получите комбинаторный взрыв. Лучше несколько небольших автоматов (выполнение, оплата, отгрузка), согласованных между собой.
Матрица допустимых переходов
Сердце модели — таблица переходов. Она отвечает на вопрос: из какого статуса в какой можно перейти. Пример для статуса выполнения:
| Из статуса | Допустимые переходы |
|---|---|
| Новый | Подтверждён, Отменён |
| Подтверждён | В сборке, Отменён |
| В сборке | Отгружен, Отменён |
| Отгружен | Доставлен, Возврат |
| Доставлен | Завершён, Возврат |
| Завершён / Отменён | — (терминальные) |
Эту матрицу выносят в конфигурацию, а не хардкодят по коду: список переходов задан в одном месте, и его легко читать, менять и проверять. Хранить матрицу можно в настройках модуля, отдельном highload-блоке или конфигурационном массиве — важно, что она одна и является единственным источником правды о переходах.
Обработчики событий как страж переходов
Матрица бесполезна, если её никто не проверяет. В 1С-Битрикс страж переходов — обработчики событий модуля продаж: событие изменения заказа и смены статуса. Логика проста:
- Перехватить смену. В обработчике поймать факт изменения статуса: старое значение и новое.
- Проверить по матрице. Есть ли переход «старый → новый» в таблице допустимых.
- Решить судьбу. Разрешён — пропустить; недопустим — отменить смену и залогировать.
- Учесть источник. Разным источникам (менеджер, клиент, обмен) могут быть доступны разные переходы.
Ключевое — держать эту проверку в одном месте, а не размазывать по шаблонам компонентов, ajax-обработчикам и скриптам. Единая точка контроля означает, что любой источник смены статуса проходит через одни и те же правила. Про аккуратную упаковку такой логики в переиспользуемый код — в материале про разработку модуля под 1С-Битрикс.
Побочные эффекты на переходах
Смена статуса почти всегда тянет за собой действия: письмо клиенту, задачу менеджеру, проводку, обновление остатков. Главная ошибка — привязывать эти действия к факту «статус равен X», а не к переходу «стал X».
Разница критична. Заказ может пересохраняться в статусе «отправлен» несколько раз — обмен, правка менеджера, фоновый агент. Если письмо об отправке привязано к «статус = отправлен», клиент получит его столько раз, сколько заказ пересохранился. Если привязать к переходу «→ отправлен», письмо уйдёт один раз — в момент реального перехода.
Согласование с обменом 1С
Отдельная зона риска — двусторонний обмен CommerceML с 1С. Статусы, флаги оплаты и отгрузки ходят в обе стороны, и если сайт и учётная система по-разному понимают жизненный цикл, начинаются конфликты: 1С возвращает статус, которого сайт не ждёт, или откатывает заказ назад по воронке.
- Маппинг статусов. Явное соответствие между статусами сайта и состояниями заказа в 1С.
- Правила приёма. Изменения из обмена тоже проходят через автомат: недопустимый переход из 1С не применяется вслепую.
- Разрешение конфликтов. Договорённость, чья версия статуса главнее в спорной ситуации.
- Идемпотентность. Повторный приём того же статуса не порождает повторных эффектов.
Обмен — источник смены статусов наравне с людьми, поэтому он тоже подчиняется правилам автомата. Как безопасно принимать внешние изменения и не доверять им вслепую, мы разбираем в статье про REST, вебхуки и безопасность в 1С-Битрикс.
История и аудит статусов
Автомат без журнала — полдела. История смены статусов отвечает на вопрос «как заказ оказался в этом состоянии» и незаменима при разборе инцидентов.
- Кто перевёл. Источник изменения: менеджер, клиент, обмен, платёжный шлюз, агент.
- Когда. Точное время перехода для восстановления хронологии.
- Из чего в что. Старый и новый статус — вся траектория заказа.
- Отклонённые попытки. Логировать и недопустимые переходы — они сигнализируют о проблемах в процессе.
Журнал переходов — это и разбор споров с клиентами, и материал для аналитики: сколько заказы «висят» на каждом этапе, где узкие места выполнения. Без истории любая аномалия остаётся загадкой.
Реализация пошагово
- Опишите статусы. Соберите реальные статусы процесса и разнесите их по измерениям: выполнение, оплата, отгрузка.
- Составьте матрицу переходов. Задайте допустимые переходы для каждого измерения в одном конфигурационном месте.
- Повесьте страж. В обработчике события смены статуса проверяйте переход по матрице и отклоняйте недопустимые.
- Перенесите эффекты на переходы. Уведомления и проводки привяжите к переходам, а не к значениям статуса.
- Согласуйте обмен. Настройте маппинг с 1С и пропускайте изменения из обмена через тот же автомат.
- Заведите историю. Логируйте каждый переход с источником и временем, включая отклонённые.
- Протестируйте сценарии. Прогоните оплату, отгрузку, отмену, возврат и обмен, проверьте отсутствие дублей уведомлений.
Частые ошибки
- Нет правил переходов. Статусы меняются откуда угодно и куда угодно, состояние заказа разъезжается.
- Проверки размазаны. Логика статусов раскидана по шаблонам и скриптам, нет единой точки контроля.
- Эффекты на состоянии. Письма и проводки привязаны к «статус = X» и дублируются при пересохранении.
- Обмен доверяют вслепую. Статус из 1С применяется без проверки по автомату.
- Всё в один список. Оплату, отгрузку и выполнение впихнули в один линейный статус — комбинаторный взрыв.
- Нет истории. Journal переходов отсутствует, инциденты неразбираемы.
- Матрица захардкожена. Правила переходов раскиданы по коду и их нельзя окинуть взглядом.
Чек-лист внедрения
- Статусы описаны. Составлен список статусов по измерениям с понятным смыслом каждого.
- Матрица есть. Допустимые переходы заданы в одном конфигурационном источнике.
- Страж работает. Обработчик события отклоняет недопустимые переходы независимо от источника.
- Эффекты на переходах. Уведомления и проводки срабатывают один раз в момент перехода.
- Обмен согласован. Настроен маппинг с 1С, изменения из обмена проходят через автомат.
- История ведётся. Каждый переход логируется с источником, временем и результатом.
- Роли учтены. Разным источникам доступны разные переходы согласно процессу.
- Сценарии протестированы. Оплата, отгрузка, отмена, возврат и обмен проверены без дублей и конфликтов.
Вывод
Бардак со статусами заказа — не про плохих менеджеров, а про отсутствие правил. Как только статус может меняться откуда угодно и куда угодно, несогласованные состояния, дубли уведомлений и конфликты с 1С становятся вопросом времени. Конечный автомат состояний решает проблему в корне: конечный набор статусов, явная матрица допустимых переходов и единый страж, через который проходит любое изменение.
В 1С-Битрикс это ложится на штатную модель заказа естественно: статусы и события уже есть, нужно добавить поверх них дисциплину переходов, привязать эффекты к переходам, согласовать модель с обменом и завести историю. Результат — предсказуемый жизненный цикл заказа, где заказ не прыгает по воронке назад, клиент не получает лишних писем, а сайт и 1С говорят на одном языке.
