Сквозная интеграция возвратов между 1С и Битрикс: полный обмен

Интеграция возвратов с 1С 1С-Битрикс

Мы разрабатываем и интегрируем системы обработки возвратов, которые автоматизируют взаимодействие между Битриксом и 1С. Когда покупатель оформляет возврат на сайте, в бэк-офисе нужно создать несколько связанных документов: сторнирование реализации, акт о расхождении, корректировочный счёт-фактура. Если Битрикс и 1С работают независимо — всё это делается вручную, а вероятность расхождений остатков и взаиморасчётов растёт с каждой неделей, влияя на прибыльность бизнеса.

Мы реализуем интеграцию возвратов как отдельный контур внутри обмена 1С–Битрикс, потому что стандартный модуль sale обменивается заказами, а не корректировочными документами. Их нужно описывать отдельно и явно. За более чем 10 лет опыта мы реализовали сотни таких интеграций для магазинов разного масштаба.

Как устроен возврат в Битрикс

Возврат в Битрикс — объект класса \Bitrix\Sale\Payment\PaymentReturn в контексте платежа или \Bitrix\Sale\Shipment\ShipmentReturn в контексте отгрузки. С точки зрения БД это записи в таблицах:

• b_sale_order_return — заявка на возврат
• b_sale_order_return_item — позиции возврата
• b_sale_order_return_shipment — связь с отгрузкой

Статусы возврата (RETURN_STATUS): NEW, PROCESSED, COMPLETED, REJECTED. Триггером для передачи в 1С должен служить переход в COMPLETED — до этого момента данные могут меняться.

Схема обмена

Стандартный модуль bitrix.1c передаёт заказы через sale.order в CommerceML 2. Возвраты в CommerceML не описаны — это кастомный узел, который нужно добавить в схему самостоятельно.

Битрикс: возврат переходит в COMPLETED
  → Обработчик события OnSaleReturnComplete
    → Формирование XML-узла <Возврат>
      → Запись в очередь обмена (b_agent / кастомная таблица)
        → Следующий сеанс обмена с 1С
          → 1С создаёт документ "Возврат товаров от покупателя"
            → Подтверждение из 1С → статус возврата обновляется

Используйте событие OnSaleReturnComplete из модуля sale:

\Bitrix\Main\EventManager::getInstance()->addEventHandler(
    'sale',
    'OnSaleReturnComplete',
    function (\Bitrix\Main\Event $event) {
        $return = $event->getParameter('ENTITY');
        ReturnExchangeQueue::push($return->getId());
    }
);

XML-структура для передачи в 1С

1С работает с CommerceML, но возвраты удобнее передавать отдельным узлом внутри <КоммерческаяИнформация>:

<Возврат>
  <Ид>RETURN-{return_id}</Ид>
  <НомерДокумента>R-{return_id}</НомерДокумента>
  <Дата>{date}</Дата>
  <ЗаказИд>{order_id}</ЗаказИд>
  <Контрагент>
    <Ид>{user_id}</Ид>
    <Наименование>{user_name}</Наименование>
  </Контрагент>
  <Товары>
    <Товар>
      <Ид>{product_id}</Ид>
      <Наименование>{product_name}</Наименование>
      <Количество>{qty}</Количество>
      <ЦенаЗаЕдиницу>{price}</ЦенаЗаЕдиницу>
      <Сумма>{sum}</Сумма>
    </Товар>
  </Товары>
  <СуммаВозврата>{total}</СуммаВозврата>
  <Причина>{reason}</Причина>
</Возврат>

На стороне 1С в конфигурации описывается обработчик, который читает этот узел и создаёт документ «Возврат товаров от покупателя» с правильной привязкой к исходной реализации по ЗаказИд.

Синхронизация остатков после возврата

После успешного проведения возврата в 1С остатки обновляются. Важно, чтобы Битрикс получил этот сигнал и обновил b_catalog_store_product. Стандартный обмен остатками (offers.xml) это сделает при следующем сеансе, но если сеансы редкие — нужен отдельный запрос:

