1. Сборка заказов в WMS при отсутствии сущности «заказ»

Многие WMS (особенно нацеленные на управление запасами и операциями) оперируют понятиями отгрузки или экспедиции, вместо прямого понятия «заказ покупателя». Если в WMS нет явной сущности «заказ клиента», следует использовать другие сущности и механизмы WMS для формирования подборок под заказ:

• Заказ на отгрузку / Отгрузочный документ. В большинстве WMS есть понятие отгрузочного заказа (shipment order), который отражает, какие товары нужно отгрузить со склада. Для каждого клиентского заказа (или для каждой его части) можно через API создавать соответствующий заказ на отгрузку в WMS. Эта сущность будет содержать список SKU и количеств, подлежащих отбору и отгрузке. Все дальнейшие операции в WMS – отбор, консолидация, упаковка, отгрузка – будут привязаны к этому документу заказа на отгрузку. Таким образом, хоть «заказа» в терминах WMS может не быть, его роль играет заказ на отгрузку (по сути подзаказ, если оригинальный заказ разбит на части).
• Грузовое место / груз (Handling Unit). WMS обычно позволяют работать с грузовыми единицами – коробами, паллетами, контейнерами. Для комплектации заказа можно использовать грузовое место как физический контейнер, куда собираются товары одного заказа. В рамках WMS за каждым таким контейнером закрепляется уникальный номер (штрихкод), и система знает содержимое контейнера. При подборе (комплектации) заказа каждую позицию можно сразу складировать в предназначенное для этого заказа грузовое место (например, короб или лоток). Такой контейнер в WMS фактически будет эквивалентен собранному заказу.
• Контейнеры при кластерном отборе. Если склад обрабатывает сразу несколько заказов, можно применять кластерный пикинг – одновременный отбор товаров для нескольких заказов. В этом случае для каждого заказа готовится свой контейнер (например, несколько коробов на тележке), и система подсказывает сборщику, в какой контейнер положить каждую отобранную позицию. Такой подход позволяет собирать несколько заказов параллельно, распределяя товары по контейнерам заказов. Контейнер-груз для каждого заказа играет роль сборочной единицы, несмотря на отсутствие явной сущности «заказ»: WMS отслеживает, какие SKU помещены в контейнер, тем самым формируя состав заказа.
• Ячейки консолидации (буфер неполных заказов). В случае, если заказ не может быть сразу собран полностью (например, не все товары доступны одномоментно), полезно предусмотреть физическую или логическую зону/ячейки ожидания для таких частично собранных заказов. WMS может оперировать выделенными ячейками хранения под заказ: например, каждая ячейка помечается идентификатором заказа (или подзаказа) и туда складываются отобранные позиции, пока не появятся недостающие. Это особенно актуально при частичной комплектации: наличие «буфера неполных заказов» позволяет хранить частично отобранный заказ до его дозакладки или отгрузки частями. Если бизнес-правила маркетплейса допускают частичные отгрузки, WMS-процесс может быть настроен так, что заказ на отгрузку закрывается даже с неполным набором позиций (недостающие позиции либо отменяются, либо оформляются другим отгрузочным документом позже).

Резюме: несмотря на отсутствие прямой сущности «заказ клиента» в WMS, можно использовать заказы на отгрузку (как документ для выполнения), контейнеры или грузоместа (как физическое объединение позиций заказа) и специальные ячейки или зоны (для консолидации или хранения частично собранных заказов). Эти механизмы обеспечат сборку заказов под конкретного покупателя. В API Yolka WMS, к примеру, предусмотрены методы для создания отгрузок и обработки их статусов – можно через вызов вроде POST /shipment создать отгрузку по заказу и затем отметить ее выполненной (подобные эндпоинты указаны в Swagger-документации Yolka WMS). Таким образом, каждый подзаказ маркетплейса будет представлен в WMS как отдельная отгрузка/груз, собранная в конкретный контейнер.

2. Организация пунктов выдачи заказов (ПВЗ)

Два подхода: ПВЗ можно рассматривать либо как часть складской системы (мини-склад), либо как элемент, управляемый на стороне маркетплейса (вне основной WMS). Рассмотрим оба варианта:

• ПВЗ как мини-склад в WMS: В этом случае каждый пункт выдачи моделируется как отдельный склад или зона хранения в WMS. Когда заказ готов к отправке покупателю через ПВЗ, WMS оформляет перемещение или отгрузку с основного склада на склад-ПВЗ. Товар физически едет в пункт выдачи, а в WMS происходит движение запасов: со списанием с центрального склада и оприходованием на виртуальный склад ПВЗ. Преимущества этого подхода:
• Единая система учета: WMS будет знать, где именно находится товар – даже на этапе нахождения в пункте выдачи. Учет остатков будет вестись вплоть до момента вручения покупателю.
• Сквозная прослеживаемость: можно использовать сканирование штрихкодов/QR-кодов при выдаче, непосредственно завершая отгрузку в WMS. Например, сотрудник ПВЗ сканирует коробку – WMS фиксирует реализацию (выдачу) и списывает товар.
• Возможность управления запасами ПВЗ: если ПВЗ крупный и хранит много посылок, WMS может помогать оптимизировать размещение посылок по полкам, оповещать о сроках хранения, возвращать непросчитанные заказы назад и т.д. Однако есть и минусы: полноценная WMS на маленьком ПВЗ может быть избыточной. Потребуются терминалы для сканирования, обучение сотрудников ПВЗ работе в WMS, лицензии на дополнительные пользователи и пр. Для 30 м² точек выдачи, где одновременно хранится сравнительно немного заказов, полноценный функционал WMS может оказаться слишком громоздким.
• ПВЗ вне WMS (учет на стороне маркетплейса): Здесь WMS отвечает только за процессы на больших складах, а когда посылка покидает склад, она передается под управление системе маркетплейса (логистической/OMS подсистеме). Практически это означает: WMS фиксирует отгрузку «до ПВЗ», а дальнейшее отслеживание происходит во внешней системе. В таком варианте:
• Перемещение отражается как отгрузка в WMS (например, заказ на отгрузку с пунктом назначения «ПВЗ №5»). После отгрузки WMS больше не «видит» товар – он списан со склада.
• Маркетплейс получает от WMS данные об отправленной посылке (ID заказа/посылки, состав, возможно код отслеживания) и далее учитывает ее поступление в пункт выдачи через свой софт. На ПВЗ может использоваться легкое приложение или веб-интерфейс: сотрудник отмечает в системе маркетплейса поступление коробки (сканируя ее код), хранит ее до прихода клиента, и при выдаче также отмечает вручение (например, сканируя QR-код клиента).
• Все движения на ПВЗ отражаются в базе маркетплейса, а для WMS цикл завершен в момент отгрузки с центрального склада. Такой подход проще для внедрения – не нужно расширять WMS на сотни мелких точек. Маркетплейс может реализовать более гибкий клиентский сервис (например, отслеживание в приложении, push-уведомления и т.д.) без доработки WMS. Недостаток – учет на ПВЗ придется дублировать (WMS не знает о складах ПВЗ, нужно следить, чтобы данные о невостребованных или частично выданных заказах возвращались обратно).

