Сборка заказов FBS с нескольких маркетплейсов: один список, этикетки, сканер и контроль сроков отгрузки

Короткий ответ: при FBS на нескольких площадках сборку ломает не объём, а то, что заказы живут в трёх кабинетах с разными артикулами, этикетками и сроками. Решение — забирать задания по API в один лист подбора по вашим ячейкам, печатать этикетки пачкой в порядке сборки, проверять каждую позицию сканером и видеть ближайший срок отгрузки на одном экране. Это можно собрать в готовом сервисе или своей программой — выбор зависит от того, насколько ваш склад похож на типовой.

Ниже — операционка склада продавца: что происходит между «пришёл заказ» и «поставка уехала». Чем схемы FBO, FBS и DBS отличаются и какие данные ходят по API, разобрано в статье «FBO, FBS или DBS»; здесь не повторяем. Штрафы и точные часы на сборку не называем: они зависят от площадки, склада и вашего договора с ней, сверяйте их в кабинете продавца.

Почему сборка по трём кабинетам ломается при росте заказов?

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

Типичная картина у продавца, который вырос с одной площадки до трёх:

• Три обхода склада вместо одного. Сначала собирают Wildberries, потом Ozon, потом Маркет — и трижды подходят к одной и той же полке.
• Разные названия одного товара. В каждом кабинете свой артикул и своё название, а на полке — ваш артикул. Сборщик переводит в уме и ошибается на похожих позициях.
• Этикетки по одной. Каждую скачивают и печатают отдельно, а потом ищут, к какому пакету она относится.
• Нет общей картины по срокам. Чтобы понять, что горит, надо открыть все кабинеты по очереди.
• Остаток узнают последним. Товар, который только что ушёл в заказ на одной площадке, продолжает продаваться на другой, и сборщик находит пустую полку.

У Wildberries есть и своя особенность: по документации API «Заказы FBS» одно сборочное задание всегда равно одной единице товара. Покупатель взял пять одинаковых футболок — у вас пять заданий и пять стикеров; объединить их в одну посылку помогает общий идентификатор корзины orderUid. Кто не знает об этом, считает заказы неправильно и путается при упаковке.

Поле	Откуда берётся	Зачем сборщику
Ячейка или полка	Ваш справочник мест хранения	Обход склада по порядку, без возвратов к той же полке
Ваш артикул и название	Учёт: 1С, МойСклад или таблица	Один язык для всех площадок вместо трёх разных артикулов
Штрихкод товара	Карточка товара	Проверка сканером, что взяли именно эту позицию
Количество	Сумма заданий по позиции	Сразу снять с полки нужное число, а не ходить по одной штуке
Площадка и номер задания	API площадки	Разложить взятое по заказам и наклеить нужную этикетку
Срок отгрузки	Данные заказа на площадке	Видеть, что собирать первым
Отметка «нужна маркировка»	Требования площадки к заданию	Не забыть отсканировать код при упаковке

Как устроен единый лист подбора?

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

Лист подбора — это не выгрузка из кабинета. Его строит программа из трёх источников: новые задания с площадок, ваш справочник товаров и справочник мест хранения. Порядок строк — по маршруту обхода склада, а не по номеру заказа.

Работают обычно в две волны:

1. Подбор. Сборщик идёт по листу, берёт товар по ячейкам и складывает в тележку или ящик. На этом шаге площадки не важны — важны артикул и количество.
2. Раскладка и упаковка. У стола каждую единицу сканируют, программа говорит, в какой заказ она идёт, и печатает этикетку нужной площадки. Заказ из нескольких позиций закрывается, когда отсканированы все.

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

Этикетки и маркировка: что печатать?

Для FBS печатают три вида наклеек: этикетку на каждый заказ, стикеры на коробки или грузоместа поставки и документ на передачу. Код маркировки «Честного знака» не печатают — его сканируют с упаковки и закрепляют за заказом, если товар маркируемый.

Что важно знать по площадкам:

• Wildberries. Стикер задания по API запрашивают в размере 58×40 или 40×30 (картинка 580×400 или 400×300 пикселей) в форматах SVG, PNG или ZPL (вертикальный и горизонтальный), до 100 штук за запрос. Отдаётся он только после того, как задание добавлено в поставку и перешло в статус «на сборке». Отдельно печатаются стикеры грузомест, а QR-код самой поставки доступен после её передачи в доставку.
• Ozon. Этикетка отправления доступна, когда оно собрано и перешло из «ожидает сборки» в «ожидает отгрузки».
• Яндекс Маркет. По сравнению моделей в документации Partner API ярлыки заказов получают через API для FBS, Экспресса и DBS, а отгрузки по API — только для FBS.

