Інтеграція повернень з онлайн-касою 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-ФЗ. Зв'яжіться з нами для безкоштовного аудиту вашої поточної схеми.