Рекомендация: Для небольших ПВЗ целесообразно не развертывать полноценную WMS, а вести учет силами системы маркетплейса, получая от WMS информацию о сформированных отправлениях. Однако важно наладить интеграцию: WMS при отгрузке будет передавать в маркетплейс данные (какая коробка/посылка и для какого заказа отгружена, в какой ПВЗ направляется). Далее маркетплейс берет эти данные в работу: при прибытии в ПВЗ посылка сканируется и помечается как «в точке выдачи». При выдаче клиенту – сканируется QR-код заказа, находят соответствующую посылку, и отмечают ее выданной. Таким образом, WMS покрывает «большую логистику» (складские комплексы и перемещение между ними), а ПО маркетплейса – «последнюю милю» (пункты выдачи).

Для сравнения, крупные игроки:

• Ozon интегрирует ПВЗ в общую логистическую сеть, однако их пункты выдачи работают под управлением собственного ПО, а не стандартной WMS. Основная WMS ведет учет до уровня маршрутизации отправлений по ПВЗ, а на самих точках выдачи — облегченные системы для сканирования и выдачи.
• Wildberries имеет собственные пункты выдачи, где реализована система сканирования полученных посылок и их хранения на стеллажах по кодам. Это похоже на мини-WMS, но встроено в их внутреннюю систему. Для сторонней WMS интеграция подобных функций часто неоправданна — вместо этого строят API-взаимодействие.

Таким образом, оптимально реализовать ПВЗ в рамках системы маркетплейса, но с передачей данных из WMS о высланных контейнерах (посылках). В особых случаях (крупные ПВЗ-хабы с большим товарооборотом) можно рассмотреть их как отдельные узлы WMS, но в общем – ПВЗ остаются конечной точкой выдачи под контролем OMS/CRM маркетплейса.

3. Генерация QR-кодов и штрихкодов для коробок, заказов и подзаказов

В системе будут использоваться различные коды для идентификации:

• Штрихкоды/QR на коробках (грузовых местах) – наклейки на сами отправления (посылки), используемые для отслеживания и сканирования на этапах перемещения и выдачи.
• QR-код заказа для клиента – код, отображаемый покупателю (в приложении или на сайте), по которому он получает свой заказ (или часть заказа) в пункте выдачи.
• Идентификаторы подзаказов – если заказ разбивается на несколько отправлений, каждой части понадобится свой код/номер для управления.

Где генерировать и на каком этапе:

• Маркировка коробок (посылок): Обычно генерируется на этапе упаковки заказа. Когда в WMS завершена комплектация и заказ упакован в короб, необходимо нанести этикетку. Этикетка содержит идентификатор отправления (например, номер отгрузки, код доставки или SSCC). Здесь возможны два подхода:

1. Маркетплейс генерирует код и передает в WMS: Например, маркетплейс заранее формирует уникальный номер отправления (или QR-код с информацией) и через API передает его в WMS для печати на этикетке. Это удобно, если код должен содержать данные, известные маркетплейсу (номер заказа, пункт выдачи, проверочный код и т.п.). WMS в этом случае просто выводит предоставленный код на принтер этикеток.
2. WMS генерирует код упаковки: Современные WMS могут самостоятельно создавать уникальные коды грузомест (например, SSCC – Serial Shipping Container Code). Yolka WMS поддерживает учет транспортных единиц без дополнительной маркировки – т.е. может присвоить коробу уникальный идентификатор. WMS может сгенерировать штрихкод или QR (например, на основе внутреннего номера отгрузки) и вернуть этот код во внешнюю систему. Маркетплейс затем ассоциирует его с заказом. На практике часто комбинируется подход: код этикетки содержит одновременно ID, понятный WMS, и ID, понятный маркетплейсу. Например, на этикетке можно закодировать GUID отгрузки из WMS, который сопоставлен в базе маркетплейса с номером заказа. Так при сканировании на выдаче система сможет по коду однозначно найти заказ и проверить статус.

