К содержимому
MoranaLabs.
Инженерные гайды10 мин чтения0 просмотров

Интеграция  с Ozon и Wildberries: что ломается на объеме 

Обмен с площадками обычно настраивают модулем за вечер, а через полгода он начинает задваивать заказы и врать по остаткам. Разбираем типовые отказы, идемпотентность, работу с лимитами и то, где проходит граница между коробкой и своей интеграцией.

0xReality

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

Разберем, что именно ломается и почему, без привязки к конкретным модулям. Общая архитектура обменов — схемы, версионирование, нагрузка на учетную базу — разобрана в статье про интеграцию по программному интерфейсу. Здесь только специфика площадок.

Три потока, которые называют одним словом «обмен»

Интеграция с площадкой — это три независимых процесса, у каждого своя логика и своя цена отказа.

Каталог. Карточки, характеристики, штрихкоды, габариты. Меняется редко, ошибки заметны сразу, откат простой.

Остатки и цены. Идут постоянно, ошибка приводит либо к продаже того, чего нет, либо к потере продаж из-за нулевого остатка. Самый чувствительный поток.

Заказы и статусы. Двусторонний обмен: заказы приходят, статусы отгрузки уходят. Ошибка здесь стоит дороже всего, потому что затрагивает деньги и обязательства перед покупателем.

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

FBS и FBO: почему это разные интеграции

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

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

Ошибка проектирования, которая встречается постоянно: попытка вести обе схемы одним механизмом. Тогда товар, лежащий на складе площадки, участвует в расчете доступного остатка своего склада, и система начинает обещать покупателю то, чего у нее нет.

Лимиты и очереди

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

Лечится это тремя приемами. Первый — отправлять только изменения вместо всего каталога: если по позиции остаток не поменялся, ее не надо трогать. Второй — группировать позиции в пакеты допустимого размера. Третий — очередь с приоритетами: ходовые позиции обновляются часто, неликвид раз в сутки.

Отдельная тонкость — реакция на ответ «слишком много запросов». Правильное поведение здесь: подождать и повторить с увеличивающейся паузой. Обмен, который при таком ответе просто пишет ошибку в лог и идет дальше, теряет обновления молча, и это выясняется на расхождении остатков через неделю.

Идемпотентность: почему задваиваются заказы

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

Защита строится на внешнем идентификаторе. Номер заказа площадки должен храниться в документе и проверяться перед созданием: если документ с таким идентификатором есть, повторное создание запрещено. Проверка делается по уникальному индексу: поиск по строке на объеме сам станет узким местом.

Тот же принцип нужен в обратную сторону. Отправка статуса отгрузки должна быть повторяемой: если ответ площадки потерялся, повтор не должен привести к двойному списанию или второй передаче в доставку.

Почему расходятся остатки

Жалоба «остатки на площадке не совпадают с 1С» почти всегда имеет одну из пяти причин, и все они лечатся по-разному.

ПричинаКак выглядитЧто делать
Резервы не учитываютсяТовар зарезервирован под другой канал, а на площадку ушел полный остатокСчитать доступный остаток вместо складского
Обмен отстаетРасхождение растет к вечеру и уходит за ночьПриоритеты в очереди, отправка только изменений
Ошибки не обрабатываютсяЧасть позиций не обновилась, в логе есть отказыПовторы с паузой и контроль неотправленных
Возвраты не приходят в учетТовар вернулся на склад площадки, в учете его нетОтдельная обработка возвратов и невыкупов
Двойное управлениеОстаток правят и в учетной системе, и в кабинете рукамиОпределить единственный источник правды

Последняя причина самая частая и самая неочевидная. Пока кто-то в компании имеет привычку править остатки прямо в кабинете площадки, никакая интеграция не даст сходимости.

Отдельно стоит договориться о допустимом расхождении. Идеальной сходимости в реальном времени не бывает: между продажей на площадке и обновлением остатка всегда проходит время. Разумный подход — определить порог, при котором расхождение считается нормой, и контролировать превышения. Тогда вместо ежедневной ручной сверки появляется отчет по позициям, где что-то действительно пошло не так.

Проверять сходимость стоит на срезе, а не на потоке: раз в сутки в спокойное время снимаются остатки с обеих сторон и сравниваются. Такой отчет занимает минуту и заменяет утренние ритуалы менеджера с двумя открытыми окнами.

Сопоставление номенклатуры

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

Правильное решение — отдельная таблица соответствий с коэффициентом пересчета. Подгонять свой справочник под требования площадки — путь к потере учета. Тогда продажа упаковки из шести штук корректно списывает шесть единиц со склада, и учет остается вашим.

Отдельно стоит завести признак «продается на площадке» и правило, что новая позиция не уезжает в каталог автоматически до заполнения обязательных полей. Иначе первый же импорт прайса поставщика создаст на площадке сотни карточек без габаритов и описаний.

Цены и акции: кто главный

Площадки активно управляют ценой: акции, скидки, автоматические снижения. Учетная система при этом считает цену по своим правилам. Если обмен просто перетирает цену на площадке значением из учета, вы будете регулярно выпадать из акций и не понимать, почему упали продажи.

Рабочая схема выглядит так: учетная система хранит базовую цену и минимально допустимую, а участие в акциях остается за менеджером в кабинете. Обмен при этом проверяет, что итоговая цена площадки не опустилась ниже минимально допустимой, и сигнализирует, если это произошло.

Такой контроль стоит недорого и окупается на первой же акции, в которую товар попал с ценой ниже себестоимости.

Возвраты, невыкупы и потери

Участок, который в проектах обмена регулярно откладывают на потом, а потом он превращается в ежемесячную ручную сверку.

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

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

