Как синхронизировать остатки между маркетплейсами и своим магазином
Практика3 минРедакция Innovialabs
Коротко
Остатки должны жить в одной системе, а все каналы получают из неё доступное количество с небольшим резервом; продажа в любом канале сразу уменьшает общий остаток.
Главный принцип: один источник правды
Если вы продаёте на сайте и на нескольких маркетплейсах, остаток должен храниться в одном месте: в учётной системе, WMS, CRM или отдельном сервисе синхронизации. Каналы не ведут свои остатки — они только получают из центра доступное к продаже количество и сообщают о продажах.
Схема простая:
- Заказ приходит из любого канала.
- Центральная система резервирует товар и уменьшает остаток.
- Новое доступное количество отправляется во все остальные каналы.
Когда остатки правят вручную в каждом личном кабинете, рано или поздно один товар продают дважды.
Что такое доступный остаток
Физический остаток на складе и то, что можно продать, — разные числа.
Доступно к продаже = на складе − в резерве под заказы − страховой буфер
- Резерв — товары в оформленных, но ещё не отгруженных заказах.
- Буфер — небольшой запас, который вы не показываете каналам. Он закрывает разрыв между продажей и обновлением остатков в других каналах.
Буфер можно задавать по-разному: фиксированное количество, правило «показывать ноль, если осталось меньше N» или отдельная квота для каждого канала. Для ходовых товаров с малым остатком буфер полезнее всего.
Как работают API маркетплейсов
Крупные маркетплейсы дают API для обновления остатков и получения заказов. Общие черты, которые стоит учесть:
- Лимиты запросов — нельзя отправлять обновление по каждому товару отдельно без ограничений. Обновления группируют пачками.
- Модели работы со складом — при продаже со своего склада вы управляете остатками сами; если товар лежит на складе маркетплейса, остатками там управляет площадка, и синхронизировать нужно иначе.
- Сопоставление товаров — у каждой площадки свой идентификатор карточки. Нужна таблица связей «ваш SKU ↔ ID на площадке».
- Получение заказов — через вебхуки или регулярный опрос API.
Перед разработкой изучите документацию каждой площадки: правила и лимиты отличаются и меняются.
Интервалы обновления
| Событие | Как часто |
|---|---|
| Новый заказ в любом канале | Сразу или в течение минут |
| Отмена или возврат | Сразу, остаток возвращается |
| Поступление на склад | После оприходования |
| Сверка всех остатков | Раз в сутки или чаще |
Событийные обновления дают скорость, а регулярная полная сверка исправляет то, что потерялось: упавший запрос, ручную правку, сбой на стороне площадки.
Готовый сервис или своя интеграция
Готовые сервисы мультиканальной торговли подходят, если:
- площадки популярные и сервис их поддерживает;
- учётная система стандартная;
- нужна быстрая настройка без разработки.
Своя интеграция оправдана, если:
- учёт ведётся в доработанной 1С или самописной системе;
- нужны свои правила резервов, квот и приоритетов каналов;
- есть площадки, которые готовые сервисы не поддерживают;
- объём заказов большой и важен контроль над логикой.
Частые ошибки
- Остатки правят вручную в кабинетах маркетплейсов.
- Нет таблицы соответствия SKU — обновления уходят не на те карточки.
- Отмены не возвращают товар в остаток.
- Ошибки API не логируются, и карточка неделями показывает неверное количество.
- Нет буфера на товарах, которых осталось несколько штук.