Остатки по размерам на WB: как швейке не терять SKU на FBO

Сборщик подходит к стеллажу с заказом «Платье A001 синее, 42-й, 8 штук» — а 42-го там два. Менеджер открывает карточку WB: остаток показан «48 штук платья A001». Звонит технологу: «По модели всего сорок восемь? Точно?». Технолог открывает Excel: «Сорок восемь всего, по размерам не считали». Заказ на сборке стоит, дедлайн отгрузки горит, штраф WB за нарушение сроков — 5% от ожидаемой суммы заказа за каждый день. Через два дня партия уезжает в недокомплекте, рейтинг продавца проседает, карточка падает в выдаче маркетплейса.

Эта картина — не редкая ошибка, а штатный сценарий любого швейного цеха, который ведёт учёт в карточке «модель целиком» и работает с маркетплейсом. В Excel — один SKU. На складе — 24 разных SKU. На WB — 24 карточки с отдельными остатками. Между этими тремя реальностями нет автоматического маппинга, и расхождение всегда выявляется в самый болезненный момент — на сборке.

В этой статье — почему дефицит размера на маркетплейсе ловится поздно, как стыковать остатки по SKU с FBO/FBS-схемой, что должен показывать учёт сборщику до начала упаковки и где экономика штрафа за дефицит. Без терминологии — на примере одной партии платьев и одного заказа WB.

Где ломается стыковка остатков с маркетплейсом

WB и Ozon работают на уровне карточки товара = SKU. У каждой комбинации модель × размер × цвет — отдельная карточка, отдельный штрихкод, отдельный остаток в личном кабинете продавца. Так устроен любой маркетплейс одежды: иначе невозможно показать покупателю «есть 42-й, нет 44-го».

Швейный цех чаще всего живёт по обратной логике: карточка товара = модель. В Excel или в таблице «Учёт ткани» строка «Платье A001 синее — 48» закрывает потребности технолога (сколько ткани закроили, сколько сшили) и собственника (сколько готового товара). На уровень «остаток по 42-му» ручной учёт не спускается — это много строк, их никто не успевает обновлять после каждой сборки заказа.

В итоге между складом и маркетплейсом образуется три рассинхрона:

1. Остаток в карточке WB обновляется через API или через ручную выгрузку. Если ведёте по модели целиком — отправляете в WB условные «48 штук», размазанные по всем размерам поровну. WB продаёт по каждому SKU независимо, и однажды на 42-й приходит запрос — а его всего две штуки.
2. Резерв под заказ не существует на уровне SKU. Когда заказ на 42-й уже подтверждён, остаток на складе формально ещё «48», и кладовщик ничего не знает: 42-й продаётся параллельно через шоурум, через Ozon, через B2B-канал.
3. Сборщик отгрузки проверяет наличие физически — пересчитывает 42-й на стеллаже. Он первый человек, который видит реальную картину. К этому моменту заказ уже подтверждён, дедлайн начал идти.

Эту проблему нельзя решить «делать раз в неделю инвентаризацию по размерам». Скорость продаж на WB — десятки заказов в день; за неделю остаток меняется до сотни раз.

Пример: партия 60 платьев и заказ на 42-й

Возьмём конкретный кейс. Цех шьёт женское платье A001 в трёх цветах (синий, чёрный, бордо) и восьми размерах (40, 42, 44, 46, 48, 50, 52, 54). Это 24 уникальных SKU из одной модели.

В партии отшито 60 платьев. На бумаге технолог распределил так: каждого размера по 7-8 штук, цвета поровну. По факту раскрой шёл «как лежит ткань», и реальное распределение получилось перекошенным:

Цвет / Размер	40	42	44	46	48	50	52	54
Синий	1	2	3	4	3	2	1	0
Чёрный	2	3	4	4	3	2	1	1
Бордо	1	2	3	3	2	1	1	0

В Excel это всё равно одна строка: «Платье A001 — 60». В WB карточек 24, и каждая показывает остаток на основе того, что отправили в личном кабинете. Если продавец отправил «по 2,5 штуки на SKU» (60 / 24), то по карточке 42-го синего на WB светится «3 штуки», а на складе их две. Покупатели делают заказы. Через неделю кто-то покупает 42-й синий, заказ уходит в сборку. Сборщик пересчитывает физический остаток — два. По регламенту WB FBS для платьев упаковочный slot — 48 часов; если не отгрузил по карточке, начинается штраф.

