Wildberries + RetailCRM

Связка Wildberries и RetailCRM позволяет обрабатывать заказы маркетплейса в том же окне, где живут заказы сайта на 1С-Битрикс. Но у неё есть подводные камни: где хранится каталог, кто хозяин остатков и как не задвоить заказы. Разберём архитектуру глазами интегратора.

Зачем связывать WB, RetailCRM и Битрикс

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

• 1С-Битрикс — витрина и источник каталога (карточки, характеристики, цены сайта);
• RetailCRM — обработка заказов, статусы, коммуникации, аналитика по каналам;
• Wildberries — канал продаж, откуда прилетают заказы и куда уходят остатки.

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

Две возможные архитектуры связки

На практике встречается два подхода, и выбор влияет на всю дальнейшую эксплуатацию:

Первый вариант проще: подключения независимы, RetailCRM сама забирает заказы WB. Второй даёт полный контроль на стороне Битрикс, но требует собственного модуля выгрузки заказов WB. Чаще выбирают первый и оставляют за Битрикс роль каталога и (через 1С) остатков.

Каталог и сопоставление товаров

Чтобы заказ WB корректно лёг в RetailCRM и связался с товаром сайта, нужна сквозная привязка номенклатуры. Ключ сопоставления — артикул продавца (vendorCode) и баркод, которые должны совпадать во всех трёх системах.

• в Битрикс артикул хранится в свойстве товара или XML_ID торгового предложения;
• в RetailCRM это поле article / xmlId товарного предложения;
• в WB — vendorCode в карточке.

Каталог в RetailCRM удобнее наполнять из Битрикс через ICML-выгрузку (RetailCRM умеет читать этот формат по расписанию). Тогда товары сайта и позиции заказов WB связываются автоматически по артикулу, и аналитика по товарам не рассыпается на «сайтовые» и «маркетплейсовые» строки.

Единые остатки и склады

Ключевой риск любой мультиканальной торговли — продать один товар дважды. Чтобы этого избежать, остаток должен считаться в одном месте и раздаваться по каналам. Обычно источник остатков — 1С или складской модуль, а маршрут такой:

1. 1С отдаёт актуальный остаток в Битрикс (через CommerceML);
2. Битрикс или RetailCRM держит единый складской остаток;
3. остаток раздаётся на витрину сайта и на склад продавца WB (FBS) через Marketplace API.

RetailCRM умеет вести склады и передавать остатки в WB в рамках своей интеграции. Если же остатками управляет Битрикс, выгрузку в WB (PUT /api/v3/stocks/{warehouseId}) делают агентом на стороне сайта. Главное — не включать выгрузку остатков в WB одновременно из двух систем.

Заказы и статусы: как избежать задвоения

Заказы Wildberries попадают в RetailCRM как заказы отдельного канала (order type/site). Дальше важно не дать им продублироваться и правильно провести статусы:

• у каждого заказа WB есть внешний идентификатор — он должен сохраняться в externalId заказа RetailCRM для идемпотентности;
• статусы WB (новое сборочное задание, на сборке, в доставке) маппятся на группы статусов RetailCRM;
• обратная передача статуса на WB (сборка, отгрузка) идёт через FBS-методы Marketplace API.

Если в схеме участвует Битрикс как передаточное звено, каждый заказ WB создаёт заказ в Битрикс с сохранением внешнего ID и признака канала. При повторном запросе тот же заказ не должен создаваться заново — проверка по externalId обязательна.

Техническая связка Битрикс и RetailCRM

Со стороны 1С-Битрикс подключение к RetailCRM делают одним из способов:

Обмен с REST API RetailCRM в Битрикс строят на Bitrix\Main\Web\HttpClient, ICML-выгрузку каталога — по расписанию через агент/cron. Для передачи заказов сайта в CRM удобно использовать событие оформления заказа (OnSaleOrderSaved) с постановкой в очередь, чтобы не блокировать оформление на витрине при недоступности CRM.

• токены RetailCRM и WB храните в настройках модуля, а не в коде;
• ведите лог обмена с внешними ID для разбора расхождений;
• предусмотрите повторную отправку при сбое (retry с backoff).

Итог

Связка Wildberries + RetailCRM + 1С-Битрикс работает надёжно, когда чётко распределены роли: Битрикс/1С — каталог и остатки, RetailCRM — обработка заказов и аналитика, WB — канал продаж. Сквозная привязка по артикулу и баркоду, единый источник остатков, идемпотентность заказов по внешнему ID и разделение FBO/FBS — вот что отличает рабочую интеграцию от постоянных расхождений.

Мы в B2Bsite настраиваем такие мультиканальные связки под ключ: подключаем Битрикс к RetailCRM, выстраиваем ICML-выгрузку каталога, согласуем остатки с 1С и следим, чтобы заказы WB не задваивались. В результате менеджеры работают в одном окне, а данные остаются согласованными.