Представьте: менеджер переводит заказ в «доставляется», хотя товар ещё не собрали. Или отменяет уже оплаченный заказ, вынуждая бухгалтерию оформлять возврат через 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. Мы настраиваем обмен так, чтобы ошибки синхронизации не блокировали заказ — используется механизм очередей и повторных попыток. Это гарантирует, что статусы будут обновлены даже при временной недоступности внешних систем.
Сравнение с самостоятельной реализацией
| Параметр | Самостоятельная реализация | Наша разработка |
|---|---|---|
| Сроки | 2–4 недели с учётом ошибок | 1–5 дней |
| Риски | Высокие: кэширование событий, права доступа, обработка ошибок | Гарантия стабильной работы 12 месяцев |
| Интеграции | Дорабатывать отдельно | Подключение склада, доставки, 1С, 54-ФЗ |
| Поддержка | Нет | 1 месяц бесплатного сопровождения |
Самостоятельная реализация занимает в 4 раза больше времени и имеет высокие риски. Одна ошибка в обработчике может полностью парализовать работу с заказами. Наша разработка проверена на 50+ проектах и гарантирует стабильность.
Типичные ошибки при реализации кастомной логики
Вот что часто идёт не так:
- Забывают отключить стандартные события при переопределении — возникает двойной вызов.
- Не учитывают, что
OnSaleOrderBeforeStatusChangeвызывается и для частичной отгрузки — нужна проверка типа сущности. - Пропускают обработку ошибок в интеграциях с внешними сервисами — заказ зависает в промежуточном статусе.
- Не кэшируют матрицу переходов — каждый запрос к заказу вызывает чтение из файла.
Мы учитываем все эти нюансы: используем тегированное кэширование, добавляем логирование всех ошибок, и пишем unit-тесты на каждый обработчик. Это сокращает время на отладку и исключает простои.
Что входит в работу?
| Deliverable | Описание |
|---|---|
| Техническое задание | Фиксируем матрицу переходов, роли, интеграции |
| Код обработчиков | Событийные классы с валидацией и реакциями |
| Интеграции | 1С (CommerceML), службы доставки (СДЭК, Почта России), 54-ФЗ |
| Документация | Описание логики и инструкция для менеджеров |
| Обучение | 1 час консультации для команды |
| Поддержка | 1 месяц бесплатного сопровождения после деплоя |
Сколько времени занимает разработка?
| Этап | Длительность | Результат |
|---|---|---|
| Анализ | 0.5 дня | ТЗ, схема статусов |
| Разработка ядра | 1–2 дня | Обработчики, валидация, реакции |
| Тестирование | 0.5–1 день | Протокол тестирования, исправления |
| Деплой на бой | 0.5 дня | Рабочая система, документация |
Базовая матрица с валидацией и реакциями на 3–5 статусов — 1–2 дня. Полноценная система с журналом, интерфейсом комментариев, интеграцией со складом и службой доставки — 3–5 дней. Стоимость рассчитывается индивидуально — свяжитесь с нами, оценим ваш проект за 1 день.
Работаем официально, предоставляем гарантию 12 месяцев на все доработки. Обсудим ваш бизнес-процесс и предложим решение. Получите консультацию прямо сейчас.