Из этого вытекает правило для программы: сначала перевести задания в нужный статус, потом печатать. Печать пачкой должна идти в том же порядке, в каком стоят заказы на столе упаковки, иначе сборщик снова ищет, какая этикетка к какому пакету. Если термопринтер понимает ZPL, удобнее брать этот формат: этикетка уходит на принтер командами, а не картинкой, которую нужно подгонять по размеру.

С маркировкой отдельная история. На Wildberries код «Честного знака», УИН, IMEI или GTIN закрепляют только за заданием в статусе «на сборке», а обязательные идентификаторы из поля requiredMeta влияют на то, удастся ли передать поставку в доставку. Поэтому сканировать код стоит в момент упаковки, сразу отправляя его на площадку. Что ещё требует маркировка от учёта, — в статье про «Честный знак» в интернет-магазине.

Как сканер ловит пересорт?

Сканер сравнивает штрихкод товара с позицией в задании. Совпало — позиция закрыта, нет — программа не даёт упаковать заказ и показывает, что ожидалось. Пересорт по размеру, цвету или комплектации ловится на столе, а не в отзыве покупателя.

Чтобы проверка работала, нужно три вещи:

• Штрихкод на каждой единице. Если на товаре штрихкода нет или он одинаковый для всех размеров, сканер ничего не проверит. Первая задача — промаркировать склад своими штрихкодами.
• Связь штрихкода с вашим артикулом. Один товар может иметь заводской штрихкод и штрихкоды, выданные каждой площадкой. Все они должны вести к одной позиции в справочнике.
• Запрет закрыть заказ вручную. Если кнопка «собрано» доступна без скана, на потоке её будут нажимать. Обход проверки — только для старшего, с записью в журнал.

Оборудование — от сканера, подключённого к компьютеру на столе упаковки, до терминала сбора данных на подборе. Для небольшого склада часто хватает проводного сканера и одного рабочего места. Как выбрать устройство, разобрано в статье штрихкодирование склада: ТСД или смартфон; здесь достаточно того, что программа должна принимать скан как обычный ввод с клавиатуры, тогда подойдёт почти любой сканер.

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

Как не пропустить срок отгрузки?

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

Что обычно настраивают:

• Очередь по сроку. Лист подбора строится из заданий, у которых срок ближе всего; новые заказы с запасом времени уходят в следующую волну.
• Предупреждения. Уведомление в Telegram, если задание не собрано за оговорённое время до отгрузки или если поставка не передана в доставку.
• Контроль поставки. На Wildberries задание попадает «на сборку», только когда его добавили в поставку; поставку потом нужно передать в доставку. Если этого не сделать, по документации она закроется сама при сканировании её QR-кода или приёмке первого товара на пункте. Удобнее, когда программа делает это шагом процесса, а не надеется на память.
• Отмены до упаковки. Покупатель может отменить заказ, а продавец на Wildberries — отменить задание до передачи площадке. Программа должна снимать отменённые позиции с листа, иначе их соберут и упакуют зря.

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

	Вручную по кабинетам	Готовый сервис	Своя программа
Когда подходит	Десяток заказов в день, одна-две площадки	Процесс типовой, склад небольшой, учёт уже в сервисе	Свои правила склада, несколько складов, связка с вашей 1С или CRM
Лист подбора	Три выгрузки, сведённые руками	Есть, в формате сервиса	Под ваш склад: ячейки, порядок обхода, приоритеты
Этикетки	Скачивание в каждом кабинете отдельно	Пачкой, в порядке сервиса	Пачкой, в порядке листа и с вашими шаблонами
Проверка сканером	Нет	Зависит от тарифа и оборудования	Под ваш процесс и ваше оборудование
Расходы	Время сотрудников	Ежемесячная подписка сервиса	Разработка один раз плюс поддержка

Готовый сервис или своя программа?

Готовый сервис подходит, если склад типовой и учёт уже живёт в нём. Своя программа нужна, когда есть свои правила: несколько складов, адресное хранение, комплекты, связка с вашей 1С или CRM, особый порядок упаковки. Ручной режим разумен, пока заказов немного.

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

Признаки, что готового сервиса уже мало:

• учёт ведётся в 1С, и остатки, заказы и отгрузки нужно видеть там, а не в стороннем кабинете;
• складов несколько, и заказ надо собирать с того, где товар есть и откуда быстрее отгрузить;
• есть комплекты и наборы, которые собирают из частей прямо при упаковке;
• своё оборудование и свои этикетки, которые сервис не поддерживает;
• сборку нужно связать со своим интернет-магазином, где заказы тоже собирает этот же склад.

Сколько стоит

Основа — тариф «Автоматизация маркетплейсов»: от 40 000 ₽, срок от 3 дней. В него входят подключение Wildberries и Ozon по API, синхронизация остатков со складом или 1С, защита от переторговли и уведомления в Telegram о заказах и сбоях. Яндекс Маркет — за доплату.