• QR- и штрихкоды на уровне заказов/подзаказов: QR-код для клиента, как правило, формирует сам маркетплейс, т.к. он связан с учетной записью покупателя и показывается в мобильном приложении или высылается по email. Этот QR обычно шифрует идентификатор заказа или конкретного отправления, и используется при выдаче: сотрудник сканирует QR с телефона клиента, система на стороне маркетплейса определяет, какие посылки готовы к выдаче этому клиенту. Генерация такого кода происходит при оформлении заказа или при готовности к выдаче, и WMS тут не участвует. Однако важно, чтобы коды заказа и коды на коробках можно было соотнести. Возможны варианты:
• Один QR-код соответствует всему заказу, а если заказ разделён, то клиент с одним кодом может получать несколько коробок. В системе будет храниться привязка: заказ X состоит из отправлений A, B, C. Сотрудник ПВЗ сканирует QR заказа, видит все части и отмечает выдачу каждой поштучно.
• Либо каждому отправлению присвоен свой QR, и клиенту отображаются несколько кодов (по числу посылок). Например, Ozon присваивает каждому shipment свой трек-номер (штрихкод), и при поступлении в ПВЗ клиент может видеть несколько записей и кодов. Лучше генерировать единый QR на заказ, чтобы упростить жизнь покупателю; но тогда система на пункте выдачи должна уметь показать все связанные коробки.
• Стадия генерации: Штрихкод или QR на коробку обычно печатается сразу после упаковки. То есть, этап упаковки/маркировки в WMS – последний шаг комплектации заказа – должен либо запросить код у внешней системы, либо сгенерировать. В API Yolka WMS есть возможность завершать отгрузку и, вероятно, получить ее ID; этот ID может использоваться для формирования этикетки. Например, 1С:WMS допускает, что при создании заказа на отгрузку можно сразу указать номера контейнеров и их состав, либо распечатать этикетки грузомест по факту упаковки. Аналогично, Yolka WMS может формировать этикетки МХ-3 / отгрузочные акты после комплектации. В процессе интеграции следует решить, кто отвечает за формат этикетки. Обычно маркетплейс предоставляет шаблон (с логотипом, адресом ПВЗ, информацией для клиента), а WMS через интеграцию печатает по шаблону, подставляя переменные (ФИО, код заказа, штрихкод и т.д.).

Итого:

• Штрихкоды/QR для грузовых мест (посылок) целесообразно генерировать в момент упаковки заказа. Практически – при закрытии заказа на отгрузку в WMS. Либо WMS получает от маркетплейса уникальный код и печатает, либо генерирует сам и отдает маркетплейсу для учета.
• QR-код для заказчика генерируется маркетплейсом на уровне OMS и передается покупателю (в личный кабинет, приложение) заранее, до выдачи. Он может быть сгенерирован, когда все (или часть) позиций заказа готовы к выдаче.
• Коды подзаказов: если один заказ распался на N отправлений, уместно использовать различные идентификаторы отправлений. Например, заказать №1001-A, №1001-B – с отдельными штрихкодами на коробках. Маркетплейс должен хранить эту иерархию. Генерация таких под-номеров произойдет при разбиении заказа (логистическая часть, см. п.5 ниже), а печать – при сборке каждого отправления.

Примечание: При интеграции с конкретной WMS изучите ее API для печати этикеток. В Yolka WMS, судя по документации, реализована автоматизированная печать сопроводительных документов прямо из WMS – вероятно, можно печатать и этикетки. Убедитесь, что WMS получает все необходимые данные (например, адрес ПВЗ, ФИО клиента, код заказа) для вывода на этикетку в момент упаковки. Если нет – лучше сформировать этикетку на стороне маркетплейса и просто передать WMS штрихкод для учёта.

4. Планирование поставки товара продавцом на склад (FBO-интеграция)

Процесс поставки от продавца (то есть пополнение склада маркетплейса товарами) должен быть четко спланирован и отражен в обеих системах – у маркетплейса и в WMS. Обычно этот процесс выглядит так:

1. Создание заявки на поставку (ASN – Advanced Shipping Notice): Продавец через интерфейс маркетплейса оформляет поставку: указывает, какие товары и в каком количестве он намерен привезти, а также выбирает склад назначения и, возможно, удобную дату/время доставки. Например, на Ozon продавец в личном кабинете создает заявку FBO, перечисляет SKU и их количество, выбирает тип поставки (напрямую на склад или через распределительный центр) и желаемую дату. Эта заявка поступает в систему маркетплейса.
2. Передача информации в WMS (ожидаемая приемка): Система маркетплейса через API создает в WMS документ ожидаемого прихода. В терминологии WMS это может называться «Ожидаемая приемка» или «планируемая поставка», содержащая список товаров (номенклатур) и заявленное количество. Передаются следующие данные:

• Идентификатор поставки (например, номер заявки от маркетплейса) для связывания в будущем.
• Список SKU (артикулов) и количество каждой позиции. Важно использовать согласованный идентификатор товара – GUID номенклатуры WMS, либо артикул/штрихкод, по которому WMS сможет сопоставить.
• Указание отправителя (продавца) и получателя (склад маркетплейса). Если WMS поддерживает мультиклиентский режим, то может фиксироваться атрибут «владелец товара» = конкретный продавец.
• Желаемая дата поставки или слот времени (если используется расписание приемок).
• Информация о грузовых местах, если известна: например, продавец может разметить поставку по коробкам/паллетам сразу. В Ozon продавцу предлагается указать состав грузомест – сколько коробок или паллет, и что в них лежит. Эти данные тоже желательно передать в WMS, чтобы ускорить приемку (WMS сможет ожидать определенное количество паллет с определенным содержимым). Созданный документ «Ожидаемая поставка» резервирует временно ячейки приемки и позволяет складу подготовиться.

1. Доставка товара и приемка в WMS: Продавец привозит товар на склад (согласно согласованному времени). При выгрузке на рампе сотрудники склада осуществляют приемку с помощью WMS. Процесс:

