Автоматизація повернень: наскрізна інтеграція 1С та Бітрікс

Як автоматизувати повернення між 1С та Бітрікс: наскрізна інтеграція

Ми розробляємо та інтегруємо системи обробки повернень, які автоматизують взаємодію між Бітріксом і 1С. Коли покупець оформлює повернення на сайті, у бек-офісі потрібно створити кілька пов'язаних документів: сторнування реалізації, акт про розбіжність, коригувальний рахунок-фактуру. Якщо Бітрікс і 1С працюють незалежно — все це робиться вручну, а ймовірність розбіжностей залишків і взаєморозрахунків зростає з кожним тижнем, впливаючи на прибутковість бізнесу.

Автоматизація пришвидшує обробку повернень у 10 разів порівняно з ручним уведенням даних — це підтверджено досвідом наших клієнтів. Наша інтеграція зменшує кількість помилок у 3 рази порівняно зі стандартними модулями. Вартість базової інтеграції починається від 1500 $, а повна комплексна реалізація з синхронізацією залишків у реальному часі — від 4000 $.

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

Чому варто автоматизувати повернення? (H3 question)

Автоматизація повернень дозволяє уникнути ручних помилок, прискорити обробку та зменшити навантаження на бухгалтерію. Це особливо важливо для компаній з високим обсягом повернень.

Як влаштоване повернення в Бітрікс

Повернення в Бітрікс — об'єкт класу \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?

Використовуйте подію 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 після проведення повернення з параметрами підтвердження
// Далі виконується оновлення залишків

У 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 тижнів.

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

• Детальний аналіз вашої конфігурації 1С та Бітрікс
• Проєктування архітектури обміну (XML-схема, черги, вебхуки)
• Розробка та налаштування всіх компонентів інтеграції
• Тестування на типових і нештатних сценаріях
• Документація рішення та навчання вашої команди
• Технічна підтримка 30 днів після запуску

Гарантії та підтримка

Ми даємо гарантію на виконану роботу терміном на 12 місяців. Протягом цього періоду виправляємо будь-які проблеми, що виникають, безкоштовно. Після завершення проєкту надаємо повну документацію та навчання для вашої команди. Технічна підтримка доступна протягом 30 днів після запуску — ми допоможемо усунути будь-які питання та консультації.

Переваги нашого підходу

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

Контакти та наступні кроки

Якщо ваша компанія зіткнулася з описаною проблемою, зв'яжіться з нами для безкоштовної консультації. Проведемо аналіз вашої системи та запропонуємо оптимальне рішення. Оцінимо ваш проєкт безкоштовно протягом 2 робочих днів. Вартість проєкту під ключ — від 1500 $, точний кошторис надаємо після аналізу.

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