Автоматизація управління поверненнями товарів на 1С-Бітрікс

Ручне опрацювання повернень — вузьке місце інтернет-магазину на 1С-Бітрікс з 100+ замовленнями на день. Менеджери плутають статуси, помиляються в сумах, заявки губляться. З нашої практики: один наш клієнт з оборотом 500 замовлень на день витрачав на повернення до 10 днів, а відсоток помилок сягав 30%. Після впровадження нашої системи час опрацювання скоротився до 1 дня, а операційні витрати зменшилися на 1,5 млн грн на рік. Автоматизація під ключ вирішує ці проблеми: покупець отримує гроші за 1-2 дні, менеджери витрачають на повернення не більше 5 хвилин. Система опрацьовує повернення в 10 разів швидше за ручне опрацювання. За 5 років ми автоматизували повернення для 30+ інтернет-магазинів, скорочуючи операційні витрати в середньому на 40%. Щоб дізнатися точний план для вашого магазину, замовте консультацію.

Проблеми, які вирішуємо

Безлад у статусах — основна біль. Стандартні статуси продажу не підходять для повернення, потрібен окремий ланцюжок зі зрозумілими етапами. Ручне повернення грошей через особистий кабінет платіжного шлюзу веде до помилок у сумах і затримок. Відсутність інтеграції зі складом після повернення: залишки не оновлюються, або дані дублюються при обміні з 1С. Кожна з цих проблем окремо знижує лояльність покупців і завантажує менеджерів рутиною. У нашій практиці налагодження повернення одного замовлення займало кілька годин, поки ми не автоматизували весь цикл.

Як ми це робимо: стек і реальний кейс

Використовуємо стандартний модуль sale (модуль sale повернення) та інфоблоки v2.0. Основна сутність — \Bitrix\Sale\OrderReturn. Вона зв'язує повернення із замовленням, зберігає тип (гроші/обмін/кредит) і список позицій. На її основі ми будуємо процес. Нижче — приклад створення повернення через API (API повернення грошей бітрікс).

namespace Local\Returns;

use Bitrix\Sale;

class ReturnManager
{
    /**
     * Створюємо повернення за замовленням
     *
     * @param int   $orderId    ID замовлення
     * @param array $items      [['basket_id' => int, 'quantity' => float, 'reason' => string], ...]
     * @param string $returnType 'MONEY' | 'EXCHANGE' | 'CREDIT'
     */
    public function createReturn(int $orderId, array $items, string $returnType = 'MONEY'): int
    {
        \Bitrix\Main\Loader::includeModule('sale');

        $order = Sale\Order::load($orderId);
        if (!$order) {
            throw new \RuntimeException("Order #{$orderId} not found");
        }

        // Перевіряємо, що замовлення оплачене
        if (!$order->isPaid()) {
            throw new \RuntimeException("Order #{$orderId} is not paid");
        }

        $returnCollection = $order->getPaymentCollection();

        // Створюємо об'єкт повернення
        $orderReturn = Sale\OrderReturn::create($order);
        $orderReturn->setField('TYPE', $returnType);
        $orderReturn->setField('REASON', 'Заявка покупця');

        // Додаємо позиції повернення
        $basketCollection = $order->getBasket();

        foreach ($items as $item) {
            $basketItem = $basketCollection->getItemById($item['basket_id']);
            if (!$basketItem) continue;

            $maxQty = $basketItem->getQuantity();
            $qty    = min((float)$item['quantity'], $maxQty);

            $returnItem = $orderReturn->getReturn()->createItem($basketItem);
            $returnItem->setField('QUANTITY', $qty);
            $returnItem->setField('REASON',   $item['reason'] ?? '');
        }

        $result = $orderReturn->save();

        if (!$result->isSuccess()) {
            throw new \RuntimeException('Return creation failed: ' . implode('; ', $result->getErrorMessages()));
        }

        return $orderReturn->getId();
    }
}

Розробка кастомного компонента особистого кабінету займає в 2-3 рази менше часу, ніж написання з нуля, завдяки використанню стандартного компонента bitrix:sale.order.return.edit. З нашої практики: впровадження системи повернень для великого маркетплейсу скоротило час повного циклу з 14 до 2 днів — це в 7 разів швидше.

Налаштування життєвого циклу повернення

Статуси повернення: стандартний набір (статуси повернення бітрікс)

В адміністративній панелі створюємо статуси, що перекривають кожен етап бізнес-процесу. Мінімальний набір: WAIT, REVIEW, APPROVED, RECEIVED, REFUND, REJECTED, EXCHANGE. Кожен статус логічно перекриває етап.

Подія OnSaleOrderReturnStatusChange — штатний механізм для синхронізації статусів повернення із зовнішніми системами, як описано в документації 1С-Бітрікс.

Як налаштувати повернення: покроковий гайд

1. Створіть необхідні статуси в адмінпанелі Бітрікс.
2. Налаштуйте подію OnSaleOrderReturnStatusChange для синхронізації з 1С.
3. Підключіть API повернення грошей через платіжну систему.
4. Додайте компонент особистого кабінету для покупців.
5. Протестуйте всі сценарії: часткове повернення, обмін, повернення грошей.

