Сборщик вам не марафонец: мы связали 5 компонентов FBS-сборки, чтобы сократить путь между полками

Когда сборка привязана к ПК и стационарному сканеру, сотрудник несёт найденный товар к рабочему месту, подтверждает его и снова идёт к полкам. Чем больше заказов, тем чаще повторяется этот маршрут. ТСД переносит точку сканирования к товару: сотрудник за один обход подбирает позиции сразу для нескольких заказов, а у упаковочного стола распределяет их по заказам и печатает этикетки. Серверная часть продукта служит связующим слоем между Ozon, Wildberries, мобильным рабочим местом и «Честным знаком». Пятым подключаемым компонентом станет 1С.

В интерактивном демо можно переключиться между сборкой у стационарного ПК и подбором с ТСД, а затем сравнить длину маршрута. Та же разница показана на схеме ниже.

Мобильное рабочее место решает физическую часть задачи: сканирующий модуль ТСД считывает штрихкод или DataMatrix там, где сотрудник взял товар, а приложение фиксирует результат. Сам терминал не знает, какие заказы ждут на площадках, к какой поставке относится позиция, какую маркировку передать и где запросить этикетку. За эту логику отвечают серверная часть и коннекторы «Маркетплейса 15».

Дальше разберём, где проходит граница каждого компонента и как между ними движутся данные.

Где расходятся данные разных компонентов

FBS означает, что товар хранит и собирает продавец. Маркетплейс передаёт заказ и принимает изменения его состояния, но физически нужную футболку, банку или коробку с полки берёт сотрудник склада.

В этот момент одна складская операция оказывается представлена несколькими объектами.

Для Ozon это отправление, которое может состоять из нескольких товаров и грузомест. Для Wildberries отдельный товар является сборочным заданием, которое затем включается в поставку. Для «Честного знака» важны конкретный экземпляр маркированного товара и состояние его кода. На ТСД сотрудник видит последовательность действий: найти позицию, считать код и подтвердить результат.

Попытка свести всё к полю order_status быстро ломается. Одинаковая надпись «заказ собран» может скрывать разные наборы завершённых действий: товар найден, DataMatrix считан, код передан площадке, грузоместо создано, этикетка получена, заказ включён в поставку.

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

Как устроен контур

Если убрать интерфейсные детали, схема выглядит так:

У многих продавцов товарный учёт и оформление реализации ведутся в 1С. Интеграция выходит через неделю: здесь показываем её место в контуре, но подробности пока не разбираем. Следите за обновлениями.

Стрелки к Ozon и Wildberries двусторонние. «Маркетплейс 15» получает заказы и данные о товарах, передаёт площадкам результаты сборки и коды маркировки, а также отправляет запросы на смену состояния заказа и получение этикеток.

С «Честным знаком» соединяется серверная часть, а не сканирующий модуль ТСД напрямую. Для работы с маркировкой база устанавливается на компьютер или сервер с КриптоПро и ключом участника оборота. Облачный вариант без локального контура подходит для сценариев, где работа с маркировкой не требуется. Стабильный интернет обязателен: продукт обращается к личным кабинетам маркетплейсов в реальном времени и не рассчитан на автономную FBS-сборку.

Что должно быть настроено между сервером и «Честным знаком»

Этот канал состоит не из одного логина. Для подключения нужны OmsID, ИНН участника, идентификатор соединения и отпечаток сертификата УКЭП. OmsID и ИНН берут в профиле станции управления заказами, идентификатор соединения — в разделе «Устройства». Пароль от личного кабинета на ТСД не передаётся.

Криптографическая часть живёт на компьютере или сервере, где установлена база: там должен быть КриптоПро и доступный службе сертификат. Приложение на ТСД передаёт считанный DataMatrix серверу. Запрос к ГИС МТ подписывает серверный контур.

Из-за этой границы маркировку нельзя считать ещё одним прямым API-запросом с терминала. Если сервер не видит сертификат или соединение с СУЗ настроено неверно, сканирование может пройти, но проверка и дальнейшая операция с кодом не завершатся. Поэтому связь с ГИС МТ проверяют отдельно до начала массовой сборки.