Лист подбора, пакетная печать этикеток, проверка сканером и экран сроков в базовый состав тарифа на странице автоматизации маркетплейсов отдельной строкой не входят. Это доработка, и её объём зависит от вашего склада, поэтому считаем после брифа. Ориентиры по прайсу студии:

• Только уведомления. Если сейчас главная боль — пропущенные заказы и сроки, начать можно с Telegram-бота, который присылает новые задания и предупреждения: от 16 000 ₽, 1–2 дня.
• Связка с учётом и службами. Обмен с 1С, CRM или складской программой — тариф интеграций от 32 000 ₽, от 2 дней.
• Своя программа сборки с ролями сборщика и упаковщика, листами подбора, сканером и журналом — это уже веб-приложение: от 160 000 ₽, от 10 дней.

Итог по смете фиксируем в договоре до старта, оплата 50/50: половина при старте, половина после подписания акта. В работу входят до 2 раундов правок, после запуска — бесплатные мелкие правки по тарифу (7 дней у автоматизации маркетплейсов, интеграций и бота, 14 дней у веб-приложения), отдельно от них гарантия 30 календарных дней с даты акта. Дальше — поддержка от 7 900 ₽ в месяц. Исключительное право на код остаётся у студии, у вас после полной оплаты — лицензия на весь срок действия исключительного права: исходники в вашем репозитории, любой сервер и любые подрядчики. Опубликованных кейсов именно по сборке FBS у нас на сайте пока нет, поэтому сроки называем по вашему процессу, а не по чужому примеру.

Когда это вам не нужно и какие ошибки делают

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

Ошибки, которые видим чаще всего при постановке задачи:

• Автоматизировать хаос. Без справочника артикулов и мест хранения лист подбора получится, но экономии шагов не будет.
• Начать с оборудования. Купленные терминалы лежат в коробке, пока нет программы, которая знает, что с ними проверять.
• Печатать до смены статуса. Этикетка не скачается или окажется не той, если задание ещё не переведено в нужный статус.
• Забыть про отмены. Отменённый заказ остаётся в листе, его собирают и упаковывают, а потом ищут, куда вернуть.
• Вести остатки отдельно от сборки. Если собранный заказ не уменьшает остаток сразу, другая площадка продаёт тот же товар. Как это устроено, — в статье про автообновление остатков на WB и Ozon.

Чек-лист перед тем, как автоматизировать сборку

Ответьте на эти вопросы до брифа — по ним можно оценить объём работы и понять, хватит ли готового сервиса.

1. Сколько FBS-заказов в день на каждой площадке сейчас и в пик сезона?
2. Где ведутся остатки: 1С, МойСклад, таблица, складская программа?
3. Есть ли у каждого товара ваш артикул и привязаны ли к нему артикулы площадок?
4. Есть ли на каждой единице штрихкод, разный для размеров и цветов?
5. Есть ли адресное хранение — ячейки или хотя бы номера стеллажей?
6. Какие товары маркируются «Честным знаком» и где сейчас сканируют коды?
7. Какой принтер этикеток стоит и поддерживает ли он ZPL?
8. Сколько человек собирают и упаковывают, есть ли разделение ролей?
9. Продаёте ли вы тот же товар в своём интернет-магазине или офлайн?

Если на большинство вопросов ответ «нет» или «не знаю», начинать стоит со справочников и маркировки склада, а не с программы. Если ответы есть, такой список экономит половину брифа.

Короткие ответы на частые вопросы

Можно ли собирать заказы Wildberries, Ozon и Яндекс Маркета по одному списку?

Да. Заказы всех площадок забирают по API, сводят по вашим артикулам и ячейкам в один лист подбора, а раскладывают по заказам уже с этикеткой нужной площадки. Главное условие — единый справочник: артикул каждой площадки должен быть привязан к вашей номенклатуре.

Какого размера этикетки FBS на Wildberries?

По документации API Wildberries стикер сборочного задания запрашивают в одном из двух размеров — 58×40 или 40×30 (картинка 580×400 или 400×300 пикселей) в форматах SVG, PNG или ZPL для термопринтера, до 100 стикеров за один запрос. Стикеры отдаются только для заданий в статусах «на сборке» и «в доставке», то есть уже добавленных в поставку.

Зачем сканер, если сборщик и так видит название товара?

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

Сколько стоит автоматизировать сборку FBS?

Подключение Wildberries и Ozon по API с синхронизацией остатков и уведомлениями о заказах входит в тариф автоматизации маркетплейсов — от 40 000 ₽, срок от 3 дней; Яндекс Маркет за доплату. Лист подбора, пакетная печать и проверка сканером — доработка поверх тарифа, её считаем после брифа.

Когда автоматизация сборки не окупает себя?

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

Услуги и кейсы по теме: автоматизация Wildberries и Ozon · Telegram-боты под ключ · цены и сроки