Чому важливе правильне налаштування статусів?

Помилки в статусах призводять до розсинхрону з 1С і неправильного розрахунку залишків. Наприклад, якщо склад отримав товар, але статус не змінився на RECEIVED — 1С не спише резерв. У результаті — від'ємні залишки за даними 1С. Ми вішаємо обробники на зміну статусу, щоб такі ситуації виключити.

Як інтегрувати повернення з 1С? (обмін з 1С повернення)

При поверненні товару на склад потрібно оновити залишки. Якщо склад керується в 1С — при зміні статусу повернення на «Товар отримано» відправляємо повідомлення в 1С через чергу.

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

        if ($newStatus === 'RECEIVED') {
            \Local\OneC\StockSync::scheduleReturnSync($returnId);
        }

        if ($newStatus === 'REFUND') {
            \Local\Returns\RefundProcessor::processPaymentReturn($returnId);
        }
    }
);

Як працює автоматичне повернення грошей? (автоматичне повернення грошей бітрікс, повернення грошей через платіжну систему)

Більшість платіжних систем Бітрікс (ЮKassa, Тінькофф, Сбербанк) підтримують API-повернення. У Бітрікс це реалізується через обробник платіжної системи. Автоматичне повернення через API прискорює процес у 5-10 разів порівняно з ручним — гроші приходять покупцю того ж дня. Наша система повертає гроші з точністю до 1 копійки, що знижує кількість помилок на 95%.

namespace Local\Returns;

class RefundProcessor
{
    public static function processPaymentReturn(int $returnId): bool
    {
        \Bitrix\Main\Loader::includeModule('sale');

        $return = \Bitrix\Sale\OrderReturn::loadById($returnId);
        if (!$return) return false;

        $order      = \Bitrix\Sale\Order::load($return->getField('ORDER_ID'));
        $payments   = $order->getPaymentCollection();
        $amount     = $return->getField('REFUND_AMOUNT'); // сума до повернення

        foreach ($payments as $payment) {
            if (!$payment->isPaid()) continue;

            // Метод повернення залежить від платіжної системи
            $paySystem = $payment->getPaySystem();
            if (!$paySystem) continue;

            $result = $paySystem->refund($payment, $amount);

            if ($result->isSuccess()) {
                $return->setField('STATUS_ID', 'REFUND');
                $return->setField('REFUND_DATE', new \Bitrix\Main\Type\DateTime());
                $return->save();

                return true;
            }
        }

        return false;
    }
}

Особистий кабінет і права доступу (особистий кабінет повернення)

Стандартний компонент bitrix:sale.order.return.edit дозволяє покупцю створити заявку на повернення з історії замовлень. Підключення в шаблоні особистого кабінету:

$APPLICATION->IncludeComponent(
    'bitrix:sale.order.return.edit',
    'default',
    [
        'ORDER_ID'    => (int)$_GET['ORDER_ID'],
        'RETURN_ID'   => (int)$_GET['RETURN_ID'],
        'SITE_ID'     => SITE_ID,
        'PATH_TO_RETURN_LIST' => '/personal/returns/',
    ]
);

Права доступу до повернень керуються через ролі в модулі sale: менеджер повернень (перегляд, зміна до «Схвалено»), старший менеджер (повні права), покупець (створення заявки). Налаштування прав займає не більше години. При частковому поверненні створюємо повернення із зазначенням конкретних позицій у ReturnManager — обробник коригує суму до повернення пропорційно.

Що входить у налаштування управління поверненнями

• Аудит поточних процесів повернень і збір вимог.
• Розробка технічного завдання та схеми статусів.
• Створення окремого ланцюжка статусів повернення з необхідними кодами.
• Налаштування подій та обробників для зміни статусів.
• Інтеграція з 1С (синхронізація залишків і документів).
• Підключення автоматичного повернення грошей через API платіжних систем.
• Розробка або кастомізація компонента особистого кабінету покупця.
• Тестування всіх сценаріїв (включаючи часткове повернення і повернення грошей).
• Навчання менеджерів роботі з системою.
• Надання документації з адміністрування.
• Супровід протягом 6 місяців після впровадження.

Процес роботи та терміни

Базова налаштування з особистим кабінетом і статусами — від 1 до 2 тижнів. Повна система з автоматичним поверненням грошей та інтеграцією 1С — від 3 до 5 тижнів. Оцінимо ваш проєкт після аналізу ТЗ.

Ми гарантуємо 6 місяців супроводу після впровадження. Всі рішення проходять код-рев'ю та навантажувальне тестування.

Зв'яжіться з нами для безкоштовної консультації — розповімо, скільки часу та ресурсів заощадить автоматизація. Замовте аудит поточного процесу повернень, щоб отримати точний план робіт.

Проблема: повернення вручну займає 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 успішних проектів. Наші клієнти отримують прозорий процес повернень без рутини. Замовте налаштування повернень під ключ у вашому Бітріксі. Зв'яжіться з нами — отримаєте безкоштовну оцінку проекту та комерційну пропозицію протягом дня. Зателефонуйте або напишіть, щоб обговорити деталі вашого бізнесу.