Интеграция возвратов с онлайн-кассой 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-ФЗ. Свяжитесь с нами для бесплатного аудита вашей текущей схемы.

Как настроить возврат товаров на 1С-Битрикс?

Типичная картина: менеджер открывает заказ в /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.

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

• Возврат до настраиваемого порога (например, 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% бонус за выбор возврата на баланс вместо карты.

Гарантируем корректную обработку каждого кода ошибки через кастомные обработчики sale.paysystem.handler.

Соответствие законодательству — без вариантов

• ЗоЗПП, ст. 26.1 — дистанционная продажа: отказ в любой момент до получения, 7 дней после. Система контролирует сроки автоматически и предупреждает менеджера о приближении дедлайна. Подробнее о законе — статья 26.1 ЗоЗПП.
• 14 дней — возврат товара надлежащего качества. Проверка: date_insert заказа + дата доставки из трекинга + 14 дней. Если просрочено — заявка отклоняется с пояснением.
• 54-ФЗ — чек возврата обязателен. Федеральный закон №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. Обучение сотрудников и передача документации.

Результаты внедрения

Чек-лист проверки перед запуском

• Проверен рефанд через каждую платёжку (частичный и полный).
• Тест 54-ФЗ: чек возврата корректен, уходит в ОФД.
• Обмен с 1С: документ «Возврат товаров от покупателя» создаётся без ошибок.
• ЛК покупателя: все поля, загрузка фото, выбор способа возврата.
• Автоодобрение до порога срабатывает.
• Уведомления (email/SMS/push) приходят.
• Остатки после приёмки обновляются.
• Аналитика считает метрики корректно.

Сроки внедрения

Почему это окупается за месяц?

Сравните: ручная обработка возврата занимает 25 минут, после автоматизации — 3 минуты. Это в 8 раз быстрее. При 15 возвратах в день высвобождается целая ставка менеджера. Экономия на зарплате — до 1.2 млн рублей в год. Плюс рост повторных покупок: клиент, которому легко вернуть товар, приходит снова.

Закажите настройку возвратов под ключ в вашем Битриксе. Свяжитесь с нами — получите бесплатную оценку проекта и коммерческое предложение в течение дня.