// 1С вызывает URL после проведения возврата
// /bitrix/admin/1c_exchange.php?type=catalog&mode=checkauth&return_confirm=Y&return_id=123

$returnId = (int)$_GET['return_id'];
ReturnSyncService::updateStocksFromReturn($returnId);

В updateStocksFromReturn — прямое обновление b_catalog_store_product через \Bitrix\Catalog\StoreProductTable с вызовом \Bitrix\Catalog\StoreBatchService при необходимости пересчёта партий.

Обратная передача статуса

После создания документа в 1С необходимо вернуть в Битрикс подтверждение:

Обновление статуса на стороне Битрикс:

$return = \Bitrix\Sale\OrderReturn::load($returnId);
$return->setField('STATUS', 'COMPLETED');
$return->setField('COMMENTS', '1С: документ #' . $doc1cId);
$return->save();

Кейс: оптовый поставщик, 150+ возвратов в месяц

Клиент — дистрибьютор строительной химии. Возвраты приходили двумя путями: через ЛК дилера на сайте и напрямую от логистики. Проблема: бухгалтерия 1С не видела возвраты из сайта, проводила документы вручную с опозданием 3–5 дней. Это вело к неверным остаткам на складах Битрикс и конфликтам при последующих заказах.

Реализовали следующие шаги:

1. Событие OnSaleReturnComplete пишет возврат в очередь local_1c_return_queue.
2. Агент (каждые 10 минут) формирует XML и передаёт в конечную точку 1С через HTTP-запрос к стандартному обработчику обмена.
3. 1С проводит документ, обновляет остатки, шлёт подтверждение на /api/1c/return-confirm/{returnId}.
4. Вебхук в Битрикс обновляет статус возврата и переоценивает b_catalog_store_product для затронутых SKU.

Состав работ

• Анализ конфигурации 1С: тип документа «Возврат товаров от покупателя», поля привязки к заказу
• Разработка XML-схемы и PHP-генератора для Битрикс
• Обработчик события OnSaleReturnComplete, очередь обмена
• Вебхук-эндпоинт для подтверждения из 1С
• Обновление остатков в Битрикс после подтверждения
• Тестирование на нескольких сценариях: частичный возврат, возврат без отгрузки, возврат с несколькими складами

Сроки: базовая интеграция (передача возвратов, подтверждение) — 3–4 недели. С синхронизацией остатков в реальном времени и обработкой нештатных сценариев — 6–8 недель.

Наш подход к решению

Каждая задача требует индивидуального анализа и тщательного планирования. Мы не используем шаблонные решения — каждый проект адаптируется под конкретные требования и существующую инфраструктуру. Наша команда имеет опыт работы с проектами разного масштаба: от небольших магазинов до высоконагруженных платформ с миллионами операций в день.

Гарантии и поддержка

Мы даём гарантию на выполненную работу сроком на 12 месяцев. В течение этого периода исправляем любые возникающие проблемы бесплатно. После завершения проекта предоставляем полную документацию и обучение для вашей команды. Техническая поддержка доступна в течение 30 дней после запуска — мы поможем устранить любые вопросы и консультации.

Преимущества нашего подхода

Мы обеспечиваем комплексное решение, а не отдельные исправления. Каждый проект включает документирование, тестирование и обучение команды. Нашим клиентам нравится, что мы не просто выполняем работу, но и объясняем каждый шаг процесса, давая возможность вашей команде в будущем самостоятельно поддерживать систему. Со своей стороны, мы гарантируем помощь в течение года после завершения проекта.

Контакты и следующие шаги

Если ваша компания столкнулась с описанной проблемой, свяжитесь с нами для бесплатной консультации. Проведём анализ вашей системы и предложим оптимальное решение. Стоимость проекта зависит от сложности и объёма работ, но для типовых решений мы всегда предоставляем точную смету на основе предварительного анализа требований.

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

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