Кто отвечает за заказ, сканирование и код маркировки

«Маркетплейс 15» не входит в список подключаемых компонентов: это связующий слой между ними. Заказы, физическое сканирование и состояние марки остаются в ведении исходных систем и мобильного рабочего места.

Такое разделение избавляет кладовщика от необходимости помнить, почему одна площадка называет объект отправлением, а другая сборочным заданием. Различия остаются внутри коннекторов и проявляются только там, где меняют складской сценарий.

Шаг 1. Получить заказы и не потерять особенности площадки

Коннекторы работают с API личных кабинетов, а не с веб-страницами площадок. Для Ozon нужны Client ID и отдельный API-ключ Seller API. В FBS-сценарии ключу дают роль Posting FBS, чтобы работать с отправлениями, и Admin read only, чтобы читать номенклатуру и другие справочные данные без административной записи.

В Wildberries вместо пары Client ID и ключа создаётся токен. Для описываемого контура ему нужны категории «Контент», «Поставки», «Маркетплейс» и «Аналитика». Доступ к ним выдают на чтение и запись: коннектор не только получает задания, но и меняет их состояние. Токен создают в личном кабинете продавца, а затем вводят в серверных настройках. На ТСД секрет не хранится.

API-ключ и токен показываются при создании, поэтому их сразу сохраняют в защищённом хранилище. В открытых документах и журналах обмена секреты маскируют. При компрометации ключ отзывают в кабинете площадки и выпускают новый.

После подключения коннекторы загружают заказы и номенклатуру в базу продукта. В приложении «Маркетплейс 15» на ТСД можно показать общий список двух площадок либо отфильтровать его по маркетплейсу, личному кабинету и складу. Параметры обоих кабинетов задаются при первоначальной настройке базы.

Единый список не означает единую модель данных. Для Ozon при завершении заказа может потребоваться распределить товары по нескольким грузоместам и получить этикетки для каждого из них. В Wildberries товар нужно связать с поставкой. Поставка выбирается из актуальных или создаётся на ТСД. Поэтому коннекторы не могут завершать заказы одинаково: Ozon ждёт данные по отправлению и грузоместам, а Wildberries — связь сборочного задания с поставкой.

Начало операции для двух площадок выглядит похоже: сотрудник выбирает заказ, видит позиции и сканирует товар. Завершение различается, потому что Ozon и Wildberries ожидают разные данные. Интерфейс не должен скрывать сведения, которые кладовщику необходимо указать до закрытия коробки.

Шаг 2. Подобрать несколько заказов за один проход

Для небольшого потока подходит прямая сборка: сотрудник открывает заказ, идёт по его позициям, возвращается к упаковке и завершает документ.

При потоке из нескольких заказов подбор и сортировку можно разделить. Операция «Сборка в тележку» формирует общий документ из нескольких заказов. Сотрудник выбирает маркетплейс, склад, при необходимости личные кабинеты и ограничение по числу строк. Затем проходит по зоне хранения и собирает одинаковые товары сразу для нескольких заказов.

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

Это двойная сортировка, поэтому число действий не сокращается автоматически. Цель сценария в другом: реже возвращаться от упаковочного стола к одним и тем же полкам. Для склада с уже упакованным товаром или небольшим числом позиций прямая сборка может оказаться проще. Поэтому оба сценария существуют параллельно.

Шаг 3. Зафиксировать физический товар там, где он оказался в руке

До сканирования система знает, что нужно найти. После сканирования в операции появляется конкретный товар, который сотрудник положил в заказ.

Для обычного товара достаточно штрихкода. Для маркированной позиции нужно считать DataMatrix конкретного экземпляра. Приложение может сверить GTIN из марки с товаром, сохранить связь кода с заказом и передать данные нужной площадке. Связь с ГИС МТ проверяется отдельной настройкой, чтобы проблема с доступом к маркировке обнаружилась до начала массовой сборки.