• Сотрудники сканируют каждый товар или коробку. Если товары промаркированы штрихкодами (что обязательно), WMS идентифицирует SKU. Согласно заявке, WMS ожидает X штук; оператор подтверждает фактическое количество.
• Возможны два сценария: поштучная приемка (каждую единицу сканируют) или приемка по коробам/паллетам (если использованы этикетки грузомест). Например, WMS24/1С:WMS позволяет оформлять приемку по грузовым местам, особенно для транзитных грузов. Если поставка идет транзитом сразу под заказ (кросс-док), товар может не размещаться на хранение, а сразу направляться на отгрузку – но в нашем случае это скорее поставка на склад на хранение.
• После сканирования и пересчета каждой позиции WMS сравнивает факт с планом:
  • Если все в порядке: все позиции приняты полностью.
  • Если есть расхождения: например, недостача 2 шт или обнаружены лишние/несоответствующие товары – WMS фиксирует эти отклонения.
• По завершении приемки WMS закрывает документ «Приемка» (на основе ожидаемой поставки). Автоматически могут сформироваться документы: акт приемки МХ-1 (в российской практике), а также сопроводительные документы при необходимости (УПД, сертификаты – если интеграция с контуром ЭДО). Yolka WMS, в частности, имеет функцию автоматической отправки актов на email клиента – например, МХ-1 после приемки.

1. Обработка данных после приемки: После завершения приемки WMS передает данные обратно в систему маркетплейса (либо маркетплейс запрашивает):

• Подтверждение, что поставка принята (полностью или частично).
• Фактическое количество принятых единиц по каждому SKU. Эти данные позволят маркетплейсу обновить остатки на складе для данного продавца.
• Отчет о расхождениях: какие позиции и в каком количестве не приняли (например, не довезены или брак). Если что-то не принято, маркетплейс может уведомить продавца и скорректировать его ожидаемый остаток.
• Идентификаторы приемочных документов: номер приходного ордера, дата приемки, может быть скан-копия акта. Это важно для юридического оформления приема на ответственное хранение.
• Если WMS присваивает внутренние ID партиям или грузовым местам, в большинстве случаев маркетплейсу они не нужны. Однако, если, к примеру, маркетплейс показывает продавцу статус по коробкам, можно передать и внутренние номера паллет/коробов (для прозрачности).

1. Размещение товара: После приемки WMS создает задания на размещение (putaway) товаров на складские ячейки. Этот шаг внутри WMS (маркетплейсу о нем знать не нужно детально, кроме случаев, когда нужен статус «в размещении»). В результате товар становится доступен для заказов. В некоторых WMS товар считается доступным только после полного закрытия приходной поставки и выполнения операций размещения. Однако современные системы могут показывать остаток «на приемке» – маркетплейс может условно отобразить товар как доступный через некоторое время после приемки.

Пример (Ozon): Продавец создает заявку на поставку, указывает товары, дату и место. Он же указывает, сколько будет коробок/паллет и что в них. Получив эти данные, Ozon планирует приемку. Приехав на склад, продавец сдаёт все товары сразу (частями завозить нельзя), сотрудники склада проверяют соответствие. После приемки продавец в личном кабинете видит результаты – сколько единиц принято на каждый склад. Аналогичный принцип мы реализуем: данные в WMS о приемке синхронизируются с маркетплейсом, чтобы обновить доступные остатки.

Итак, данные, передаваемые в WMS перед поставкой: номер поставки, список товаров с количеством, идентификаторы (коды) товаров, данные о грузоместах, поставщике, назначении. Данные, возвращаемые из WMS после приемки: подтверждение поставки, фактические принятые количества, информация о завершении операции (акты, статусы). Это двусторонний обмен через API, обеспечивающий точный складской учет и информирование продавца.

5. Цикл движения товаров от продавцов до покупателей (пример с заказом из 3 товаров разных продавцов)

Сценарий: Покупатель оформил заказ, в котором 3 товара: например, ручка (продавец А), макароны (продавец Б) и сметана (продавец В). Предположим, эти товары изначально находились на разных складах сети (или в разных зонах одного склада) и требуют консолидации для доставки. Рассмотрим полный цикл – от поставки товаров на склады маркетплейса до вручения покупателю, с учетом частичной выдачи:

1. Поставка товаров продавцами на склад маркетплейса:

• Продавец А отправляет партию своих товаров (включая ручки) на склад №1 маркетплейса или в распределительный центр. Продавец Б – свои макароны, продавец В – сметану (скоропортящийся товар, требующий особых условий хранения, возможно холодильной зоны).
• Эти поставки проходят процесс, описанный в п.4: приемка через WMS, размещение на складах. Например, ручки и макароны размещены на основном складе (зоне сухих товаров), а сметана – на складе с холодильным оборудованием или специальной секции (либо на том же складе, но в холодильной камере, которую WMS отслеживает как отдельную зону хранения с ограничением по срокам годности).
• После приемки все товары доступны для заказа: WMS знает текущие остатки, а маркетплейс обновил карточки товаров как «в наличии на складе».

1. Размещение заказа и разбиение на отгрузки:

• Покупатель оформляет заказ через маркетплейс. OMS (система управления заказами маркетплейса) проверяет наличие каждого товара и резервирует их на складе. Здесь интеграция с WMS важна: маркетплейс либо заранее вел учёт остатков, либо делает онлайн-запрос в WMS. Предположим, ручка есть на складе №1, макароны – там же, а сметана – на складе №2 (либо на том же складе, но в другой температурной зоне).
• Маркетплейс может принять решение, как доставлять этот заказ. Варианты:
  • Единая консолидация: собрать все товары вместе и доставить одной посылкой. Это требует, чтобы товары встретились физически до пункта выдачи. Например, можно организовать, что склад №2 отправит сметану на склад №1 или в распределительный центр, где добавят ручку и макароны в ту же посылку.
  • Раздельные отправления: отправить товары разными посылками прямо в пункт выдачи (или покупателю), т.е. фактически сделать подзаказы по складам. Например, со склада №1 отправить ручку+макароны, а со склада №2 отдельно – сметану, потому что она хранится в холодильнике и может идти с охлаждением.
