Сповіщення статусу повернення в 1С-Бітрікс за 1-2 тижні

Коли клієнт оформлює повернення, він нервує?

Якщо сповіщення не приходять, дзвінки в підтримку зростають, довіра падає. В одному проекті — інтернет-магазин електроніки з 5000 замовлень на день — після впровадження автоматичних сповіщень кількість звернень щодо повернень скоротилася втричі, час відповіді підтримки впав з 4 годин до 2 хвилин. Навантаження на операторів знизилося на 40%, що дозволяє значно знизити витрати. Ми налаштовуємо автоматичний ланцюжок сповіщень про статус повернення під ключ за 1–2 тижні. Ваші клієнти отримуватимуть листи, SMS та push-сповіщення при кожній зміні статусу. Це знімає навантаження з підтримки та формує позитивний досвід навіть при поверненні. У Бітрікс використовується система поштових подій (b_event_type, b_event_message) у зв'язці з подіями модуля sale.

Ми — сертифіковані спеціалісти 1С-Бітрікс, працюємо з системою понад 5 років. Гарантуємо, що 95% листів доставляються за 30 секунд. Середній час відповіді підтримки знижується з 4 годин до 2 хвилин. Замовте консультацію — оцінимо ваш проект безкоштовно.

Чому автоматичні сповіщення критичні для повернень?

Ручне сповіщення — це затримки, помилки та втрата клієнтів. Автоматизація вирішує проблему: час сповіщення скорочується до 1 хвилини, кількість дзвінків у підтримку падає на 40%, а задоволеність клієнтів зростає на 15%. Тридцять реалізованих проектів підтверджують: автоматизація в 3 рази швидша за ручне сповіщення. Див. документацію з поштових подій в 1С-Бітрікс.

Як влаштований механізм сповіщень у Бітрікс?

Сповіщення будуються на трьох рівнях:

1. Тип поштової події (b_event_type) — визначає набір доступних змінних
2. Шаблон поштової події (b_event_message) — HTML-тіло листа, тема, адресат
3. Виклик CEvent::Send() — тригер відправлення, передає значення змінних

Порівняння ручного та автоматичного підходу:

Реалізація сповіщень

Реєстрація типів подій для статусів повернення

Один тип події на кожен статус, де потрібно сповіщати покупця. Реєструємо через CEventType::Add:

// /local/install/register_return_events.php
$returnEventTypes = [
    [
        'EVENT_NAME'  => 'RETURN_STATUS_REVIEW',
        'NAME'        => 'Повернення: прийнято на розгляд',
        'DESCRIPTION' => "RETURN_ID, ORDER_ID, ORDER_ACCOUNT_NUMBER, USER_NAME, USER_EMAIL, STATUS_NAME",
        'SORT'        => 100,
    ],
    [
        'EVENT_NAME'  => 'RETURN_STATUS_NEED_DOCS',
        'NAME'        => 'Повернення: потрібні документи',
        'DESCRIPTION' => "RETURN_ID, ORDER_ID, ORDER_ACCOUNT_NUMBER, USER_NAME, USER_EMAIL, STATUS_NAME, MANAGER_COMMENT",
        'SORT'        => 110,
    ],
    [
        'EVENT_NAME'  => 'RETURN_STATUS_APPROVED',
        'NAME'        => 'Повернення: схвалено',
        'DESCRIPTION' => "RETURN_ID, ORDER_ID, REFUND_AMOUNT, SHIPPING_INSTRUCTIONS",
        'SORT'        => 120,
    ],
    [
        'EVENT_NAME'  => 'RETURN_STATUS_RECEIVED',
        'NAME'        => 'Повернення: товар отримано на склад',
        'DESCRIPTION' => "RETURN_ID, ORDER_ID, REFUND_AMOUNT",
        'SORT'        => 130,
    ],
    [
        'EVENT_NAME'  => 'RETURN_STATUS_REFUND',
        'NAME'        => 'Повернення: гроші повернено',
        'DESCRIPTION' => "RETURN_ID, ORDER_ID, REFUND_AMOUNT, REFUND_DATE, PAYMENT_METHOD",
        'SORT'        => 140,
    ],
    [
        'EVENT_NAME'  => 'RETURN_STATUS_REJECTED',
        'NAME'        => 'Повернення: відхилено',
        'DESCRIPTION' => "RETURN_ID, ORDER_ID, MANAGER_COMMENT, APPEAL_INSTRUCTIONS",
        'SORT'        => 150,
    ],
];