Комиссии и сверка с отчетом площадки

Деньги приходят от площадки сводной суммой за период, с удержанной комиссией, логистикой, штрафами и корректировками. Чтобы понимать реальную маржинальность, отчет площадки нужно разложить по заказам и сопоставить с вашими отгрузками.

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

Результатом должен быть отчет с расхождениями и суммой к разбору. Победная надпись «сверка выполнена» пользы не приносит.

Журналирование: без него разбора не будет

Любой обмен рано или поздно даст сбой, и вопрос будет один: что именно произошло с конкретным заказом. Ответить на него можно только по журналу.

Минимальный состав записи: время, направление, объект, отправленные данные, полученный ответ, результат. Хранить это надо столько, сколько занимает претензионный цикл с площадкой, обычно два-три месяца, с автоматической очисткой старых записей, чтобы журнал не съел базу.

Второй обязательный элемент — мониторинг. Кто-то должен узнавать о том, что обмен встал, раньше, чем это заметит покупатель. Достаточно простого правила: если за час не прошло ни одной успешной операции, уходит уведомление ответственному.

Площадка меняет правила: как не сломаться

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

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

Стоит заранее договориться, как оформляются такие доработки: обычно они идут по подписке на сопровождение или отдельными мелкими работами. Общая механика обменов и требования к их версионированию описаны на странице интеграции по программному интерфейсу.

Сколько занимает работа

Разбор текущего обмена и постановка задачи — от нескольких дней до двух недель, в зависимости от того, насколько запутана текущая схема и есть ли журналы.

Первая работающая версия обмена по одной площадке — три-четыре недели с тестированием на реальном потоке. Вторая площадка обычно занимает вдвое меньше, потому что механика очередей, журналирования и сопоставления уже собрана.

Сверка с отчетами площадки и работа с возвратами делаются отдельным этапом, еще две-три недели. Этот этап логично делать вторым: он требует накопленных данных хотя бы за месяц работы обмена. Что еще входит в наш периметр по учетной системе, собрано на странице интеграции 1С.

Когда хватит готового модуля

Честный раздел, который экономит вам деньги.

Готовое решение закрывает задачу, если у вас типовая конфигурация без серьезных доработок, одна-две площадки, работа по одной схеме, до нескольких тысяч позиций и стандартный набор операций без хитростей с наборами и комплектами.

Своя интеграция начинает окупаться, когда появляется хотя бы два признака из списка: самописная или сильно доработанная конфигурация, несколько юрлиц и складов, десятки тысяч позиций, наборы и комплекты, собственная логика резервирования, требование к сверке с отчетами площадки, работа сразу по обеим схемам складов.

Работы по интеграции у нас начинаются от 140 000 ₽, точная оценка появляется после разбора текущего обмена. Из чего вообще складывается цена доработок, разобрано в отдельной статье.

Кто это ведет со стороны компании

Техническая интеграция закрывает механику, но остается операционный слой, который автоматизировать нельзя. Кто-то должен разбирать спорные возвраты, отвечать на претензии площадки, следить за карточками и решать, участвовать ли в акции.

На практике это один человек в компании — категорийный менеджер или специалист по площадкам, — и от его работы результат зависит не меньше, чем от качества обмена. Автоматизация здесь дает ему время: вместо ежедневной сверки остатков в таблице он занимается ассортиментом и ценой.

Договоритесь заранее, что этот человек участвует в приемке интеграции. Он единственный, кто заметит, что в выгрузке не хватает признака, по которому он каждый день принимает решения.

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

Обратная крайность тоже встречается: компания автоматизирует все подряд, включая решения, которые требуют суждения. Автоматическое снятие товара с продажи по формальному признаку или автоматическая переоценка без контроля приводят к потерям быстрее, чем ручная работа. Автоматизируем перенос данных и проверки, решения оставляем человеку.

Чек-лист устойчивого обмена

  1. Каталог, остатки и заказы обмениваются независимыми процессами.
  2. Заказы создаются с проверкой внешнего идентификатора по индексу.
  3. На ответ о превышении лимита обмен реагирует паузой и повтором.
  4. На площадку уходит доступный остаток с учетом резервов.
  5. Отправляются только изменения, ходовые позиции имеют приоритет.
  6. Схемы работы со своего склада и со склада площадки разделены.
  7. Сопоставление ведется таблицей соответствий с коэффициентами.
  8. Есть контроль минимальной цены.
  9. Возвраты, невыкупы и компенсации попадают в учет документами.
  10. Ведется журнал операций и работает уведомление об остановке обмена.

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

  • #
  • #Ozon
  • #Wildberries
  • #интеграция
  • #маркетплейсы
  • #обмен данными
ПоделитьсяTelegramX
рассылка

Новые статьи — на почту

Лонгриды про ML в проде, edge и компьютерное зрение — сразу после выхода.

Канал в Telegram: morana.log

Без спама. Нажимая «Подписаться», соглашаетесь с обработкой персональных данных

бесплатный pdf-гайд

Edge AI или облако: когда тащить нейросеть на железо

Признаки, фреймворк выбора и прикидка экономии — короткий PDF-гайд на почту.

PDF · 5 страниц · без спама. Нажимая «Получить», соглашаетесь с обработкой персональных данных

Читать дальше
— заявка

Опишите задачу  ответим как инженеры. 

Оставьте имя и Telegram — остальное обсудим. Без брифов на 40 слайдов и звонков по три раза.

Отвечаем за пару часовотвечает инженер, а не отдел продажNDA по запросу

Сюда напишем — это быстрее всего

Или сразу написать в Telegram

Без спама и звонков-роботов. Нажимая кнопку, вы соглашаетесь с политикой конфиденциальности и обработкой персональных данных.