Когда продавец работает только с одним маркетплейсом, остатки ещё можно контролировать вручную: выгрузить отчёт, сверить склад, поправить карточки. Но как только появляются несколько площадок, несколько личных кабинетов и общий склад, ручной учёт быстро начинает ломаться.
Один и тот же товар может одновременно продаваться на Ozon, Wildberries и в другом канале. Заказы приходят в разное время, статусы обновляются не синхронно, возвраты возвращаются с задержкой, а сотрудники продолжают собирать заказы из одного физического остатка. В итоге на витрине товар ещё есть, а на складе его уже забрали под другой заказ. Для селлера это не просто неудобство. Ошибка в остатках превращается в отмену, просрочку, спор с покупателем, штраф или снижение рейтинга.
Почему остатки расходятся?
Главная причина — учёт живёт отдельно от реального движения товара. В личном кабинете маркетплейса видно одно, в учётной системе другое, на складе третье. Пока сотрудник собирает заказ, информация может устареть уже через несколько минут.
Чаще всего расхождения появляются в нескольких местах:
- заказ с одной площадки уже собран, но остаток ещё не обновился в других магазинах;
- товар зарезервировали под заказ, но физически он лежит вместе с доступным остатком;
- возврат приняли на склад, но не вернули товар в доступный остаток;
- один и тот же SKU по-разному называется в разных личных кабинетах;
- часть операций ведётся в таблицах, а часть в учётной системе;
- сотрудник узнаёт о нехватке только в момент сборки.
Чем больше заказов и площадок, тем сильнее эта проблема. Она не решается внимательностью сотрудников: процесс должен сам показывать, что реально можно собрать и отгрузить.
Чем опасен ручной контроль остатков?
Ручная сверка кажется простой, пока заказов немного. Но на потоке она создаёт задержки и скрытые ошибки. Например, продавец видит на складе 20 единиц товара и распределяет их между двумя маркетплейсами. За день часть товара продаётся на одной площадке, часть уходит в сборку на другой, ещё несколько штук возвращаются от покупателей. Если все эти события не попадают в общий учёт вовремя, остаток становится приблизительным. Проблема в том, что маркетплейс не видит вашу внутреннюю логику. Для него важен результат: заказ должен быть собран, передан вовремя и без ошибки. Если товара нет, карточка и рейтинг страдают уже на стороне площадки.
Для маркированных товаров риск выше. Нужно контролировать не только количество, но и конкретные коды Data Matrix: какой экземпляр ушёл покупателю, какой вернулся, какой снова доступен к продаже.
Как должен работать единый учёт?
Единый учёт нужен не ради красивой цифры в отчете. Его задача — связать витрину, склад и сборку заказа в один процесс.
Рабочий сценарий выглядит так: заказы из разных маркетплейсов попадают в общую очередь. Склад видит, какие товары реально нужно собрать. При сборке сотрудник сканирует товар на ТСД. Система подтверждает правильный SKU и количество. Остаток уменьшается по факту операции, а не после ручной сверки. Возврат возвращается в учёт только после проверки и сканирования. Маркированный товар связывается с конкретным заказом и кодом Data Matrix.
Так склад работает не по памяти и не по распечатке, а по актуальному заданию. Если товара нет, ошибка обнаруживается до передачи заказа, а не после претензии от маркетплейса.
Где помогает «Маркетплейс 15»?
Для таких задач компания Клеверенс предлагает решение «Маркетплейс 15». Оно помогает перенести сборку FBS-заказов, проверку товара и работу с маркировкой на ТСД, чтобы складские действия сразу отражались в учётном контуре.
Единая очередь заказов
Сотрудник работает не с несколькими разрозненными личными кабинетами, а с очередью заказов на терминале. Это снижает риск, что заказ с одной площадки соберут, а остаток для другой площадки останется завышенным. На ТСД видно, какой заказ нужно собрать, какие позиции в него входят и в каком количестве. Склад перестаёт выбирать заказы по распечаткам и начинает работать по понятному списку задач.
Сборка сканированием
При подборе сотрудник сканирует товар. Система проверяет, тот ли SKU взят, и не даёт спокойно закрыть заказ с лишней или пропущенной позицией. Это особенно важно, когда один товар продаётся в нескольких магазинах или имеет разные названия на разных площадках. Сканирование помогает связать физический товар с номенклатурой в учёте, а не полагаться на визуальное совпадение названий.
Контроль маркированных товаров
Если товар маркируется, в процессе сборки нужно подтвердить конкретный Data Matrix. Для селлера это критично: после продажи код должен корректно выйти из оборота, а при возврате — вернуться в учёт только после проверки. «Маркетплейс 15» помогает встроить работу с кодами в обычный сценарий сборки. Сотруднику не нужно отдельно вести список марок или восстанавливать, какой экземпляр ушёл в заказ.
Возвраты и доступный остаток
Возврат не должен автоматически превращаться в доступный товар. Сначала его нужно принять, проверить состояние, сверить код маркировки, а уже потом вернуть в продажу. Если этот процесс ведется через ТСД, склад видит разницу между физически вернувшимся товаром и товаром, который действительно можно снова продавать. Это защищает от ситуации, когда площадка показывает доступный остаток, а товар ещё не прошел проверку.
Что получает продавец?
После перехода от ручной сверки к единому учёту меняется не только цифра остатков. Меняется сам процесс работы склада. Продавец получает:
- меньше отмен из-за отсутствующего товара;
- меньше пересорта при сборке заказов;
- более понятную очередь задач для сотрудников;
- контроль маркированных экземпляров в момент сборки;
- быстрее обработку возвратов;
- меньше ручных таблиц и перепроверок;
- более стабильную работу на нескольких маркетплейсах.
Главный эффект — склад перестает догонять витрину. Остатки обновляются не после аврала в конце дня, а по мере фактических операций: сборки, упаковки, отгрузки и возврата.
Когда пора наводить порядок?
Если продавец работает на нескольких площадках и регулярно сталкивается с отменами, спорными остатками или ручными корректировками, это уже сигнал. Значит, учёт не успевает за реальным движением товара.
Проблему лучше решать до роста заказов. Чем больше поток, тем дороже каждая ручная ошибка: один неверный остаток может затронуть сразу карточку, рейтинг, складскую смену и поддержку.
Единый учёт в связке со сборкой на ТСД помогает сделать процесс управляемым. Заказ собирается по заданию, товар подтверждается сканированием, маркированные позиции фиксируются по кодам, а остатки не живут отдельно от склада. Для FBS-продавца это база спокойной работы на нескольких маркетплейсах.