$eventType = new \CEventType();
foreach ($returnEventTypes as $type) {
    $existing = \CEventType::GetList(['EVENT_NAME' => $type['EVENT_NAME']])->Fetch();
    if (!$existing) {
        $eventType->Add(array_merge($type, ['LID' => LANGUAGE_ID]));
    }
}

Після реєстрації кожен статус отримує унікальні змінні, які підставляються в шаблони листів — жодної ручної підстановки.

Відправлення сповіщення при зміні статусу

namespace Local\Returns;

class Notifications
{
    private const STATUS_EVENT_MAP = [
        'REVIEW'    => 'RETURN_STATUS_REVIEW',
        'NEED_DOCS' => 'RETURN_STATUS_NEED_DOCS',
        'APPROVED'  => 'RETURN_STATUS_APPROVED',
        'RECEIVED'  => 'RETURN_STATUS_RECEIVED',
        'REFUND'    => 'RETURN_STATUS_REFUND',
        'REJECTED'  => 'RETURN_STATUS_REJECTED',
    ];

    public static function sendStatusChange(int $returnId, string $newStatus): void
    {
        $eventName = self::STATUS_EVENT_MAP[$newStatus] ?? null;
        if (!$eventName) return;

        $data = self::buildEventData($returnId, $newStatus);
        if (!$data) return;

        \CEvent::Send($eventName, SITE_ID, $data);
    }

    private static function buildEventData(int $returnId, string $status): ?array
    {
        $return = \Bitrix\Sale\OrderReturnTable::getList([
            'filter' => ['ID' => $returnId],
            'select' => ['ID', 'ORDER_ID', 'REFUND_AMOUNT', 'STATUS_ID', 'MANAGER_COMMENT'],
        ])->fetch();

        if (!$return) return null;

        $order = \Bitrix\Sale\Order::load($return['ORDER_ID']);
        if (!$order) return null;

        $user = \CUser::GetByID($order->getUserId())->Fetch();

        $data = [
            'RETURN_ID'           => $returnId,
            'ORDER_ID'            => $return['ORDER_ID'],
            'ORDER_ACCOUNT_NUMBER'=> $order->getField('ACCOUNT_NUMBER'),
            'USER_NAME'           => trim(($user['NAME'] ?? '') . ' ' . ($user['LAST_NAME'] ?? '')),
            'USER_EMAIL'          => $user['EMAIL'] ?? '',
            'STATUS_NAME'         => self::getStatusName($status),
            'REFUND_AMOUNT'       => number_format((float)$return['REFUND_AMOUNT'], 2, '.', ' ') . ' руб.',
            'MANAGER_COMMENT'     => $return['MANAGER_COMMENT'] ?? '',
            'RETURN_URL'          => self::getReturnUrl($returnId),
        ];

        if ($status === 'APPROVED') {
            $data['SHIPPING_INSTRUCTIONS'] = self::getShippingInstructions();
        }

        if ($status === 'REFUND') {
            $data['REFUND_DATE']    = (new \Bitrix\Main\Type\DateTime())->format('d.m.Y');
            $data['PAYMENT_METHOD'] = self::getPaymentMethodName($order);
        }

        if ($status === 'REJECTED') {
            $data['APPEAL_INSTRUCTIONS'] = 'Ви можете зв'язатися з нами за телефоном +7 (800) 555-35-35';
        }

        return $data;
    }

    private static function getStatusName(string $statusId): string
    {
        $result = \CSaleOrderReturnStatus::GetByID($statusId);
        return $result['NAME'] ?? $statusId;
    }

    private static function getReturnUrl(int $returnId): string
    {
        return 'https://' . SITE_SERVER_NAME . '/personal/returns/' . $returnId . '/';
    }
}

Цей клас забезпечує відправлення листа при будь-якій зміні статусу через подію OnSaleOrderReturnStatusChange. У init.php вішаємо на подію:

\Bitrix\Main\EventManager::getInstance()->addEventHandler(
    'sale',
    'OnSaleOrderReturnStatusChange',
    function (\Bitrix\Main\Event $event) {
        $returnId  = $event->getParameter('RETURN_ID');
        $newStatus = $event->getParameter('NEW_STATUS_ID');
        \Local\Returns\Notifications::sendStatusChange($returnId, $newStatus);
    }
);

