Послуги з налаштування повернень товарів на 1С-Бітрікс

Управління поверненнями товарів на 1С-Бітрікс

Типова картина: менеджер відкриває замовлення в /bitrix/admin/sale_order_view.php, вручну змінює статус, дзвонить на склад, потім лізе в 1С формувати документ «Повернення товарів від покупця». На одне повернення — 20-30 хвилин. При 15 поверненнях на день одна людина зайнята тільки цим. Ми автоматизуємо цикл повністю: від кнопки «Оформити повернення» в особистому кабінеті до проведення в 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

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

• Повернення до настроюваного порогу (наприклад, 3000 ₴) — автосхвалення через обробник події 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% бонус за вибір повернення на баланс замість картки

Відповідність законодавству — без варіантів

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

Аналітика повернень — дані для прийняття рішень

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

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

Обмін і заміна — зберігаємо продаж

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

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

Зворотна логістика — інтеграції

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

Терміни впровадження

Окупність: обробка повернення з 25 хвилин до 3 хвилин. При 15 поверненнях на день — це вивільнення цілого менеджера. Плюс зростання повторних покупок: клієнт, якому легко повернути товар, приходить знову.