Розробка кастомної логіки зміни статусів замовлення 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 місяців на всі доробки. Обговоримо ваш бізнес-процес і запропонуємо рішення. Отримайте консультацію прямо зараз.