Частичный возврат на 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' — успешный возврат

ЮКасса:

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 (в ЮКасса)
• В чек включаются только возвращаемые позиции с возвращаемыми суммами
• Сумма позиций в чеке должна точно совпадать с суммой возврата

// Пример чека возврата для ЮКасса
$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-ФЗ
• Тестирование на песочнице и боевом контуре
• Документация и обучение менеджеров работе с интерфейсом
• Гарантия на код и поддержка после внедрения

Сравнение стандартного и кастомного решения

Сроки

Сроки уточняются после анализа вашего текущего решения. Мы оценим проект бесплатно. Для точного расчёта сроков и стоимости закажите консультацию — мы бесплатно проанализируем вашу текущую конфигурацию и подготовим предложение.

Как настроить возврат товаров на 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 млн рублей в год. Плюс рост повторных покупок: клиент, которому легко вернуть товар, приходит снова.

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