Ситуація: у інтернет-магазину на 1С-Бітрікс обсяг замовлень виріс до 200 на день, і менеджери витрачають по 6 годин на ручну зміну статусів: підтвердження оплати, скасування прострочених, переведення в доставлені. У результаті зростає навантаження, клієнти скаржаться на затримки, а повернення збільшуються на 20% через пропущені сповіщення. Ми автоматизуємо зміну статусів під ключ: від простої події при оплаті до повної інтеграції з транспортними компаніями та бізнес-процесами. Наш підхід знижує ручне втручання на 70% і суттєво економить бюджет на FTE менеджера. Ми займаємося автоматизацією Бітрікс більше 5 років, реалізували проєкти для 50+ магазинів.
Як працює автоматична зміна статусів замовлення?
Система реагує на ключові події в життєвому циклі замовлення. Розглянемо три основні підходи.
Автозміна статусу при оплаті
Подія OnSalePaymentPaid спрацьовує коли платіжний модуль позначає оплату проведеною — і при ручному підтвердженні менеджером, і при автоматичному IPN від платіжної системи (наприклад, ЮKassa або Сбер):
AddEventHandler('sale', 'OnSalePaymentPaid', function(\Bitrix\Main\Event $event) { $payment = $event->getParameter('ENTITY'); $order = $payment->getOrder(); if ($payment->isPaid() && $order->getField('STATUS_ID') === 'WAIT_PREPAY') { $order->setField('STATUS_ID', 'F'); $order->save(); } }); Автоскасування за часом
Реалізується через агент Бітрікс — він запускається за розкладом і перевіряє замовлення без оплати. Ліміт 50 замовлень за ітерацію захищає від таймауту при великому накопиченому обсязі:
// Реєстрація агента (разово) \CAgent::AddAgent( 'Local\\Sale\\OrderAgents::cancelUnpaidOrders();', 'local', 'N', 3600, // кожну годину '', 'Y', \ConvertTimeStamp(time() + 3600, 'FULL'), ); class OrderAgents { public static function cancelUnpaidOrders(): string { $deadline = new \Bitrix\Main\Type\DateTime(); $deadline->add('-24 hours'); $result = \Bitrix\Sale\Internals\OrderTable::getList([ 'filter' => [ 'STATUS_ID' => 'WAIT_PREPAY', '<DATE_INSERT' => $deadline, ], 'select' => ['ID'], 'limit' => 50, ]); while ($row = $result->fetch()) { $order = \Bitrix\Sale\Order::load($row['ID']); if ($order) { $order->setField('STATUS_ID', 'CANCEL'); $order->save(); } } return 'Local\\Sale\\OrderAgents::cancelUnpaidOrders();'; } } Автоматизація через бізнес-процеси
Для складних ланцюжків з умовами та затримками — бізнес-процеси Sale (Інтернет-магазин → Бізнес-процеси замовлень). Доступні тригери:
- За статусом — запуск при переході в певний статус
- За оплатою — при підтвердженні або поверненні платежу
- За часом — через N годин/днів після створення або зміни статусу
Приклад: «Через 2 години після переходу в Передано кур'єру — надіслати SMS із запитом оцінки». Реалізується без коду через конструктор BP.
Чому варто автоматизувати зміну статусів?
Окрім економії часу, автоматизація знижує ризик помилок людського фактора (пропущений платіж, забуте скасування) і покращує користувацький досвід — клієнти отримують актуальну інформацію без затримок. Наші клієнти відзначають скорочення часу обробки замовлення на 70% і зменшення кількості повернень на 15% за рахунок своєчасних сповіщень. Для простих сценаріїв агенти обробляють замовлення в 2 рази швидше, ніж бізнес-процеси, але BP зручніші при складній логіці.
Який підхід обрати: агенти чи бізнес-процеси?
| Критерій | Агенти (код) | Бізнес-процеси (BP) |
|---|---|---|
| Гнучкість | Повний контроль логіки | Обмежений шаблонами |
| Швидкість розробки | Години | Хвилини (якщо шаблон готовий) |
| Потрібен розробник | Так | Ні (можна силами адміністратора) |
| Інтеграція з зовнішніми API | Проста | Складніше (через REST) |
| Масштабування | Обмеження 50 замовлень за крок | Залежить від продуктивності |
Які events використовуються для авто зміни?
Типові сценарії та тригери зведені в таблицю:
| Поточний статус | Подія | Новий статус |
|---|---|---|
| WAIT_PREPAY | Оплата | F (Виконано) |
| WAIT_PREPAY | 24 години без оплати | CANCEL (Скасовано) |
| D (Доставлено) | 14 днів без претензій | CLOSED (Закрито) |
Докладніше про подію OnSalePaymentPaid — в офіційній документації. Автоматизація в цілому описана на Wikipedia.
Процес роботи
- Аналітика — вивчаємо поточні статуси, сценарії, логіку обміну з 1С.
- Проєктування — обираємо підхід (події/агенти/BP) для кожного сценарію.
- Реалізація — пишемо код або налаштовуємо BP, тестуємо на тестовому замовленні.
- Тест — проганяємо всі сценарії (оплата, скасування, доставка) в staging-середовищі.
- Деплой — переносимо на бойову, моніторимо логи в першу добу.
Що входить у налаштування (deliverables)
- Створення файлу
local/php_interface/init.phpз обробниками подій (якщо потрібно). - Налаштування агентів із зазначенням періодичності.
- Конфігурація бізнес-процесів (якщо потрібно) через адмінку.
- Інтеграція з webhook від транспортної компанії (наприклад, СДЕК API або Пошта Росії API).
- Документація: опис усіх автоматичних переходів.
- Доступ до git-репозиторію з кодом.
- Навчання адміністратора (1 година).
- Гарантія 14 днів на коректну роботу скриптів.
Типова помилка при інтеграції транспортної компанії: якщо в webhook приходить статус, якого немає в маппінгу, замовлення залишається без зміни. Рішення: додати логування невідомих статусів і налаштувати сповіщення адміністратору.
Інтеграція зі статусами транспортних компаній
// Webhook від ТК — POST /bitrix/tools/delivery_webhook.php $trackNumber = $_POST['track']; $deliveryStatus = $_POST['status']; $shipmentResult = \Bitrix\Sale\Internals\ShipmentTable::getList([ 'filter' => ['TRACKING_NUMBER' => $trackNumber], 'select' => ['ORDER_ID'], ]); if ($shipment = $shipmentResult->fetch()) { $order = \Bitrix\Sale\Order::load($shipment['ORDER_ID']); $statusMap = ['delivered' => 'D', 'returned' => 'RETURN_INIT', 'lost' => 'PROBLEM']; $newStatus = $statusMap[$deliveryStatus] ?? null; if ($newStatus && $order) { $order->setField('STATUS_ID', $newStatus); $order->save(); } } Автозавершення доставлених замовлень
Переведення в «Закрито» через 14 днів після доставки без претензій:
public static function completeDeliveredOrders(): string { $deadline = new \Bitrix\Main\Type\DateTime(); $deadline->add('-14 days'); $result = \Bitrix\Sale\Internals\OrderTable::getList([ 'filter' => ['STATUS_ID' => 'D', '<DATE_STATUS' => $deadline], 'select' => ['ID'], 'limit' => 100, ]); while ($row = $result->fetch()) { $order = \Bitrix\Sale\Order::load($row['ID']); if ($order) { $order->setField('STATUS_ID', 'CLOSED'); $order->save(); } } return 'Local\\Sale\\OrderAgents::completeDeliveredOrders();'; } Терміни виконання
Автозміна при оплаті та один агент автоскасування — 3–5 годин. Повна автоматизація з інтеграцією ТК, бізнес-процесами та декількома агентами — 1–3 робочі дні. Оцінимо ваш проєкт безкоштовно — зв'яжіться з нами для аудиту. Замовте налаштування та отримайте готове рішення з гарантією 14 днів.