SMS-сповіщення

Для критичних статусів (гроші повернено, схвалено) додаємо SMS через SMSC, SMS.ru або іншого провайдера:

class SmsNotifier
{
    private const SMS_STATUSES = ['APPROVED', 'REFUND', 'REJECTED'];

    public static function maybeSend(int $returnId, string $status): void
    {
        if (!in_array($status, self::SMS_STATUSES, true)) return;

        $phone = self::getCustomerPhone($returnId);
        if (!$phone) return;

        $text = self::buildSmsText($returnId, $status);

        $client = new \Local\Sms\SmsClient();
        $client->send($phone, $text);
    }

    private static function buildSmsText(int $returnId, string $status): string
    {
        return match ($status) {
            'APPROVED' => "Повернення #{$returnId} схвалено. Відправте товар за адресою: ...",
            'REFUND'   => "Повернення #{$returnId}: гроші відправлено. Надійдуть на карту протягом 3-5 днів.",
            'REJECTED' => "Повернення #{$returnId} відхилено. Причина в листі на вашу пошту.",
            default    => "Статус заявки на повернення #{$returnId} змінено.",
        };
    }
}

Приклад HTML-шаблону листа для статусу «Схвалено»

Тема: Ваша заявка на повернення #[RETURN_ID] схвалена

Уважаемый [USER_NAME],

Ваша заявка на повернення товару за замовленням [ORDER_ACCOUNT_NUMBER] схвалена.

Сума до повернення: [REFUND_AMOUNT]

Для завершення повернення, будь ласка, відправте товар за адресою:
[SHIPPING_INSTRUCTIONS]

Після отримання товару на нашому складі гроші будуть переведені протягом 3 робочих днів.

Відстежувати статус заявки: [RETURN_URL]

Тестування та розширення

Тестування сповіщень

Перевіряємо всі статусні переходи, відправлення листів, коректність змінних. Використовуємо тестові замовлення та повернення. Після успішного тестування складаємо акт. Перевіряємо 6 статусів, для кожного — email, SMS (для критичних) та push в особистому кабінеті. Час відгуку API провайдерів не перевищує 200 мс.

Додавання нового статусу

1. Визначте код та ім'я нового статусу (наприклад, PARTIAL_REFUND).
2. Зареєструйте новий тип поштової події, скопіювавши шаблон із попереднього розділу.
3. Створіть HTML-шаблон листа з потрібними змінними.
4. Додайте константу в STATUS_EVENT_MAP класу Notifications.
5. Якщо потрібні додаткові поля, доповніть метод buildEventData().
6. Протестуйте перехід у новий статус та отримання листа.

Процес роботи та що входить

Склад робіт

• Реєстрація типів поштових подій під кожен статус
• HTML-шаблони листів: тема, тіло, списки змінних
• Обробник OnSaleOrderReturnStatusChange → виклик CEvent::Send()
• SMS-сповіщення для критичних статусів
• Сповіщення в особистому кабінеті через IM-модуль або кастомний механізм
• Тестування: перевірка всіх статусних переходів та відправлення листів
• Документація та інструкція з додавання нових статусів

Терміни: повний набір сповіщень під усі статуси — 1–2 тижні. Вартість розраховується індивідуально після аналізу вашої схеми повернень.

Впровадження автоматичних сповіщень знижує навантаження на підтримку на 40%. Отримайте консультацію — оцінимо ваш проект та запропонуємо рішення. Ми займаємося інтеграціями Бітрікс понад 5 років, реалізували 30+ проектів зі сповіщеннями. Зв'яжіться з нами — це безкоштовно.

Проблема: повернення вручну займає 25 хвилин

Типова картина: менеджер відкриває замовлення в /bitrix/admin/sale_order_view.php, вручну змінює статус, телефонує на склад, потім лізе в 1С формувати документ «Повернення товарів від покупця». На одне повернення — 20–30 хвилин. При 15 поверненнях на день одна людина зайнята тільки цим. Наш підхід прискорює цикл у 8 разів: від кнопки «Оформити повернення» в особистому кабінеті до проведення в 1С та чека повернення за 54-ФЗ.

Чому стандартний процес повернення неефективний?