• На практике крупные маркетплейсы (Ozon, Wildberries) делят заказ на несколько отправлений, если товары находятся на разных складах или требуют разных условий доставки. В нашем случае сметану, скорее всего, отправят отдельно (из-за температуры), а ручку с макаронами – либо вместе, либо тоже раздельно, если, к примеру, разные продавцы/склады.
• Предположим, система решила сделать 2 отправления: посылка №1 (ручка + макароны со склада №1) и посылка №2 (сметана со склада №2, охлажденная). Таким образом, создаются два документа «заказ на отгрузку» в соответствующих WMS:
  • В WMS склада №1: заказ на отгрузку, включающий ручку и макароны.
  • В WMS склада №2: заказ на отгрузку на сметану.
• Каждый такой документ имеет свой уникальный идентификатор (подзаказ). OMS маркетплейса знает, что эти подзаказы принадлежат одному клиентскому заказу, но WMS обрабатывают их независимо.

1. Отбор и упаковка на складах:

• На складе №1: WMS получает задачу подобрать 1 шт артикул «ручка» и 1 шт «макароны» для отгрузки. Система планирует маршрут отбора: например, ручки лежат в ячейке A-101, макароны – в B-205. Сборщик выполняет задание с терминалом сбора данных: идет по адресам, сканирует товары. В процессе WMS может применять кластерный отбор или волновой, но в данном примере объем малый – можно подобрать последовательно и принести на упаковку.
  • После отбора товары консолидационно упаковывают: скорее всего, они поместятся в одну коробку. Упаковщик проверяет содержимое (сканирует штрихкоды товаров, сверяет с заказом) и запечатывает коробку.
  • На коробку печатается этикетка (сгенерированная как описано в п.3). Коробка №1 готова к отправке, связанной с подзаказом №1 (ручка+макароны).
  • WMS отмечает заказ на отгрузку №1 как собран и готов к отгрузке.
• На складе №2: Параллельно (или последовательно) WMS склада №2 обрабатывает заказ на сметану. Здесь важны условия: сметана может храниться в холодильнике, WMS знает срок годности. При отборе система должна выбрать самую свежую подходящую единицу (с учетом FIFO по срокам годности).
  • Сборщик в холодильной зоне отбирает нужное количество (1 банку сметаны), приносит на упаковку (возможно, в специальный изотермический контейнер или обкладывает холодоэлементами – вне рамок WMS, но по процессу).
  • Упаковка маркируется этикеткой. Это посылка №2.
  • WMS склада №2 закрывает заказ на отгрузку №2 как готовый.

1. Межскладская логистика (распределительный склад):

• Теперь у нас две готовые посылки в разных местах. Нужно доставить их к покупателю или в его пункт выдачи.
• Распределительный склад в инфраструктуре может играть роль транзитного хаба. Возможны два сценария:
  1. Консолидация через распределительный центр: обе посылки отправляются из своих складов на распределительный склад, чтобы затем единым рейсом поехать в город покупателя. Например, склад №1 и склад №2 находятся в разных городах, а распределительный центр – в регионе покупателя. Тогда:
     • Со склада №1 посылка №1 отправляется как груз в РЦ (оформляется накладная, транспортировка).
     • Со склада №2 посылка №2 тоже отправляется в РЦ.
     • На распределительном складе они прибывают, сканируются и формально приходят на учет РЦ (как транзитные грузы). Возможно, их сгруппируют: если они идут в один пункт выдачи, можно даже вложить одну коробку в другую или связать их. Но чаще всего они остаются отдельными.
     • Затем РЦ формирует партию грузов на маршрут доставки, включая обе посылки, и отправляет их в соответствующий город/ПВЗ.
  2. Прямая отправка в пункт выдачи: если логистика настроена эффективно, каждый склад может отправлять посылки напрямую в нужный ПВЗ (или ближайший сортировочный центр региона покупателя). Например, склад №1 отгружает посылку через курьерскую службу прямо на адрес ПВЗ, склад №2 делает то же. В пункте выдачи в итоге по разным каналам прибывают две посылки для одного клиента.
  Выбор сценария зависит от географии и организации: распределительный склад часто используют для централизованной консолидации потоков (если склады находятся далеко и необходимо собрать отправления к общему маршруту). В других случаях это лишнее звено – тогда отправляют отдельно. В нашей архитектуре возможно:
• Распределительный склад (5000 м²) служит буфером и сортировочным центром для отгрузок в разные регионы. Он может не хранить товар постоянно, но через него проходят межскладские перевозки (это и есть кросс-докинг – функция, поддерживаемая Yolka WMS).
• Предположим, склад №1 и №2 – оба центральные, а РЦ – региональный: тогда обе посылки идут транзитом через РЦ к ПВЗ.

1. Доставка в пункт выдачи:

• Независимо от маршрута, обе коробки должны прибыть в выбранный покупателем пункт выдачи. Пусть пункт выдачи – в городе покупателя.
• Посылка №1 и №2 приходят (вместе или по отдельности) в ПВЗ. Сотрудник ПВЗ принимает их:
  • Сканирует штрихкод на коробке №1, регистрируя, что посылка поступила. Она помещается на хранение (например, на полку с адресом).
  • Аналогично для коробки №2 (может прибыть позже или раньше первой; в условиях частичной выдачи не обязательно ждать все).
• Система маркетплейса оповещает покупателя: часть вашего заказа прибыла в пункт выдачи. Например, после поступления первой посылки клиент получает уведомление «Товар X готов к получению, остальные в пути».
• Если политика сервиса предполагает ждать полного комплекта – можно уведомлять после всех. Но по условию задачи покупатель может забрать заказ частично, значит уведомления и выдача происходят по мере поступления каждой части.

1. Выдача заказов покупателю (частичная):

