Как мы построили склад для нескольких продавцов маркетплейсов и не смешали их товары
3PL-оператор (компания, которая берёт на себя хранение и отгрузку товара для внешних клиентов) обычно работает не с одним складом на одну компанию, а с одним складом на десятки продавцов маркетплейсов одновременно. У каждого продавца — свой ассортимент, свои остатки, свои заказы с Ozon, Wildberries и Яндекс.Маркета. Смешать товары или показать одному продавцу остатки другого — не просто неудобно, а прямой финансовый и репутационный риск.
Рассказываем, как мы спроектировали WMS (систему управления складом) для такого сценария — от приёмки товара до отгрузки конечному покупателю.
Задача
До внедрения системы склад вёл учёт вручную — таблицы, звонки, бумажные накладные. При таком подходе с ростом числа продавцов возникают одни и те же проблемы:
- Невозможно быстро понять, сколько и где именно (на какой ячейке склада) лежит товар конкретного продавца.
- Приёмка товара без сверки по факту — расхождения по количеству обнаруживаются постфактум, когда разбираться уже сложнее.
- Сборка заказов идёт «из общей кучи» — риск отгрузить чужой товар вместо нужного.
- У продавца нет прозрачности: чтобы узнать остатки, нужно звонить на склад.
Как устроено решение
Мультитенантность на уровне данных
Каждая единица остатка привязана к конкретному продавцу (селлеру). Это не просто колонка «владелец» для галочки — API и интерфейс жёстко фильтруют данные по этому полю на каждом запросе, поэтому продавец физически не может увидеть остатки, заявки или отгрузки другого продавца, даже если попробует обратиться к системе напрямую.
Адресное хранение по ячейкам
Склад разбит на зоны и ячейки со статусами «свободна» / «занята» / «заблокирована» / «зарезервирована». Товар при приёмке физически кладётся в конкретную ячейку, и система это фиксирует — вопрос «а где именно лежит партия №42» перестаёт требовать похода на склад.
Приёмка со сверкой расхождений
Приёмка — отдельный пошаговый процесс: заявка на поставку → товар в пути → приёмка на складе со сканированием и сверкой фактического количества с заявленным. Расхождения фиксируются сразу, а не обнаруживаются через месяц при инвентаризации. После подтверждения приёмки остатки обновляются автоматически и сразу становятся видны продавцу.
Сборка (picking) как отдельный этап
Отгрузка не происходит «в один клик» — между приёмкой и отправкой есть отдельный этап сборки, где сборщик с ТСД (терминал сбора данных) собирает конкретные позиции по заданию, сканируя каждую. Это тот же принцип, что в крупных фулфилмент-центрах: разделение «что нужно собрать» и «что физически собрано», с проверкой на каждом шаге.
Личный кабинет продавца и интеграции с маркетплейсами
Продавец видит свои остатки, заявки и отгрузки в отдельном личном кабинете — без доступа к операционным настройкам склада. Заказы и остатки синхронизируются автоматически с Ozon, Wildberries и Яндекс.Маркетом, так что продавцу не нужно вручную сверять, что происходит на складе, с тем, что показывает маркетплейс.
Результат
- Данные и товары разных продавцов физически и логически изолированы — перепутать остатки или заявки одного продавца с другим невозможно на уровне системы, а не только по договорённости.
- Приёмка, хранение, сборка и отгрузка — единый прослеживаемый процесс вместо разрозненных таблиц и звонков.
- Автоматическая синхронизация с тремя маркетплейсами убирает ручную сверку остатков.
- Ролевая модель (администратор, логист, кладовщик, приёмщик, сборщик, продавец) разграничивает доступ по зонам ответственности на каждом складе.
Если у вас похожая ситуация
Если склад обслуживает больше одного клиента (или больше одного подразделения со своей отчётностью) и учёт до сих пор держится на Excel и звонках — это тот самый момент, когда ручные процессы начинают стоить дороже, чем система, которая их автоматизирует. Расскажите нам о своей задаче — обсудим, что имеет смысл автоматизировать в первую очередь.