Сканирующий модуль передаёт считанный код приложению на ТСД. Приложение сопоставляет его с заданием и фиксирует результат операции. Правила Ozon, Wildberries и «Честного знака» при этом остаются на стороне соответствующих систем и коннекторов.

Проверку трудно перенести на конец смены без риска потерять связь между товаром и заказом. После упаковки приходится заново выяснять, какой DataMatrix оказался в конкретной коробке.

Шаг 4. Завершить заказ и дождаться внешних систем

Кнопка «Завершить» в приложении «Маркетплейс 15» на ТСД запускает цепочку обменов с внешними системами.

Для Ozon серверная часть «Маркетплейса 15» передаёт данные собранного отправления и марки, учитывает распределение по грузоместам и получает этикетки. Для Wildberries коннектор привязывает заказ к поставке и передаёт необходимые сведения в сборочное задание, после чего сотрудник может напечатать стикер товара.

Внешняя площадка может отвечать с задержкой, а этикетка ещё генерироваться. Для отправки марок в Ozon предусмотрен тайм-аут: операцию можно прервать без перезапуска приложения и повторной сборки заказа. Для повторной печати есть отдельная операция «Этикетка маркетплейса».

Есть и промежуточный сценарий. Вместо финальной этикетки на упаковку печатается временный QR заказа. Позже сотрудник сканирует его и получает актуальную этикетку маркетплейса. Так физическую коробку можно идентифицировать, пока внешний сервис или сеть отвечают дольше обычного.

Шаг 5. Не смешивать статус заказа и статус марки

Заказ может быть собран, передан в доставку, выдан покупателю или возвращён. Код маркировки живёт в другой системе состояний. Он может находиться в обороте, ожидать вывода, быть выведен или требовать разбора ошибки.

В описываемом FBS-сценарии продавец передаёт сведения о выводе товара из оборота. Маркетплейс принимает код в составе данных заказа, но источником состояния марки остаётся ГИС МТ.

Статус заказа служит условием для следующего действия с кодом, но не копируется в статус марки. «Маркетплейс 15» сохраняет связь заказа с отсканированным DataMatrix и выполняет настроенный обмен с «Честным знаком». Смена статуса заказа и вывод кода из оборота остаются двумя разными этапами, даже если один следует за другим.

Ограничения действующего контура

Контур работает онлайн. Заказы, статусы и этикетки приходят из внешних систем, поэтому при потере связи их нельзя актуализировать. Автономная FBS-сборка без доступа к маркетплейсам продуктом не предусмотрена.

Ozon и Wildberries нельзя полностью спрятать за одной универсальной сущностью. Общий интерфейс полезен, пока он не стирает важные для операции различия: поставки Wildberries и грузоместа Ozon.

Сканирование и успешная отправка данных происходят не одновременно. Товар уже может лежать в коробке, пока внешний API принимает марки или формирует этикетку. Поэтому физический подбор и обмен с площадкой нужно рассматривать как два этапа одной операции.

Для маркированных товаров сервер продукта размещается рядом с КриптоПро и ключом участника оборота. Это отдельная граница развёртывания и поддержки.

Один сценарий на ТСД, «Маркетплейс 15» в центре

На экране ТСД процесс выглядит последовательно: выбрать заказ или тележку, отсканировать товары, при необходимости считать DataMatrix, распределить по грузоместам, завершить сборку и напечатать этикетку.

Сейчас «Маркетплейс 15» связывает Ozon, Wildberries, мобильное рабочее место и «Честный знак». После ближайшего релиза 1С станет пятым подключаемым компонентом. Каждый источник продолжит отвечать за свой объект, а связующий слой будет передавать между ними данные, необходимые на очередном этапе операции.

Лишние перемещения сокращает сама организация подбора. Сотрудник работает с текущим заданием на ТСД, может собрать несколько заказов в одну тележку, а у упаковочного стола распределить товары и напечатать нужные этикетки. Считанные коды остаются связанными с заказами и не требуют повторного ручного ввода.