• Покупатель приходит в пункт выдачи. Допустим, на этот момент в ПВЗ уже есть посылка с ручкой и макаронами, но сметана еще не приехала (или наоборот).
• Клиент показывает свой QR-код заказа (или несколько кодов отправлений). Сотрудник сканирует:
  • Система находит заказ и видит, какие отправления доступны к выдаче. Например: «Отправление №1 (ручка+макароны) – на месте, Отправление №2 (сметана) – в пути».
  • Сотрудник выдает то, что есть: идет к полке, берет посылку №1, сканирует ее штрихкод для контроля, отдает клиенту. Система помечает эту посылку как выданную. WMS при интеграции может либо не учитывать ПВЗ (тогда маркетплейс сам снимет остаток), либо если ПВЗ был как склад – WMS списывает контейнер с баланса ПВЗ.
  • Покупатель подтверждает получение подписью или кодом. Он уходит с частью заказа.
• Спустя время прибывает вторая посылка (сметана). Клиент может прийти снова. Ему вновь сканируют QR, видят, что осталось 1 отправление. Выдают его аналогично.
• В итоге заказ закрывается полностью после выдачи последней части. Если бы клиент не пришел за второй частью – по истечении срока хранение сметану вернули бы на склад, но это другой сценарий (возврат).

1. Особые моменты:

• Температурный режим: сметана – скоропортящийся продукт, требующий холода. На этапе доставки в ПВЗ нужно обеспечить холодовую цепочку. Вероятно, это учтено в выборе маршрута: возможно, такой товар доставляется быстрее и отдельно (что мы и сделали). В ПВЗ его хранят в холодильнике (если есть) или ограниченное время.
• Разные продавцы: в примере товары от разных поставщиков. Но на складе они хранятся вместе (общий пул, разделенный по владельцу в системе). WMS должна поддерживать мультиклиентский учет, чтобы товар А, Б, В был разнесен по учетным признакам (в Yolka WMS это возможно, т.к. заявлено управление несколькими складами и запасами нескольких клиентов). При отборе для заказа не имеет значения, чей товар – главное, что он числится в наличии. После продажи маркетплейс сам рассчитает вознаграждение и спишет со счета продавца.
• Учет частичной выдачи: После выдачи первой части заказа, система должна отразить, что часть заказа исполнена. Покупатель, возможно, оплачивает все сразу онлайн, либо каждая часть может иметь отдельный платеж (но обычно оплата единовременная, а частичная выдача оформляется как несколько отгрузок под одну оплату). Маркетплейс в личном кабинете клиента может показывать статус: «1 посылка получена, 1 ожидает».
• Возвраты: Если покупатель, например, не забрал сметану вовремя, ПВЗ отправит ее обратно. Тогда WMS должна будет оприходовать возврат на склад продавца или на отдельный участок.

От склада до покупателя кратко: товары разных продавцов приезжают на склад → хранятся до заказа → при заказе резервируются и собираются в посылки по оптимальным маршрутам → едут либо через РЦ, либо напрямую в ПВЗ → в ПВЗ сканируются и хранятся → покупатель приходит с QR-кодом, получает каждую часть по мере ее прибытия.

Такая раздельная схема соответствует практике крупных маркетплейсов: Ozon, например, делит заказ на несколько отправлений, если товары на разных складах или от разных продавцов, именно чтобы оптимизировать доставку и не задерживать одни товары из-за других. В нашем примере это реализовано аналогичным образом.

6. Как делают Ozon и Wildberries (аналогичные процессы)

Ozon: Крупнейший российский маркетплейс, использует гибридную сеть фулфилмент-центров и доставку:

• Модель FBO (Fulfillment by Operator): похожа на наш сценарий – товары хранятся на складах Ozon. Продавцы завозят товары на склады Ozon по заявкам (через личный кабинет, с указанием состава поставки и грузомест). Ozon принимает товары, размещает и далее сам обрабатывает заказы клиентов. Когда клиент заказал несколько товаров, система Ozon:
• Проверяет, на каких складах лежат товары. Если все в одном – закажет оттуда. Если в разных – разделит заказ на несколько отправлений по складам.
• Некоторые категории отделяются автоматически: например, Ozon Fresh (продукты питания с особыми условиями) всегда доставляются отдельно от обычных товаров. Большегабарит тоже едет отдельно.
• На складах Ozon внедрены современные WMS, интегрированные с системой управления заказами. Отбор заказов, упаковка и отправка максимально автоматизированы, что позволяет обрабатывать тысячные объемы ежедневно. Например, практикуются волновые отбора, конвейерная сортировка заказов, роботизация.
• Каждое отправление получает свой штрихкод/код отслеживания. При поступлении в пункт выдачи (или к курьеру) эти отправления сканируются. Клиент видит в приложении несколько посылок, если заказ разделён.
• Частичная выдача: по сути, если заказ раздельный, клиент получает их как отдельные доставки. Ozon информирует покупателя о разделении заказа заранее: в личном кабинете может быть написано «Ваш заказ прибудет несколькими отправлениями». Клиент может получать их в разное время. Это считается нормальным процессом.
• Модель FBS (Fulfillment by Seller): в контексте вопроса не столь актуальна, но у Ozon она тоже есть. Там продавцы сами отгружают клиентам, а склады Ozon не участвуют. Однако для нас важнее FBO, где складской цикл аналогичен нашему описанию.
• IT-система Ozon: Ozon использует собственные разработки и, по некоторым данным, интегрировал несколько WMS-решений (возможны иностранные до 2022 г., теперь могут быть российские). В любом случае, WMS тесно интегрирована с OMS: автоматически создаются задания на сборку при появлении заказа, учитываются приоритеты по SLA доставки, ведется отслеживание статуса каждого отправления. Благодаря этому, Ozon может обеспечивать доставку на следующий день и точно знать, где находится каждый товар.

