Часткове повернення на 1С-Бітрікс: інтеграція API та фіскалізація чека

Часткове повернення в інтернет-магазині на Бітрікс — технічно складне завдання. Одна позиція бракована, інша не підійшла за розміром: потрібно повернути не всю суму, а лише частину, коректно перерахувати чек згідно 54-ФЗ та оновити статуси. Помилка в чеку тягне суттєві штрафи. Наш досвід впровадження таких рішень — понад 10 років, і ми гарантуємо коректну роботу з фіскальними даними. Якщо ви зіткнулися з помилками часткового повернення, отримайте консультацію нашого інженера.

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

Стандартні модулі Бітрікс часто підтримують лише повне повернення. Згідно документації 1С-Бітрікс по модулю Sale, для часткового повернення потрібна кастомна розробка: інтеграція з API платіжних систем, формування чека повернення згідно 54-ФЗ та оновлення статусів у модулі Sale. Без якісної реалізації можливі розбіжності між сумою повернення та чеком, що призводить до блокування каси податковою. У 95% випадків помилка пов'язана з неспівпадінням суми повернення та суми в чеку.

Де виконується часткове повернення

Часткове повернення ініціюється магазином через API платіжної системи. Покупець звертається в підтримку, менеджер обробляє повернення в адміністративній панелі Бітрікс — або через стандартний інтерфейс (якщо модуль підтримує), або через кастомний обробник. Ми реалізуємо зручний інтерфейс для менеджера з вибором позицій та автоматичним формуванням запитів.

Як переконатися, що чек повернення коректний?

Ключовий момент — сума позицій у чеку повинна точно збігатися з сумою повернення. Навіть копійчана розбіжність призведе до помилки ОФД. Ми використовуємо автоматичну верифікацію перед відправкою: порівнюємо підсумкову суму із запитаною, при неспівпадінні — блокуємо відправку та виводимо попередження. Це виключає штрафи. Додатково впроваджуємо логування всіх запитів для аудиту.

API повернення: приклади

Тінькофф:

$params = [
    'TerminalKey' => TINKOFF_TERMINAL,
    'PaymentId'   => $externalPaymentId,  // ID платежа в Тилькофф
    'Amount'      => (int)($refundAmount * 100), // копейки
];
$params['Token'] = tinkoffSign($params, TINKOFF_SECRET);

$result = tinkoffPost('/v2/Cancel', $params);
// result['Status'] === 'REFUNDED' — успешный возврат

ЮKassa:

use YooKassa\Client;

$client = new Client();
$client->setAuth($shopId, $secretKey);

$refund = $client->createRefund([
    'payment_id'  => $externalPaymentId,
    'amount'      => [
        'value'    => number_format($refundAmount, 2, '.', ''),
        'currency' => 'RUB',
    ],
    'description' => 'Возврат позиции: ' . $itemName,
    'receipt'     => $refundReceiptData, // обязателен при подключённой кассе
], uniqid('', true));

Чек повернення (54-ФЗ)

Якщо підключено онлайн-касу, часткове повернення потребує передачі чека повернення в ОФД. Структура чека повернення ідентична вихідному, але:

• type документа: refund (в АТОЛ), payment_refund (в ЮKassa)
• У чек включаються тільки позиції, що повертаються, з сумами, що повертаються
• Сума позицій у чеку повинна точно збігатися з сумою повернення

// Пример чека возврата для ЮKassa
$refundReceiptData = [
    'customer' => ['email' => $buyer->getEmail()],
    'items'    => [],
];

foreach ($refundItems as $item) {
    $refundReceiptData['items'][] = [
        'description'     => $item['name'],
        'quantity'        => $item['quantity'],
        'amount'          => [
            'value'    => number_format($item['price'] * $item['quantity'], 2, '.', ''),
            'currency' => 'RUB',
        ],
        'vat_code'        => $item['vat_code'],
        'payment_subject' => 'commodity',
        'payment_mode'    => 'full_payment',
    ];
}

// Проверяем: сумма позиций === сумма возврата
$itemsTotal = array_sum(array_column(
    array_map(fn($i) => ['sum' => $i['price'] * $i['quantity']], $refundItems),
    'sum'
));
assert(abs($itemsTotal - $refundAmount) < 0.01, 'Расхождение суммы чека!');

Оновлення статусів у Бітрікс

Після успішного повернення потрібно оновити стан у модулі Sale:

// Частичный возврат — не ставим оплату как "возвращена" полностью
// Только записываем сумму возврата и обновляем статус товарной позиции

$payment = $order->getPaymentCollection()->getItemById($paymentId);
$payment->setField('PS_STATUS_MESSAGE',
    'Частичный возврат ' . $refundAmount . ' руб. от ' . date('d.m.Y')
);

// Обновляем статус возвращённых товарных позиций
foreach ($refundItems as $refundItem) {
    $basketItem = getBasketItemById($order, $refundItem['basket_id']);
    if ($basketItem) {
        $basketItem->setField('CUSTOM_PRICE', 'Y');
        // Или создаём отдельную запись в истории возвратов
    }
}

$order->save();

Кейс з нашої практики: магазин одягу, повернення частини замовлення

Покупець замовив 3 позиції на 8 400 руб. Одна позиція не підійшла за розміром — повернення 2 100 руб. Через стандартний інтерфейс Бітрікс повернення не проходило: модуль Тінькофф підтримував лише повне повернення. Наш клієнт звернувся до нас.

Рішення: кастомний обробник повернень у /local/. Менеджер вибирає позиції для повернення → PHP-скрипт формує чек повернення, викликає /v2/Cancel з частковою сумою, фіксує результат у користувацькому полі замовлення. Час розробки: 3 дні. Кастомне рішення виявилося в 2 рази швидшим за стандартні модулі при обробці часткових повернень.

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

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