Размеры 40 и 54 синие — нулевая позиция в синем 54 и одна штука в синем 40. По карточкам WB они тоже фигурируют как «есть в наличии», пока продавец вручную не выставит 0. На эти размеры за две недели регулярно приходят отдельные заказы. Каждый из них — это либо отмена заказа (минус карма продавца), либо срочный перешив (минус маржа: 1 платье в спешке — это 1.5–2 нормо-часа дороже).

Итог: партия 60 платьев, отправленная в FBO как «единое целое», даёт до 5–8 проблемных заказов за две недели — отмены, штрафы, перешивы. На дашборде WB это видно как «низкий процент выполнения заказов» и «снижение рейтинга продавца» — а в реальности это последствие того, что 60 штук в Excel не равны 24 SKU на сайте маркетплейса.

FBO vs FBS: где дефицит ловится раньше

Схема работы с WB сильно меняет момент, когда дефицит размера всплывает.

FBS (Fulfillment by Seller). Товар хранится у вас, заказ уходит вам в личный кабинет, вы сами комплектуете и передаёте курьеру WB. Дефицит ловится на сборке — то есть после подтверждения заказа, но до отгрузки. Окно для реакции — 24–48 часов. За это окно можно либо найти 42-й в другом месте (другой склад, шоурум, перешить), либо отменить заказ со штрафом.

FBO (Fulfillment by Operator). Партия уехала на склад WB, заказы сборщик WB обрабатывает сам, продавец узнаёт о дефиците постфактум: на дашборде появляется уведомление «закончился остаток SKU». Время реакции — нулевое: сборка прошла, недокомплект уехал клиенту, возврат уже летит обратно. Здесь критично, чтобы партия, которая едет на FBO, шла уже с правильной разбивкой по SKU и реальным остатком каждого размера — потому что повлиять на сборку после этого невозможно.

Подробно сравнение схем мы разобрали в материале «Маркетплейсы для крафта: FBO vs FBS и юнит-экономика» — там же про комиссии и логистику. Для размерного ряда практический вывод такой: на FBS вы успеваете отреагировать на дефицит, на FBO — нет. Значит, до загрузки партии на склад WB остатки по SKU должны быть посчитаны точно, иначе следующие 2 недели заказы на «нулевые» размеры станут возвратами и штрафами.

Что должен показывать учёт сборщику отгрузки

Сборщик отгрузки на FBS — это первая и единственная линия защиты от штрафа за недокомплект. К моменту, когда заказ на 42-й попадает в очередь сборки, он должен видеть три вещи:

1. Остаток конкретного SKU прямо сейчас, а не «остаток модели». Не «Платье A001 — 48», а «Платье A001 синий 42 — 2 штуки. Чёрный 42 — 3. Бордо 42 — 2». Желательно с указанием конкретного места на складе (стеллаж, полка).
2. Резерв под уже подтверждённые заказы. Если на 42-й синий уже два других заказа в очереди сборки, остаток должен быть «2 минус 2 = 0 свободно» — даже если физически на стеллаже лежит две штуки. Иначе сборщик берёт под текущий заказ и оставляет следующий сборщик у пустой полки.
3. Минимальный остаток по SKU (точка заказа), при котором надо инициировать перешив. Если по 42-му синему регулярно проходит 5–6 заказов в неделю, а на складе осталось 3 — это сигнал технологу запускать раскрой ещё до того, как 42-й физически закончится.

Эти три данных невозможно держать в Excel вручную. Они есть либо в учётной системе с поддержкой вариантов товара (вариативная номенклатура — карточка модели и связанные SKU), либо собираются костылями через личный кабинет WB + Google Sheets + рукопашный пересчёт. Второй вариант работает до объёма ~10 моделей и ~3–5 заказов в день; на 20+ моделях он разваливается.

Резервирование SKU под заказ — почему это критично

Резервирование — это разница между «есть на складе» и «свободно к продаже». Сценарий без резервирования:

• 09:00 — пришёл заказ WB на «42-й синий, 3 штуки». Подтвердили.
• 11:00 — менеджер подтверждает опт на «42-й синий, 4 штуки», потому что видит «48 в наличии».
• 14:00 — сборщик находит два 42-го синих вместо трёх. WB фиксирует недокомплект.
• 15:00 — на опт остаётся ноль. Срок переносится на неделю.

Сценарий с резервированием:

• 09:00 — заказ WB подтверждён. Учёт ставит резерв «42-й синий: −3».
• 09:05 — свободный остаток показывает «2 − 3 = −1». Дефицит виден до сборки.
• 11:00 — менеджер видит «свободно 0 штук» и не обещает опту то, что уже продано.