Wildberries: Другой гигант, известен своей мощной логистикой:

• У Wildberries большая доля FBO (они требуют от продавцов поставлять товары на их РЦ). Продавец маркирует каждую единицу уникальным штрихкодом WB и привозит на склад. Приемка происходит поштучно, через систему WB.
• Wildberries имеет централизованный складской комплекс в Подмосковье и ряд региональных РЦ. Их модель – скорее дистрибутивная: товары могут располагаться в разных регионах ближе к покупателям. Поэтому, когда клиент заказывает несколько товаров:
• Если все товары есть в одном РЦ – получит одной посылкой.
• Часто товары на разных складах – тогда заказ также распадается на несколько доставок. Wildberries не ждет консолидации, а отправляет что есть. Клиенты привыкли, что заказ может прийти частями. Например, книжка пришла завтра, а футболка – послезавтра другим отправлением.
• Отличие WB – они позволяют примерку и частичный отказ прямо на пункте выдачи. То есть клиент может не забрать некоторый товар, и это оформляется возвратом. Для этого каждая единица товара имеет свой уникальный штрихкод на этикетке, и при выдаче/возврате сканируется индивидуально. Это требование влияет и на процесс приемки: еще на этапе поставки продавец клеит эти этикетки на каждую штуку.
• С точки зрения WMS: Wildberries разработали собственную систему, которая сочетает складской учет и функциональность торгового зала на ПВЗ. Их WMS (условно называем так) отслеживает движение каждой единицы. Например, если клиент не выкупил товар, система знает, что эта штука вернулась на склад и снова доступна.
• Пункты выдачи Wildberries: фактически действуют как мини-склады временного хранения. Товары на ПВЗ хранятся до 7 дней, и WB тщательно контролирует их перемещение. Можно сказать, у них единая система от центрального склада до ПВЗ. Но это custom solution: стороннюю WMS так использовать было бы сложно, поэтому WB – исключение за счет полного контроля IT.

Вывод по Ozon/WB: Оба маркетплейса реализуют похожие принципы:

• Многоскладская сеть с стратегическим распределением запасов.
• Разбиение заказов на части по необходимости (разные склады, продавцы, категории).
• Отслеживание каждого отправления и автоматизация процессов отбора/упаковки (через WMS).
• Использование штрихкодов/маркировки на уровне отправлений и товаров для точного контроля.
• Возможность частичной доставки и получения. Это считается частью клиентского сервиса, хотя и увеличивает логистические издержки.

При проектировании собственной архитектуры эти практики можно брать за основу. Например, реализовать алгоритмы автоматического разделения заказа на оптимальные отправления, как делает Ozon, с учетом:

• расположения товаров (склад А или Б),
• типа товара (обычный или особый),
• габаритов (не положить же холодильник с зубной пастой вместе – их разделят).

WMS-система должна поддерживать такие сценарии – как мы обсудили, это достигается созданием нескольких заказов на отгрузку внутри WMS. Система маркетплейса же будет решать, сколько таких заказов создать на основании бизнес-правил.

7. Сущности и процессы типичных WMS, применимые в модели маркетплейса

Чтобы эффективно интегрировать WMS и маркетплейс, важно понимать, какими базовыми сущностями оперирует WMS и как их отразить на процессах маркетплейса. Ниже приведены основные сущности WMS и их роль в нашем контексте:

