Інтеграція повернень з онлайн-касою 1С-Бітрікс

За Федеральним законом №54-ФЗ при поверненні грошей покупцеві каса зобов'язана пробити чек з ознакою розрахунку «Повернення приходу». Ми реалізуємо інтеграцію повернень з онлайн-касою в 1С-Бітрікс під ключ: аналізуємо поточну схему, доопрацьовуємо обробники, тестуємо всі сценарії та передаємо документацію. Без коректної фіскалізації повернень компанія ризикує отримати штраф до 50 % суми кожної операції. За статистикою, 70 % помилок фіскалізації повернень пов'язано з неправильною прив'язкою до чека приходу — ми усуваємо такі проблеми на етапі аудиту. При інтенсивному потоці повернень потенційні штрафи можуть сягати значних сум, тому автоматизація окупається за лічені тижні. Наш досвід — 50+ проектів з інтеграції кас з Бітрікс, у тому числі для великих інтернет-магазинів з тисячею повернень на день. Отримайте консультацію щодо вашої конфігурації — ми оцінимо проект і назвемо терміни.

Як Бітрікс взаємодіє з касою

Модуль sale.cashbox (bitrix/modules/sale/cashbox/) відповідає за фіскалізацію. Чеки надсилаються через обробники (handlers), що успадковують від \Bitrix\Sale\Cashbox\CashboxPaymaster або \Bitrix\Sale\Cashbox\CashboxAtol. Стандартні обробники: Атол Онлайн, CloudKassir, OrangeData, ЮKassa та інші.

При оплаті замовлення Бітрікс викликає \Bitrix\Sale\Cashbox\Manager::sendCheck() з типом чека CHECK_TYPE_SELL (прихід). При поверненні — CHECK_TYPE_SELL_RETURN (повернення приходу).

Таблиці: b_sale_cashbox_check — історія чеків, b_sale_cashbox — налаштовані каси.

Як формується чек повернення?

Чек повернення Бітрікс створює автоматично при виконанні двох умов:

1. Повернення переходить у статус COMPLETED
2. До початкового платежу прив'язана каса і вже є підтверджений фіскальний чек приходу

Код, який це запускає — \Bitrix\Sale\Cashbox\Manager::addByReturn():

// Внутри обработчика события OnSaleReturnComplete
\Bitrix\Sale\Cashbox\Manager::addByReturn($return);

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

Що йде в чек повернення?

Позиції чека формуються з b_sale_order_return_item. Кожна позиція містить:

• Найменування товару (з b_iblock_element.NAME через JOIN на b_sale_basket.PRODUCT_ID)
• Кількість
• Ціну
• Ставку ПДВ
• Ознаку предмета розрахунку (товар/послуга/робота) — береться з налаштувань позиції замовлення

Якщо в початковому замовленні ПДВ не вказано або вказано некоректно — у чеку повернення буде помилка. Це часта проблема при міграції з Бітрікс на нову касову схему.

Автоматична фіскалізація через штатний модуль sale.cashbox у 5 разів надійніша за ручне пробиття чеків через особистий кабінет оператора — виключені людські помилки та затримки.

Які типові проблеми виникають?

Чек повернення не надсилається. Причина: повернення створено не через \Bitrix\Sale\OrderReturn, а напряму в БД або через неофіційний механізм — подія OnSaleReturnComplete не спрацьовує. Рішення: завжди використовуйте ORM-методи.

Сума повернення перевищує суму приходу. Касовий оператор відхиляє чек, якщо сума повернення більша, ніж у початковому чеку приходу. Буває при часткових поверненнях кількох платежів за одне замовлення — кожен чек повернення має бути прив'язаний до конкретного чека приходу через PARENT_CHECK_ID в b_sale_cashbox_check.

Дублювання чека при повторному запиті. При збої мережі Бітрікс може відправити запит двічі. У Атол Онлайн є параметр external_id — унікальний ідентифікатор чека на вашому боці. Використовуйте його, щоб оператор міг визначити дублікат.

Часткове повернення кількох позицій з одного замовлення. Чек має містити лише повернені позиції з правильними кількостями. Стандартний Manager::addByReturn() це забезпечує, якщо b_sale_order_return_item заповнена коректно.

Як тестувати фіскалізацію повернень?

Усі касові оператори надають тестове середовище. Атол Онлайн — тестовий URL https://testonline.atol.ru/possystem/v5/. OrangeData — тестові ключі та сертифікати.

Перевірочний список перед запуском у прод:

Налаштування сповіщень про помилки фіскалізації

Якщо чек повернення не пройшов — касовий оператор поверне помилку. Бітрікс збереже її в полі ERROR таблиці b_sale_cashbox_check, але за замовчуванням менеджер про це не дізнається. Налаштуйте агент:

// Агент: кожні 30 хвилин перевіряє необроблені помилки
$checks = \Bitrix\Sale\Cashbox\CheckManager::getList([
    'filter' => [
        'STATUS'  => \Bitrix\Sale\Cashbox\Check::CHECK_STATUS_ERROR,
        '>=DATE_CREATE' => new \Bitrix\Main\Type\DateTime('-1 hour'),
    ],
]);

foreach ($checks as $check) {
    if ($check['TYPE'] === \Bitrix\Sale\Cashbox\SellReturnCheck::TYPE) {
        NotificationService::alertAdmin(
            'Помилка чека повернення #' . $check['ID'] . ': ' . $check['ERROR']
        );
    }
}

Чому ПДВ часто викликає помилки в чеках повернення?

Якщо в замовленні товар з ПДВ 20%, а в інфоблоці ставка не вказана — Бітрікс підставляє значення за замовчуванням 0%. Касовий оператор може відхилити чек повернення, оскільки ставка не відповідає початковому чеку. Ми перевіряємо відповідність ставок на етапі аудиту.

Як ми налаштовуємо повернення за 5 кроків?

1. Аудит поточної касової схеми та версії модуля sale.cashbox.
2. Налаштування обробника каси (Атол, OrangeData, CloudKassir та ін.) на середовище повернень.
3. Реалізація кастомних сценаріїв (якщо повернення створюється зовнішнім скриптом).
4. Тестування в тестовому контурі оператора всіх сценаріїв з чек-листа.
5. Деплой, налаштування агента моніторингу помилок та передача документації.

Поширені помилки та рішення

Терміни

Якщо каса вже налаштована для чеків приходу — налаштування повернень займає 1–2 тижні. Якщо каса налаштовується з нуля — 3–5 тижнів, включаючи тестування у всіх сценаріях. Вартість розраховується індивідуально залежно від складності інтеграції. При тиражі в сотні повернень на день економія на штрафах може бути суттєвою. Замовте інтеграцію повернень під ключ з гарантією відповідності 54-ФЗ. Зв'яжіться з нами для безкоштовного аудиту вашої поточної схеми.

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