Уявіть: менеджер переводить замовлення в «доставляється», хоча товар ще не зібрали. Або скасовує вже оплачене замовлення, змушуючи бухгалтерію оформлювати повернення через 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-тести на кожен обробник. Це скорочує час на налагодження та виключає простої.
Що входить в роботу?
| Результат | Опис |
|---|---|
| Технічне завдання | Фіксуємо матрицю переходів, ролі, інтеграції |
| Код обробників | Подійні класи з валідацією та реакціями |
| Інтеграції | 1С (CommerceML), служби доставки (СДЕК, Пошта Росії), 54-ФЗ |
| Документація | Опис логіки та інструкція для менеджерів |
| Навчання | 1 година консультації для команди |
| Підтримка | 1 місяць безкоштовного супроводу після деплою |
Скільки часу займає розробка?
| Етап | Тривалість | Результат |
|---|---|---|
| Аналіз | 0.5 дня | ТЗ, схема статусів |
| Розробка ядра | 1–2 дні | Обробники, валідація, реакції |
| Тестування | 0.5–1 день | Протокол тестування, виправлення |
| Деплой на бой | 0.5 дня | Робоча система, документація |
Базова матриця з валідацією та реакціями на 3–5 статусів — 1–2 дні. Повноцінна система з журналом, інтерфейсом коментарів, інтеграцією зі складом та службою доставки — 3–5 днів. Вартість розраховується індивідуально — зв'яжіться з нами, оцінимо ваш проєкт за 1 день.
Працюємо офіційно, надаємо гарантію 12 місяців на всі доробки. Обговоримо ваш бізнес-процес і запропонуємо рішення. Отримайте консультацію прямо зараз.