Як автоматизувати повернення між 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, але повернення зручніше передавати окремим вузлом усередині <КомерційнаІнформація>:
Приклад XML для повернення
<Повернення> <Ід>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С необхідно повернути в Бітрікс підтвердження:
| Ситуація | Статус у Бітрікс |
|---|---|
| Документ проведений в 1С | COMPLETED, прапорець 1C_SYNCED = Y |
| Позицій немає в наявності для сторно | ERROR_1C, сповіщення менеджеру |
| Повернення відхилене в 1С | REJECTED, коментар з 1С |
Оновлення статусу на стороні Бітрікс:
$return = \Bitrix\Sale\OrderReturn::load($returnId); $return->setField('STATUS', 'COMPLETED'); $return->setField('COMMENTS', '1С: документ #' . $doc1cId); $return->save(); Кейс: оптовий постачальник, 150+ повернень на місяць
Клієнт — дистриб'ютор будівельної хімії. Повернення надходили двома шляхами: через ОК дилера на сайті та безпосередньо від логістики. Проблема: бухгалтерія 1С не бачила повернення з сайту, проводила документи вручну із запізненням 3–5 днів. Це вело до невірних залишків на складах Бітрікс і конфліктів при подальших замовленнях.
Реалізували наступні кроки:
- Подія
OnSaleReturnCompleteзаписує повернення в чергуlocal_1c_return_queue. - Агент (кожні 10 хвилин) формує XML і передає в кінцеву точку 1С через HTTP-запит до стандартного обробника обміну.
- 1С проводить документ, оновлює залишки, надсилає підтвердження на
/api/1c/return-confirm/{returnId}. - Вебхук у Бітрікс оновлює статус повернення та переоцінює
b_catalog_store_productдля порушених SKU.
| Метрика | До | Після |
|---|---|---|
| Затримка відображення повернення в 1С | 3–5 днів | < 15 хвилин |
| Розбіжність залишків (щотижнева звірка) | 8–12 позицій | 0–1 позиція |
| Ручних операцій в 1С | ~150/міс | < 5/міс (винятки) |
Склад робіт
- Аналіз конфігурації 1С: тип документа «Повернення товарів від покупця», поля прив'язування до замовлення
- Розробка XML-схеми та PHP-генератора для Бітрікс
- Обробник події
OnSaleReturnComplete, черга обміну - Вебхук-ендпоінт для підтвердження з 1С
- Оновлення залишків у Бітрікс після підтвердження
- Тестування на кількох сценаріях: часткове повернення, повернення без відвантаження, повернення з кількома складами
Терміни: базова інтеграція (передача повернень, підтвердження) — 3–4 тижні. З синхронізацією залишків у реальному часі та обробкою нештатних сценаріїв — 6–8 тижнів.
Що входить в роботу
- Детальний аналіз вашої конфігурації 1С та Бітрікс
- Проєктування архітектури обміну (XML-схема, черги, вебхуки)
- Розробка та налаштування всіх компонентів інтеграції
- Тестування на типових і нештатних сценаріях
- Документація рішення та навчання вашої команди
- Технічна підтримка 30 днів після запуску
Гарантії та підтримка
Ми даємо гарантію на виконану роботу терміном на 12 місяців. Протягом цього періоду виправляємо будь-які проблеми, що виникають, безкоштовно. Після завершення проєкту надаємо повну документацію та навчання для вашої команди. Технічна підтримка доступна протягом 30 днів після запуску — ми допоможемо усунути будь-які питання та консультації.
Переваги нашого підходу
Ми забезпечуємо комплексне рішення, а не окремі виправлення. Кожен проєкт включає документування, тестування та навчання команди. Нашим клієнтам подобається, що ми не просто виконуємо роботу, але й пояснюємо кожен крок процесу, даючи можливість вашій команді в майбутньому самостійно підтримувати систему. Зі свого боку, ми гарантуємо допомогу протягом року після завершення проєкту.
Контакти та наступні кроки
Якщо ваша компанія зіткнулася з описаною проблемою, зв'яжіться з нами для безкоштовної консультації. Проведемо аналіз вашої системи та запропонуємо оптимальне рішення. Оцінимо ваш проєкт безкоштовно протягом 2 робочих днів. Вартість проєкту під ключ — від 1500 $, точний кошторис надаємо після аналізу.