Разница между двумя сценариями — это разница между «штраф WB + срыв опта» и «корректный перенос». Учётно: либо резерв на уровне SKU, либо ручные проверки на стеллаже.

Тема резервирования смежна с возвратами. Возврат не сразу возвращает SKU в свободный остаток: товар едет обратно, проверяется, потом идёт на склад, в брак или уценку. Этот цикл мы разобрали в материале «Возвраты на маркетплейсах: учёт, перепродажа, снижение».

Экономика штрафа за дефицит размера

Штраф WB за нарушение сроков отгрузки или недокомплект — это прямой минус с выплаты. Но за ним стоят ещё четыре косвенные потери, которые в моменте незаметны:

1. Снижение рейтинга карточки в выдаче WB. После одного-двух нарушений алгоритм опускает карточку на 2–5 позиций в категории. Восстановление — 2–3 недели стабильной работы.
2. Заморозка рекламы карточки. WB не показывает рекламные карточки с низким рейтингом доставки — деньги на продвижение горят.
3. Возвраты за «не тот размер». Если сборщик в спешке отправил 44-й вместо 42-го — клиент возвращает, продавец оплачивает обратную логистику (50–100 ₽ на единицу) + риск порчи товара.
4. Время менеджера на разбор. Каждый инцидент — это 30–60 минут на коммуникацию с WB, клиентом, цехом.

Статья потерь	Размер на 1 проблемный заказ
Штраф WB за срыв срока	3–5% от суммы заказа (300–800 ₽ на платье)
Логистика возврата	50–100 ₽
Время менеджера (1 час × 500 ₽)	500 ₽
Падение позиции в выдаче (упущенная выручка за 2 нед)	5–15% объёма карточки
Итого на инцидент	1 500–3 000 ₽ прямо + 5–15% выручки косвенно

При 5–8 проблемных заказах в две недели прямая стоимость размерных дефицитов = 8 000–24 000 ₽ в месяц на одном цехе. Косвенная — больше: карточка не растёт, рекламный бюджет уходит впустую, повторные клиенты не возвращаются после плохого опыта.

Как внедрить учёт размеров за 7 дней без остановки цеха

Переходить с Excel на учёт по размерам не надо «с понедельника для всего склада». Так цех останавливает текущие отгрузки и получает вторую таблицу вместо контроля. Рабочий путь — взять одну модель, один склад и один канал WB.

План на неделю:

1. День 1: выбрать пилотную модель. Берите модель с 6–8 размерами и живыми продажами на WB.
2. День 2: разложить модель на SKU. Отдельная строка на каждую комбинацию размер × цвет: «A001 синий 42», «A001 синий 44», «A001 чёрный 42».
3. День 3: пересчитать физический остаток. Не переносите «60 платьев» из Excel. Сборщик считает полку по размерам.
4. День 4: завести резервы. Все принятые WB-заказы вычитаются из свободного остатка. Остаток на полке и свободно к продаже — разные числа.
5. День 5: задать минимальные остатки. Для ходовых размеров 42–46 порог выше, для редких 52–54 ниже.
6. День 6: сверить личный кабинет WB. Если WB показывает «3», а на полке «2», сначала правится учёт, потом отгрузка.
7. День 7: включить ежедневную сверку. 10 минут утром: новые заказы, возвраты, резервы, нулевые размеры.

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

FAQ

Можно ли вести остатки по размерам в Excel?

Можно, если у вас до 10 моделей и до 3–5 заказов в день. Дальше таблица отстаёт от склада.

Нужно ли заводить отдельную карточку на каждый размер?

Да. Для WB важна комбинация модель × цвет × размер. Три цвета и восемь размеров дают 24 SKU.

Чем FBO опаснее FBS для размерного ряда?

На FBS сборщик видит дефицит до передачи заказа WB. На FBO партия уже уехала на склад маркетплейса.

Что делать с возвратом не того размера?

Не возвращайте его сразу в свободный остаток. Сначала проверьте размер, состояние и карточку WB.

Какой минимальный остаток ставить по размерам?

Берите недельный спрос по SKU и срок дошива. Если 42-й синий продаётся по 6 штук в неделю, остаток 3 штуки уже низкий.

---

Если шьёте под Wildberries или Ozon и узнали сценарий «42-й закончился на сборке», посмотрите страницу Zolotenkov MRP для швейного цеха. Для ателье с заказами по одному изделию ближе сценарий индивидуального пошива: там размерный ряд тоже важен, но резерв строится вокруг конкретного клиента, а не FBO-партии. Покажем, как разводить модель на SKU, ставить резервы под WB-заказы и ловить дефицит до упаковки.