Когда один товар продаётся через собственный сайт и маркетплейсы, главный риск — не само количество каналов. Проблема возникает, если каждый канал хранит свою версию доступного остатка, а обновления между системами происходят несогласованно. Тогда один и тот же товар можно одновременно пообещать нескольким покупателям.
Сначала определить источник истины
Единый учёт остатков начинается с ответа на простой вопрос: какая система считается главной по доступному количеству товара. Это может быть учётная система, ERP, складская система или другой внутренний контур. Важно не название программы, а то, чтобы именно она принимала события, меняющие доступный запас, и передавала актуальное состояние в каналы продаж.
Если сайт, Ozon, Wildberries и внутренний склад независимо считают остаток «правильным», автоматизация только ускорит распространение расхождений.
Остаток меняет не только продажа
Для синхронизации недостаточно периодически копировать число. На доступный запас влияют резерв, новый заказ, отмена, оплата, сборка, отгрузка, возврат, брак и ручная корректировка. Поэтому надёжная схема строится вокруг событий и правил их обработки.
Отдельно нужно учитывать, что товар на складе маркетплейса и товар на собственном складе — это разные физические запасы. Их нельзя свести к одной цифре без понимания, откуда конкретный канал может выполнить заказ.
Как должна работать синхронизация остатков
После изменения состояния главная система пересчитывает доступное количество и передаёт его в нужные каналы. Если площадка или API временно недоступны, ошибка должна фиксироваться, а не исчезать. После восстановления связи система повторяет обновление и сверяет результат.
Критично иметь журнал расхождений: какой канал получил значение, когда оно было отправлено и подтверждено ли обновление. Без этого сотрудник видит только конечную цифру и не понимает, на каком участке возник сбой.
Где достаточно простых правил
При небольшом ассортименте, низкой частоте заказов и одном складе иногда достаточно регулярной синхронизации и понятной ручной процедуры на случай ошибки. Не всякому бизнесу нужен сложный интеграционный контур.
Автоматизация становится существенно полезнее, когда заказов много, несколько каналов конкурируют за один запас, есть резервы и возвраты, а задержка обновления уже создаёт отмены или ручные сверки. Тогда важен не красивый «единый кабинет», а надёжный обмен событиями и контроль исключений.
Что проверить перед добавлением нового канала
Нужно заранее определить: где хранится главный остаток; какие события его меняют; как быстро каналы получают обновление; что происходит при недоступности внешней системы; кто видит конфликт; как выполняется повторная сверка после сбоя.
Если новый канал требует постоянного ручного переноса данных, это сигнал сначала спроектировать интеграцию. В материале о ручном переносе данных между системами мы отдельно разбираем, почему эта работа становится самостоятельным операционным процессом.
При запуске собственного интернет-магазина мы рассматриваем остатки как часть общего контура заказа: сайт не должен становиться ещё одной изолированной копией склада.