Сущность WMS	Описание и роль
Номенклатура (SKU)	Единица товара, известная WMS. В нашем случае каждый товар от продавца регистрируется как SKU в WMS. Необходимо хранить соответствие SKU между маркетплейсом и WMS (например, через GUID или артикул). Для маркетплейса важно, что WMS может хранить атрибуты SKU: вес, габариты, штрихкод производителя, а также владельца товара (продавца) для мультиклиентского учета.
Партия / Серия	Если товар сертифицируется по партиям или имеет срок годности, WMS ведет учет партий. В примере со сметаной – у каждой банки партия с датой производства. WMS фиксирует эти данные при приемке и учитывает при отборе (FIFO по срокам годности). Маркетплейсу напрямую партии могут быть не видны, но косвенно влияют (товар просрочен – не отгружать).
Локация (ячейка)	Конкретное место хранения на складе (адрес). В WMS все товары лежат где-то: зона хранения, адрес ячейки. Для маркетплейса детализация до ячейки не нужна, но важно разделение по складам и зонам. Например, у нас могут быть зоны: «хранение продавца А», «охлаждаемая камера», «зона отгрузки», «буфер консолидации». WMS управляет перемещением между локациями, обеспечивая точность остатков (99,9% при адресном хранении).
Остатки (Stock)	Количество товара на складе в конкретном месте. WMS знает текущий остаток каждого SKU. Маркетплейсу эти данные нужны агрегировано по складам (чтобы показывать на сайте наличие). Интеграция должна синхронизировать остатки: либо маркетплейс периодически запрашивает остатки у WMS, либо WMS отправляет события об изменении остатков.
Ожидаемая приемка / Заявка на поставку	Документ планируемого поступления товара (см. п.4). Маркетплейс инициирует, WMS хранит и контролирует фактическую приемку. По нему происходит приемка (Inbound): операция регистрации прибывшего товара. Приемка – важнейший процесс WMS, автоматизирующий ввод новых остатков. После приемки WMS может автоматически отправлять отчет (акт).
Заказ на отгрузку (Sales Order / Shipment Order)	Документ, отражающий заказ клиента к выполнению. Формируется через интеграцию по триггеру заказа. Содержит позиции заказа. В WMS на основе него планируется отбор (Picking). В нашем случае один клиентский заказ может соответствовать нескольким заказам на отгрузку (подзаказам) – WMS не знает о связях между ними, это знает маркетплейс.
Отбор (Picking) / Задание на отбор	Конкретная задача для оператора: взять X штук SKU Y из ячейки Z для определенного заказа. WMS генерирует такие задания автоматически, оптимизируя маршрут и стратегию (например, собирает несколько заказов сразу, группирует по зонам и т.п.). Маркетплейс эти подробности не видит, но должен знать статусы: «Отбор начат», «Комплектация завершена».
Волна (Wave) / Группа отбора	Объединение нескольких заказов для одновременного отбора. В e-commerce складах часто используют волновой или кластерный отбор для эффективности. Для интеграции это прозрачно – маркетплейсу не важно, что его заказ собирался вместе с другими, но важно время выполнения.
Контейнер / Грузоместо	Единица упаковки, в которую складываются товары при отборе. Может использоваться и на этапе приема (паллета – тоже грузоместо). WMS позволяет регистрировать контейнеры и их содержимое. В нашем контексте контейнер – это, например, короб с заказом. WMS присваивает ему номер (штрихкод). Далее контейнер перемещается как целое: на упаковку, в зону отгрузки, в машину, в ПВЗ. Маркетплейс тоже оперирует понятием посылки, поэтому контейнер WMS = посылка маркетплейса.
Зона отгрузки / ожидания	В WMS обычно есть специальные локации: зона комплектации (packing station), зона отгрузки (dock area). После сбора заказ перемещается в зону отгрузки, ожидая отправки. У нас это момент, когда посылка готова, но еще не ушла. WMS может группировать отгрузки по маршрутам, машинам или ПВЗ. Маркетплейсу важно знать, когда отправление фактически «ушло со склада» – тогда он меняет статус заказа на «в пути». Это происходит, когда WMS фиксирует отгрузку из зоны отгрузки (например, оформляет рейс).
Рейс / Маршрут доставки	Документ, объединяющий несколько отгрузок, которые едут одним транспортом по определенному маршруту. Например, машина, следующая по маршруту: Склад→ПВЗ1→ПВЗ2. В WMS может быть документ «Рейс», куда включены заказы на отгрузку для этих ПВЗ. Маршрут может создаваться на основании внешней TMS или вручную. Маркетплейс может не получать эти подробности, но может получать прогнозы доставки на основе маршрута.
Перемещение (Transfer)	Операция перемещения товара внутри склада (между ячейками) или между складами. В межскладском случае может оформляться как отгрузка с одного склада и приемка на другом. В рамках интеграции, если товар перемещается (например, пополнение одного склада с другого), маркетплейс может быть уведомлен о смене места хранения. Но в нашем сценарии межскладовые перемещения происходят под заказ (см. распределительный склад) – это часть процесса доставки.
Инвентаризация (Stock Count)	Проверка остатков. WMS проводит циклические пересчеты, снимая ячейки с операций. Маркетплейсу достаточно получать скорректированные остатки, если выявлены расхождения.
Возврат	Товар, возвращенный от клиента или от брака. WMS оформляет прием возврата, возвращает на склад (в продажу или в брак). Маркетплейс через интеграцию узнает, что единица товара вернулась на баланс продавца (если выкуп не состоялся).

Вышеупомянутые сущности позволяют выстроить модель: Продавцы -> (заявка на поставку) -> Приемка (ожидаемая) -> Запас на складе (номенклатура, партия, место) -> Заказ клиента -> (заказ на отгрузку) -> Отбор (задания, волны, контейнеры) -> Упаковка (контейнер с этикеткой) -> Отгрузка (зона отгрузки, рейс) -> Доставка -> Выдача (списание со склада ПВЗ).

Для примера, Yolka WMS декларирует соответствие ГОСТ Р 59282-2020 (функциональные требования к WMS), то есть поддерживает все типовые функции. В частности, реализованы:

• Адресное хранение с высокой точностью учета,
• FIFO/LIFO стратегии отбора,
• Кросс-докинг,
• Учет транспортных единиц (SSCC),
• 3PL-модель (мультиклиентский учет), что важно для маркетплейса – товары разных продавцов ведутся раздельно в одной системе.

Примеры интерфейсов/API:

• API Yolka WMS: предоставляет REST endpoints для ключевых операций. Например, метод создания отгрузки (POST /shipment) и фиксации ее завершения доступен через Swagger. Также есть методы получения остатков, справочников (SKU, склады) – если неизвестен GUID номенклатуры, API позволяет искать по коду. Это облегчает интеграцию – можно оперировать артикулом продавца, а WMS найдет внутренний ID.
• Интерфейс мобильного терминала: Yolka WMS поддерживает ТСД (терминалы) – операторы видят задания на экране, сканируют штрихкоды и WMS онлайн обновляет статусы. На экране может отображаться, какой товар взять и куда положить (например, в контейнер №X для заказа).
• Интерфейс настольный: Обычно это веб-интерфейс с панелями мониторинга – видно, сколько заказов в работе, сколько ожидает отправки, статус каждой поставки и т.п. Скриншоты конкретно Yolka WMS трудно достать публично, но по отзывам интерфейс интуитивный, с поддержкой визуализации склада (2D/3D схемы).

В заключение, при проектировании архитектуры «маркетплейс – WMS» важно обеспечить, чтобы бизнес-сущности маркетплейса корректно отображались на сущности WMS. Тогда интеграция будет прозрачной: заказ – на отгрузку, поставка – на приемку, коробка – на контейнер, склад продавца – на признак владельца. Такой подход гарантирует универсальность: можно заменить Yolka на другую WMS (1С:WMS, Cleverence, WMS24 и др.), ибо все они оперируют схожими объектами. Крупные маркетплейсы успешно реализовали эти процессы, минимизировав ошибки при сборке заказов и ускорив операции. Следуя изложенным принципам, можно построить гибкую архитектуру, позволяющую масштабировать склады, подключать новых продавцов и обеспечивать высокий уровень сервиса для покупателей.