Когда товар продаётся в рознице, на Ozon и на Wildberries, главный риск — трижды пообещать покупателям одну физическую единицу. Решение начинается не с выбора интегратора, а с правил учёта: где хранится истинное количество, как создаётся резерв и когда он снимается. Способ передачи данных выбирают уже под эту модель.
Один физический остаток — одна точка учёта
Назначьте учётную систему, в которой фиксируются приёмка, брак, сборка и продажа каждой единицы. Для каждого SKU и склада отдельно храните физический остаток, подтверждённые резервы и недоступный товар. Нельзя брать число «на полке» и без изменений отправлять во все каналы.
Предположим, физически на складе 12 штук. Две зарезервированы под розничные покупки, одна повреждена. Доступный пул — 12 − 2 − 1 = 9. Если из него выделить Ozon 5 и Wildberries 4 штуки, рознице нельзя одновременно обещать те же девять. Это простая модель распределения; конкретный страховой буфер зависит от скорости продаж и задержки обновлений.
Выберите модель распределения
Есть два рабочих принципа. При фиксированных квотах каждому каналу выделяется часть доступного пула, а перераспределение делает ответственная система. Это проще контролировать вручную, но часть товара может простаивать в одном канале. При общем пуле каждый подтверждённый заказ немедленно резервирует единицу для всех каналов; тогда критичны скорость обработки событий и защита от повторной обработки. Смешивать обе схемы без явных правил опасно.
Запишите события, после которых меняется резерв: новый заказ, подтверждённая отмена, сборка, возврат, обнаружение брака. Повторное сообщение об одном заказе не должно дважды уменьшать запас. Для сопоставления используйте собственный SKU и ID заказа соответствующей площадки; похожие названия товаров не являются надёжным ключом.
Что проверять в интеграции
Попросите поставщика системы показать журнал обмена: старое и новое значение, время отправки, ответ площадки и ошибку. Уточните измеренную задержку обновления и поведение при временном сбое. Формулировка «синхронизируем автоматически» без журнала не позволяет понять, опубликован ли новый остаток на Ozon и WB.
Тестируйте на одной недорогой позиции. Задайте условный остаток 6, создайте резерв на одну штуку в рознице, затем имитируйте заказ Ozon, отмену и повтор события отмены. После каждого шага сравните учёт и видимое количество на обоих маркетплейсах. Повтор отмены не должен добавлять ещё одну свободную единицу. При сбое связи не считайте отправленный запрос успешным: нужен ответ или последующая сверка.
Ручная загрузка, готовый модуль и собственная интеграция различаются не «правильностью», а скоростью, стоимостью поддержки и возможностью восстановить события. Для небольшого ассортимента ручное обновление может быть допустимым при редких продажах, но при общем быстром обороте риск пересечения заказов растёт. Сверяйте метод с реальной частотой продаж, а не с произвольным порогом SKU.
Ежедневная сверка расхождений
Выведите по каждому каналу ожидаемое и опубликованное количество. Если числа разошлись, зарегистрируйте инцидент: SKU, склад, время, размер расхождения, последняя успешная операция. До выяснения причины применяйте заранее установленное безопасное правило ограничения продаж, а не исправляйте цифру «на глаз». После решения сохраните объяснение и повторите тест спорного события.
О синхронизации именно с учётной системой читайте материал про 1С и Ozon. Перед публикацией текущие способы обновления остатков и статусы заказов нужно подтвердить официальной документацией обеих площадок. Ни тарифов, ни фиксированных задержек обмена статья не обещает; пока она noindex.
