Налаштування автоматичної зміни статусів замовлення 1С-Бітрікс

Ситуація: у інтернет-магазину на 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 зручніші при складній логіці.

Який підхід обрати: агенти чи бізнес-процеси?

Які events використовуються для авто зміни?

Типові сценарії та тригери зведені в таблицю:

Докладніше про подію OnSalePaymentPaid — в офіційній документації. Автоматизація в цілому описана на Wikipedia.

Процес роботи

1. Аналітика — вивчаємо поточні статуси, сценарії, логіку обміну з 1С.
2. Проєктування — обираємо підхід (події/агенти/BP) для кожного сценарію.
3. Реалізація — пишемо код або налаштовуємо BP, тестуємо на тестовому замовленні.
4. Тест — проганяємо всі сценарії (оплата, скасування, доставка) в staging-середовищі.
5. Деплой — переносимо на бойову, моніторимо логи в першу добу.

Що входить у налаштування (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 днів.

Як налаштування кошика 1С-Бітрікс вирішує проблему втрати конверсії

Ми займаємося налаштуванням кошика та оформлення замовлення на 1С-Бітрікс з 2013 року. За цей час зіткнулися з типовою проблемою: штатний sale.order.ajax втрачає на кожному кроці 10–15% покупців. Три кроки — і третина тих, хто вже додав товар, іде. Не тому що передумали — інтерфейс спотикається.

sale.order.ajax видає 500-ку, якщо не налаштований хоча б один обробник доставки. Зависає на 15 секунд при розрахунку НПП — запит синхронний, без таймауту. Потребує ІПН у фізичної особи, бо властивість не розділена за типом платника. Кожен такий кейс — прямі втрати, які система не компенсує.

Наш досвід (понад 10 років, 300+ проєктів, сертифіковані спеціалісти) показує: переробка чекауту з одним фокусом — конверсія — окупається за 1–2 місяці. Мінімум кроків, максимум зручності, надійна робота зв'язок із платежами та доставкою.

Чому однокроковий чекаут збільшує конверсію?

Всі поля на одній сторінці. Логічне групування, жодних зайвих переходів:

• Контактні дані — ім'я, телефон, email. Три поля. Не п'ять, не десять, не «вкажіть дату народження для програми лояльності».
• Доставка — вибрав місто → побачив способи з цінами та термінами. AJAX-розрахунок через API НПП, Boxberry, Укрпошти. Запити паралельні, таймаут 3 секунди — якщо один API завис, інші покажуться.
• Оплата — способи фільтруються за вибраною доставкою. Післяплата при самовивозі? Не показуємо.
• Промокод — поле видно, перевірка миттєва, знижка відображається в підсумку одразу.
• Підсумок — динамічний перерахунок за будь-якої зміни. Змінив кількість → сума → вартість доставки → підсумок. Без перезавантаження.

Під капотом:

• Повний AJAX — жодного перезавантаження. Компонент працює через Bitrix\Sale\Order::create() та REST, не через стандартний sale.order.ajax.
• Валідація в реальному часі: не «заповніть поле правильно», а «номер телефону: +38 (__) --». Маска inputmask + серверна перевірка.
• Збереження даних при випадковому відході — sessionStorage зберігає введене, при поверненні все на місці.
• Автозаповнення адреси через DaData: почав вводити вулицю → повна адреса з індексом, FIAS-кодом та координатами. Менше помилок з боку кур'єрської.
• Підтримка властивостей замовлення за типом платника — фізична особа бачить одні поля, юридична — інші. Перемикач у формі.

Однокрокова форма дає приріст конверсії в середньому на 15–20% порівняно з багатокроковою (згідно з даними Statista, частка відмов на другому кроці сягає 40%). Джерело: Statista, дослідження чекауту в e-commerce.

Як відновити покинуті кошики?

Збереження. Авторизовані — кошик у b_sale_basket, доступний з будь-якого пристрою. Гості — cookie з TTL 30 днів. FUSER_ID прив'язаний до cookie, кошик не пропаде через годину. Синхронізація: додав з телефону, оформив з ноутбука — кошик єдиний.

Повернення. Email-серія: 3 листи. Через 1 годину — нагадування. Через 24 години — «ваш товар закінчується». Через 72 години — персональний промокод на 5–10%. Реалізація через sale.basketcomponent + CEvent::Send() з відкладеною відправкою через агенти. Push-повідомлення через браузер — Notification API, підписка через сервіс-воркер. Ретаргетинг — дані про кошик йдуть у Google Ads через eCommerce-події.

Аналітика відмов. На якому кроці йдуть? Якщо на виборі доставки — ціна шокує. Якщо на оплаті — карта відхиляється, 3D-Secure не проходить. Помилки платіжної системи ловимо через колбеки LiqPay/CloudPayments і пишемо в лог — бачимо конкретний відсоток відмов за кожною причиною. Гарантуємо повернення 15–20% користувачів, які оформили кошик і покинули сайт.

Гостьове замовлення: убити обов'язкову реєстрацію

«Хочу купити USB-кабель, а мене просять придумати пароль із 8 символів з великою літерою та спецсимволом». Обов'язкова реєстрація вбиває 25–30% конверсії на дрібних замовленнях.

• Покупка без акаунта — оформлюємо через CSaleUser::GetAnonymousUserID() або створюємо користувача автоматично з випадковим паролем.
• Після оформлення — лист з даними для входу. Хоче — активує акаунт, не хоче — і так отримає замовлення.
• Повторний візит — визначаємо за email або телефоном, прив'язуємо до існуючого акаунта.
• Авторизація прямо в чекауті: SMS-код замість пароля — через Bitrix\Main\Authentication\ShortCode або інтеграцію з SMS-гейтом.

Крос-сел: допродажі, які не дратують

У кошику

Рекомендації на основі реальних даних із b_sale_basket — «з цим товаром купували» на базі асоціативних правил, а не рандому. Прив'язка через властивість інфоблоку PROPERTY_ACCESSORIES. Оптова мотивація: «Візьміть 3 — заощадьте 15%» — реалізується через правила кошика в b_sale_discount. Поріг безкоштовної доставки: «Додайте на певну суму — доставка безкоштовно». Простий віджет, але збільшує середній чек на 10–20%.

Управління через адмінку

Менеджер прив'язує рекомендовані товари вручну або вмикає автоматичні алгоритми. Правила відображення: категорія, діапазон цін, наявність. A/B-тестування різних стратегій — без розробника.

Промокоди: правильна реалізація

UX промокоду:

• Поле видно, але не кричить — не відволікає тих, у кого коду немає.
• Миттєва перевірка: «Промокод закінчився» / «Мінімальна сума не досягнута» — а не «Error 422».
• Знижка видна в підсумковому розрахунку окремим рядком.
• Можна прибрати промокод і застосувати інший.

UX-оптимізація: дрібниці, які вирішують

Десктоп:

• Прогрес-бар — користувач бачить, де він.
• Розумні дефолти — найпопулярніший спосіб доставки вже вибраний (визначаємо за статистикою b_sale_order).
• Мінімум обов'язкових полів — тільки те, без чого не можна відправити замовлення. По батькові? Необов'язково. Коментар? Необов'язково.
• Перерахунок без лоадерів на 5 секунд — debounce 300ms на AJAX-запитах.

Мобільні:

• Великі кнопки — палець не промахується. min-height: 48px за гайдами Google.
• Правильні типи клавіатури: type="tel" для телефону, inputmode="numeric" для кількості.
• Кнопка «Оформити» зафіксована внизу — position: sticky.
• Згорнуті секції — екранний простір на 375px дорогий.

Обробка помилок:

• «Перевірте номер картки» замість «Payment processing error».
• Автопрокрутка до першої помилки — scrollIntoView({ behavior: 'smooth' }).
• «Товар закінчився» — обробляємо без втрати заповнених даних. Пропонуємо аналог або прибираємо з перерахунком.

Інтеграції

• DaData — адреса, ПІБ, ІПН. Підказки під час введення, валідація ФІАС.
• Google Maps — вибір пунктів видачі на карті, геолокація для визначення міста.
• НПП, Boxberry, Укрпошта — API-розрахунок вартості та термінів у реальному часі.
• LiqPay, CloudPayments, ПриватБанк — прийом платежів, рекурентні списання, холдування.
• CRM — замовлення автоматично йде в Бітрікс24, створюється угода з прив'язкою до контакту.
• Склад — перевірка залишків через CCatalogStoreProduct::GetList() у реальному часі.

// Псевдокод для паралельних запитів
$promises = [];
foreach ($tariffs as $tariff) {
    $promises[] = async(function() use ($tariff, $basket) {
        return $tariff->calculate($basket);
    });
}
$results = awaitAll($promises, 3000);

Що входить у роботу

• Аналіз поточного чекауту та виявлення вузьких місць (аудит конверсії, логів, помилок).
• Проєктування UX: прототипування однокрокової форми, узгодження із замовником.
• Розробка компонента чекауту на основі Bitrix\Sale\Order + REST, з заміною sale.order.ajax.
• Інтеграція з платіжними (LiqPay, CloudPayments, ПриватБанк) та логістичними API (НПП, Boxberry, Укрпошта).
• Налаштування промокодів, крос-селу, покинутих кошиків.
• Тестування на реальних сценаріях: десктоп, мобільні, планшети.
• Передача документації (опис API, інструкції для менеджерів, доступи).
• Навчання співробітників роботі з новим кошиком.
• Пост-релізна підтримка — 2 тижні моніторингу та правок.

Строки

Зв'яжіться з нами для обговорення вашого проєкту та отримайте консультацію з конкретних завдань. Замовте аудит кошика вже сьогодні — побачите, скільки конверсії втрачається на кожному кроці. Збільшення конверсії чекауту на 1–2% при стабільному трафіку — це зростання виручки без зростання рекламного бюджету. Найшвидший ROI в e-commerce.