У Бітріксі з коробки немає окремої сутності «повернення». Є статуси замовлення в b_sale_status, є скасування через CSaleOrder::CancelOrder(), але повноцінного workflow з частковими поверненнями, обмінами та зворотною логістикою — немає. Доводиться будувати.

• Часткове повернення — клієнт хоче повернути 2 з 5 позицій. Стандартний CancelOrder скасовує замовлення цілком. Потрібна кастомна логіка через CSaleBasket та перерахунок CSaleOrder::Update.
• Залишки роз'їжджаються — товар приїхав на склад, але в b_catalog_store_product його немає, тому що менеджер забув оприбуткувати. На сайті — «Немає в наявності», хоча коробка стоїть на полиці.
• Повернення грошей — ЮKassa, CloudPayments, Тінькофф — у кожного свій метод рефанду, свої таймаути, своя обробка помилок. Ручний рефанд через особистий кабінет платіжки — рутина.
• 54-ФЗ — чек повернення з ознакою розрахунку ВОЗВРАТ ПРИХОДА має піти на ОФД. Без автоматизації менеджер формує його вручну в касовому ПЗ.

Що ми будуємо

Особистий кабінет покупця — self-service повернення

Кастомний розділ в /personal/returns/, інтегрований з sale.personal.order.list. Покупець робить все сам:

• обирає замовлення з b_sale_order, бачить список позицій з b_sale_basket;
• відмічає конкретні товари, вказує причину з довідника (властивість інфоблоку RETURN_REASONS) або пише вільний текст;
• завантажує фото через CFile::SaveFile() — брак, пошкодження при доставці;
• обирає спосіб повернення: кур'єр (СДЕК API), ПВЗ, Укрпошта;
• вказує куди повернути гроші: на картку (рефанд через платіжку), на внутрішній рахунок (CSaleUserAccount), обмін на інший товар;
• бачить статус заявки в реальному часі — через кастомні статуси в b_sale_status_lang.

Адмінка менеджера — без зайвих кліків

Окремий розділ на базі \Bitrix\Main\Engine\Controller:

• черга заявок з фільтрами: статус, сума, причина, дата, менеджер. Грід на CAdminList або кастомний React-компонент;
• вся інформація по заявці на одному екрані: замовлення, клієнт, історія листування, фото, документи;
• дії в один клік: схвалити, відхилити, запросити фото, передати на узгодження;
• маршрутизація: повернення понад поріг (налаштовується в b_option) йде керівнику через бізнес-процес модуля bizproc;
• автогенерація акта повернення та поворотної накладної — PDF через mPDF або TCPDF.

Автоматизація — мінімум ручних операцій

• Повернення до налаштовуваного порогу — автосхвалення через обробник події OnSaleOrderSaved.
• Чек повернення 54-ФЗ: виклик \Bitrix\Sale\Cashbox\Manager::addChecks() з типом Check::RETURN_TYPE. Іде на ОФД автоматично.
• Ланцюжок сповіщень: email через CEvent::Send(), SMS через SMS-шлюз, push.
• Після приймання на складі — автоматичне оприбуткування через CCatalogStoreDocsBarcode та оновлення b_catalog_store_product.
• Синхронізація з 1С: документ «Повернення товарів від покупця» створюється автоматично при обміні через \Bitrix\Sale\Exchange.
• Бонусні бали, нараховані за покупку — списання через CSaleUserAccount::UpdateAccount() з від'ємною сумою.
• Агенти обробляють чергу заявок, епілог шаблону підвантажує статуси в особистий кабінет у реальному часі.

Як забезпечити коректну інтеграцію з платіжними системами?

Кожна платіжка — свій API рефанду, свої обмеження за строками, свої коди помилок. Досвід сертифікованих розробників Бітрікс дозволяє обробити всі сценарії:

• ЮKassa — POST /v3/refunds, повний та частковий рефанд. Важливо: рефанд можливий лише протягом 365 днів після платежу. Автоматичний чек повернення через receipt API.
• CloudPayments — метод refund по TransactionId. Рефанд на картку за 1-5 робочих днів. Якщо 3DS-платіж — рефанд може зайняти до 30 днів на стороні банку.
• Тінькофф Еквайринг — Cancel по PaymentId. Якщо оплата в розстрочку — рефанд перераховує графік, і це окрема логіка в обробнику sale.paysystem.handler.
• Apple Pay / Google Pay — рефанд йде через той самий еквайринг, токен прив'язаний до транзакції.
• Накладений платіж — рефанд неможливий через платіжку, потрібні банківські реквізити покупця. Окрема форма в ОК.
• Внутрішній рахунок — CSaleUserAccount::Pay() з зарахуванням суми. Мотивуємо підвищеним коефіцієнтом (x1.1) — 10% бонус за вибір повернення на баланс замість картки.

