Разработка кастомной логики смены статусов заказа 1С-Битрикс

Представьте: менеджер переводит заказ в «доставляется», хотя товар ещё не собрали. Или отменяет уже оплаченный заказ, вынуждая бухгалтерию оформлять возврат через 1С. Мы сталкивались с такими кейсами десятки раз. Стандартный механизм статусов 1С-Битрикс даёт полную свободу — но именно она и приводит к ошибкам. Кастомная логика переходов решает это: жёсткая матрица, ролевые права, автоматические действия после смены статуса. За 5 лет мы реализовали более 50 проектов с кастомной логикой заказов, и в каждом случае количество ошибок сокращалось на 95%.

Наша услуга — разработка кастомной логики смены статусов заказа — включает валидацию по матрице, интеграцию с 1С через CommerceML, поддержку 54-ФЗ и ОФД. Мы используем события ядра и компонентную модель Битрикс. Стоимость рассчитывается индивидуально — свяжитесь с нами для оценки вашего проекта.

Почему стандартные статусы заказа опасны?

Встроенный интерфейс Битрикс позволяет менеджеру перевести заказ в любой статус, если хватает прав. Но реальный бизнес-процесс сложнее: «доставляется» возможен только после «собирается», отмена — только до оплаты, возврат из завершённого — для администратора. Без кастомной логики ошибки неизбежны. Наша валидация сокращает их количество на 95% по опыту проектов, обрабатывающих до 3000 заказов в день. Официальная документация 1С-Битрикс подтверждает: событие OnSaleOrderBeforeStatusChange — единственный способ внедрить такую логику.

Как работает кастомная валидация переходов?

Битрикс предоставляет событие OnSaleOrderBeforeStatusChange — обработчик может заблокировать переход и вернуть ошибку. Мы используем этот механизм как основу.

// /local/php_interface/init.php \Bitrix\Main\EventManager::getInstance()->addEventHandler( 'sale', 'OnSaleOrderBeforeStatusChange', ['\App\Order\StatusValidator', 'validate'] ); 

// /local/lib/Order/StatusValidator.php namespace App\Order; use Bitrix\Main\Event; use Bitrix\Main\EventResult; use Bitrix\Sale\Order; class StatusValidator { // Матрица допустимых переходов private static array $allowedTransitions = [ 'N' => ['P', 'A'], // Новый → Принят или Отменён 'P' => ['W', 'ASSEMBLY', 'A'], // Принят → Ожидает оплаты, Сборка, Отменён 'W' => ['P', 'ASSEMBLY', 'A'], // Ожидает оплаты → Принят, Сборка, Отменён 'ASSEMBLY' => ['D', 'A'], // Сборка → Доставляется, Отменён 'D' => ['F'], // Доставляется → Завершён 'F' => [], // Завершён — финальный 'A' => [], // Отменён — финальный ]; public static function validate(Event $event): EventResult { /** @var Order $order */ $order = $event->getParameter('ENTITY'); $newStatus = $event->getParameter('VALUE'); $currentStatus = $order->getField('STATUS_ID'); $allowed = self::$allowedTransitions[$currentStatus] ?? []; if (!in_array($newStatus, $allowed, true)) { return new EventResult( EventResult::ERROR, [ 'message' => sprintf( 'Переход из статуса "%s" в "%s" запрещён', $currentStatus, $newStatus ), ], 'sale' ); } // Дополнительная бизнес-проверка: нельзя отменить оплаченный заказ if ($newStatus === 'A' && $order->isPaid()) { return new EventResult( EventResult::ERROR, ['message' => 'Нельзя отменить оплаченный заказ. Оформите возврат.'], 'sale' ); } // Проверка ролей: возврат из финального статуса — только администратор global $USER; if ($currentStatus === 'F' && !$USER->IsAdmin()) { return new EventResult( EventResult::ERROR, ['message' => 'Изменение завершённого заказа доступно только администратору'], 'sale' ); } return new EventResult(EventResult::SUCCESS); } } 

Какие автоматические действия можно настроить?

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

\Bitrix\Main\EventManager::getInstance()->addEventHandler( 'sale', 'OnSaleOrderStatusChange', function(Event $event) { $order = $event->getParameter('ENTITY'); $newStatus = $event->getParameter('VALUE'); $oldStatus = $event->getParameter('OLD_VALUE'); switch ($newStatus) { case 'ASSEMBLY': WarehouseIntegration::createPickingTask($order); break; case 'D': DeliveryService::registerShipment($order); Notifications::sendTrackingNumber($order); break; case 'F': LoyaltyProgram::creditPoints($order); ReviewRequest::schedule($order->getUserId(), 3); break; case 'A': if ($oldStatus !== 'N') { StockManager::releaseReservation($order); } if ($order->isPaid()) { RefundManager::initiate($order); } break; } } ); 

Что даёт кастомный интерфейс с комментариями?

Все смены статусов автоматически логируются в b_sale_order_change. Для дополнительного аудита мы создаём собственную таблицу с историей переходов и причинами. При каждой смене статуса записываем order_id, from_status, to_status, user_id, comment и timestamp. Стандартный интерфейс не предоставляет поле комментария при смене статуса. Мы реализуем кастомный AJAX-обработчик на странице детали заказа в админке, куда менеджер вводит причину перехода. Комментарий сохраняется в сессии и передаётся в событие.

Как интегрировать кастомную логику с 1С и службами доставки?

Интеграция с 1С через CommerceML позволяет синхронизировать статусы заказов автоматически. При смене статуса на «ASSEMBLY» данные передаются в 1С: УТ, где резервируется товар. Аналогично, при «D» — в службу доставки (СДЭК, Почта России) через их API. Мы настраиваем обмен так, чтобы ошибки синхронизации не блокировали заказ — используется механизм очередей и повторных попыток. Это гарантирует, что статусы будут обновлены даже при временной недоступности внешних систем.

Сравнение с самостоятельной реализацией

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

Типичные ошибки при реализации кастомной логики

Вот что часто идёт не так:

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

Мы учитываем все эти нюансы: используем тегированное кэширование, добавляем логирование всех ошибок, и пишем unit-тесты на каждый обработчик. Это сокращает время на отладку и исключает простои.

Что входит в работу?

Сколько времени занимает разработка?

Базовая матрица с валидацией и реакциями на 3–5 статусов — 1–2 дня. Полноценная система с журналом, интерфейсом комментариев, интеграцией со складом и службой доставки — 3–5 дней. Стоимость рассчитывается индивидуально — свяжитесь с нами, оценим ваш проект за 1 день.

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