RetailCRM хорошо закрывает операционку маркетплейсов, но в связке с сайтом на 1С-Битрикс важно не задвоить логику. Разберём, кто за что отвечает в цепочке Ozon → RetailCRM → Битрикс и как заказы обрабатываются без ручного переноса.
Как устроена связка
В типовой схеме RetailCRM выступает операционным хабом: у неё есть штатная интеграция с Ozon, которая тянет отправления (postings) и отдаёт обратно статусы. Сайт на 1С-Битрикс при этом остаётся источником каталога и остатков, а иногда — и местом, где менеджеры видят все заказы.
Возможны две конфигурации:
- RetailCRM — центр. Заказы Ozon приходят в CRM, там же обрабатываются; в Битрикс уходит только каталог и остатки.
- Битрикс — центр учёта. Заказы из RetailCRM зеркалируются в модуль
saleБитрикса для единой отчётности и обмена с 1С.
Импорт отправлений Ozon
Заказ на Ozon — это отправление (posting). RetailCRM забирает их через Seller API, но при кастомной связке те же данные доступны напрямую:
| Метод Seller API | Что даёт |
|---|---|
/v3/posting/fbs/list | отправления FBS (со склада продавца) |
/v2/posting/fbo/list | отправления FBO (со склада Ozon) |
/v3/posting/fbs/get | детали конкретного отправления |
Каждое отправление содержит номер posting_number, состав (products с offer_id и sku), статус, дедлайны сборки и данные доставки. Именно offer_id связывает строку заказа с товаром каталога Битрикса.
Статусы и их синхронизация
Статусная модель Ozon и статусы RetailCRM/Битрикса — разные словари, их нужно сопоставить картой соответствий. Основные состояния отправления FBS:
awaiting_packaging— ожидает сборки;awaiting_deliver— собран, ждёт передачи в доставку;delivering— в пути;delivered— доставлен;cancelled— отменён.
RetailCRM подтягивает эти статусы автоматически, а обратные действия (сборка, передача) отдаёт в Ozon. При зеркалировании в Битрикс важно, чтобы статусы заказа в модуле sale обновлялись из карты соответствий, а не задавались вручную.
Остатки и каталог
Чтобы заказы не приходили на отсутствующий товар, остатки должны обновляться из единого источника. Обычно это учётная система (1С или МойСклад), которая через Битрикс или напрямую пишет остатки в Ozon методом /v2/products/stocks (для FBS) и в RetailCRM.
- 1С отдаёт остатки на сайт по CommerceML (обмен через модуль каталога).
- Битрикс либо RetailCRM транслирует их в Ozon по расписанию.
- Продажи с маркетплейса уменьшают доступный остаток в учёте — круг замыкается.
Связующее звено — всё тот же offer_id. Если артикулы в 1С, на сайте и на Ozon расходятся, синхронизация ломается, поэтому единая система артикулов — обязательное условие.
Что реализуется на стороне Битрикса
Даже когда операционка живёт в RetailCRM, на 1С-Битрикс обычно остаётся:
- обмен каталогом и остатками с 1С (модуль
catalog, CommerceML); - приём заказов из RetailCRM в модуль
saleчерез REST/вебхуки для единой отчётности; - передача заказов маркетплейса в 1С вместе с заказами сайта;
- журналирование и мониторинг обмена.
Технически интеграция строится на событиях RetailCRM (webhooks) и REST-вызовах, а на стороне Битрикса — на обработчиках событий модуля sale и агентах. Заказы из разных каналов удобно различать по свойству заказа «Источник» или отдельному складу.
Типичные проблемы и как их избежать
Что чаще всего ломается в связке Ozon + RetailCRM + Битрикс:
| Проблема | Причина | Решение |
|---|---|---|
| Задвоение заказов | заказ импортируется и из RetailCRM, и напрямую из Ozon | один источник импорта, дедуп по posting_number |
| Расхождение статусов | нет карты соответствий | единый маппинг статусов, одна система-владелец |
| Продажи без остатка | остатки обновляются редко | частая синхронизация из учёта |
| Потеря строк заказа | несовпадение offer_id | единая система артикулов |
Итог
Связка Ozon + RetailCRM работает предсказуемо, когда у каждой сущности один владелец: остатки ведёт учёт, статусы отправления меняет система сборки, заказы импортируются из одного источника. 1С-Битрикс в этой схеме отвечает за каталог, остатки и единую отчётность с заказами сайта, а offer_id связывает всё воедино.
Мы в B2Bsite проектируем такие связки под вашу конфигурацию: определяем владельцев данных, настраиваем обмен Битрикс ↔ RetailCRM ↔ 1С, прописываем карту статусов и мониторинг. Так заказы Ozon обрабатываются без ручного переноса и задвоений.
Частые вопросы
RetailCRM уже умеет работать с Ozon — зачем Битрикс?
RetailCRM закрывает операционку, но сайт на Битриксе остаётся источником каталога и остатков, а также местом единой отчётности вместе с заказами сайта и обменом с 1С. Связка распределяет роли, а не дублирует их.
Где должны вестись остатки?
В одной системе — обычно в учёте (1С или МойСклад). Оттуда они транслируются в Ozon и RetailCRM. Несколько независимых источников остатков приводят к продажам отсутствующего товара.
Как избежать задвоения заказов?
Импорт должен идти из одного источника, а дедупликация — по уникальному posting_number отправления Ozon. Нельзя тянуть один заказ и через RetailCRM, и напрямую из Seller API.
Кто меняет статус отправления в Ozon?
Только та система, что реально выполняет сборку и передачу в доставку. Если статус будут менять и RetailCRM, и Битрикс, возникнет конфликт и ошибки API.
Чем связаны строки заказа и товары каталога?
Полем offer_id — вашим артикулом. Он должен совпадать в 1С, на сайте и на Ozon, иначе строки заказа не сопоставляются с товарами.
Можно ли зеркалировать заказы Ozon в модуль sale Битрикса?
Да, через REST и вебхуки RetailCRM. Это нужно для единой отчётности и передачи заказов маркетплейса в 1С вместе с заказами сайта.
Как различать заказы сайта и маркетплейса в Битриксе?
Через свойство заказа «Источник» или отдельный склад/тип плательщика. Это упрощает отчётность и маршрутизацию в 1С.
Поможем с настройкой и поддержкой Интеграции и связки систем
Поможем с настройкой, доработкой и поддержкой Интеграции и связки систем.