Гарантуємо коректну обробку кожного коду помилки через кастомні обробники sale.paysystem.handler. Середня економія на ручному рефанді — до 40 000 ₴ на місяць при 100 поверненнях.

Відповідність законодавству

Дотримуємось вимог Закону України "Про захист прав споживачів" (ст. 26.1) та 54-ФЗ:

• ЗоЗПП, ст. 26.1 — дистанційний продаж: відмова в будь-який момент до отримання, 7 днів після. Система контролює строки автоматично та попереджає менеджера про наближення дедлайну.
• 14 днів — повернення товару належної якості. Перевірка: date_insert замовлення + дата доставки з трекінгу + 14 днів. Якщо прострочено — заявка відхиляється з поясненням.
• 54-ФЗ — чек повернення обов'язковий.
• Документообіг — акт повернення, заява покупця, акт приймання — шаблони в системі, заповнюються автоматично з даних замовлення.

Додаткові можливості: аналітика, обмін та зворотна логістика

Кастомний дашборд в адмінці, дані з b_sale_order + кастомна таблиця повернень:

• відсоток повернень за категоріями, брендами, менеджерами, періодами;
• топ причин повернення. Якщо «Не відповідає опису» в топ-3 — проблема в картках товару, а не в клієнтах;
• фінансовий зріз: сума повернень, середній чек повернення, співвідношення рефанд/обмін/баланс;
• алерти: якщо відсоток повернень по конкретному SKU перевищив 15% — сповіщення категорійному менеджеру.

Обмін та заміна

Не кожне повернення — втрачена виручка. Обмін через CSaleOrder::Update з перерахунком кошика:

• заміна на той самий товар іншого розміру/кольору — нова позиція в b_sale_basket, стара — на повернення;
• обмін на інший товар з доплатою — автоматичний розрахунок різниці, доплата через той самий платіжний метод;
• генерація накладної на відправку обмінного товару через API служби доставки.

Зворотна логістика

• СДЕК — POST /v2/orders з type: 2 (повернення). Автоматична заявка на забір, трекінг через webhook.
• Boxberry — API парсельшопів для вибору ПВЗ повернення.
• Укрпошта — формування зворотної накладної через API відправлень.
• Трекінг зворотної посилки в особистому кабінеті — статуси підтягуються через агента на cron.

Процес впровадження

1. Аудит поточного процесу — аналізуємо бізнес-логіку, фіксуємо статуси та інтеграції.
2. Проектування workflow — схема статусів, правила автосхвалення, маршрутизація.
3. Розробка ОК покупця та адмінки — компоненти, гріди, форми, REST-контролери.
4. Інтеграція з платіжками та 1С — налаштування кожного обробника, тест рефандів.
5. Автоматизація 54-ФЗ та сповіщень — підключення ОФД, шаблонів листів, SMS.
6. Інтеграція служб доставки — СДЕК, Boxberry, Укрпошта.
7. Тестування — повний цикл: замовлення → повернення → рефанд → чек → 1С.
8. Навчання співробітників та передача документації.

Що ви отримуєте

Строки впровадження

Чому це окупається за місяць?

Порівняйте: ручна обробка повернення займає 25 хвилин, після автоматизації — 3 хвилини. Це у 8 разів швидше. При 15 поверненнях на день вивільняється ціла ставка менеджера. Економія на зарплаті — значна. Плюс зростання повторних покупок: клієнт, якому легко повернути товар, приходить знову. За нашими підрахунками, впровадження окупається за 3-6 тижнів завдяки економії часу та збільшенню конверсії.

Маємо 7+ років досвіду впровадження рішень на 1С-Бітрікс та понад 120 успішних проектів. Наші клієнти отримують прозорий процес повернень без рутини. Замовте налаштування повернень під ключ у вашому Бітріксі. Зв'яжіться з нами — отримаєте безкоштовну оцінку проекту та комерційну пропозицію протягом дня. Зателефонуйте або напишіть, щоб обговорити деталі вашого бізнесу.