Остатки по размерам на Wildberries: как швейке не терять артикул на складе маркетплейса

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

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

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

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

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

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

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

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

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

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

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

В партии отшито 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 штуки на артикул» (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 артикулов на сайте маркетплейса.

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

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

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

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

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

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

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

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

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

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

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

• 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 + срыв опта» и «корректный перенос». Учетно: либо резерв на уровне артикул, либо ручные проверки на стеллаже.

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

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

Штраф 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: разложить модель на артикул. Отдельная строка на каждую комбинацию размер × цвет: «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 минут утром: новые заказы, возвраты, резервы, нулевые размеры.

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

---

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