Разные рецепты на варианты товара: почему для швейки и сборки один BOM

Если вы шьете одну модель футболки в трех размерах — S, M, L — то это не три товара. Это один товар с тремя вариантами. У Katana и у Zolotenkov на уровне справочника товара эта модель одинаковая: есть «товар», под ним три «варианта» с отдельными SKU, ценами, штрих-кодами. Но дальше начинается различие, которое на первый взгляд кажется мелочью, а на практике определяет, можно ли вообще вести производство в системе.

Речь про рецепт — список сырья и материалов, которые расходуются на единицу готовой продукции. Или, как его еще называют, BOM (Bill of Materials).

Коротко: в чем разница

Katana: один BOM на товар. Все варианты S/M/L унаследуют один и тот же список материалов с одним и тем же количеством.
Zolotenkov: BOM навешивается на каждый вариант отдельно. У S — один расход ткани, у M — другой, у L — третий. Себестоимость считается по своему BOM для каждой единицы.

Это архитектурное решение, а не настройка: в Katana вы не можете «включить» разные рецепты на варианты — их модель данных просто не предусматривает такого разделения.

Почему это важно для швейки

Футболка M-размера требует 1,5 м ткани. Футболка L — 1,8 м. Разница 20%. Если себестоимость ткани 600 ₽/м, то:

Футболка M = 600 × 1,5 = 900 ₽ только ткань.
Футболка L = 600 × 1,8 = 1 080 ₽ только ткань.

Плюс нить, бирка, упаковка, операции цеха — с разным расходом времени, потому что L-размер шьется чуть дольше M. Реальная разница в себестоимости между S и L может быть 15–25%.

Что произойдет в Katana, где один BOM на товар:

Мастер занесет средний расход — скажем, 1,6 м ткани.
На футболках S (нужно 1,2 м) система покажет завышенный расход: 1,6 м вместо 1,2 м. В прайс это заложится как 960 ₽ ткани там, где реально уходит 720 ₽ — и розничная цена получится завышенной.
На футболках L (нужно 1,8 м) — заниженный расход: 1,6 м вместо 1,8 м. В прайс заложится 960 ₽ ткани там, где реально уходит 1 080 ₽ — и розничная цена получится заниженной. Маржа на большом размере тает.

Это не теоретическая проблема. У мастерской, которая шьет 200 футболок в месяц (40 S, 80 M, 80 L), ошибка оценки себестоимости на 5–7% приводит к недополучению 30–40 тысяч рублей в месяц. Плюс к тому — при остатках сырья система покажет неправильное «хватит ли ткани на заказ», потому что не знает, сколько именно идет на каждый размер.

Как это устроено в Zolotenkov

В карточке товара с включенной опцией «несколько вариантов» каждый вариант имеет собственную вкладку с своим рецептом. Переключение между вариантами — dropdown с надписью «Любые изменения здесь затрагивают только выбранный вариант». Миграция 7__recipe_per_variant.sql в нашем бэкенде явно прописывает уникальность записи рецепта по паре (item_id, item_variant_id): один рецепт на один вариант, не на товар в целом.

Что из этого следует:

Вы создаете товар «Футболка базовая» с вариантами S, M, L.
На варианте S прописываете расход ткани 1,2 м и 15 минут операций.
На M — 1,5 м и 17 минут.
На L — 1,8 м и 20 минут.
Себестоимость каждого варианта считается по своему рецепту, прайс — по своей базовой цене, остатки ткани списываются правильно при запуске производственного заказа.

Никаких «средних по больнице» расчетов. Никаких ручных коэффициентов сверху. Система точно знает, что на 10 футболок размера L нужно 18 м ткани, а не 16.

Не только швейка

Сценарий очевиден для швейного производства, но работает для любой сборки/изготовления, где размер или спецификация влияет на расход сырья:

Мебель: шкаф высотой 180 см vs 220 см — разный расход ЛДСП и кромки.
Мыловарение: мыло формата «кусок 80 г» vs «кусок 120 г» — пропорциональный расход масла и отдушки, но разное количество упаковочной пленки и этикеток (на меньшем формате больше этикеток на тот же тираж, и это не «деление пополам»).
Кондитерка: торт 1 кг vs 2 кг vs 3 кг — разный расход крема, бисквита, декора (но не строго в 2 и 3 раза).
Свечи: 200 мл / 300 мл / 500 мл — разное количество воска и длина фитиля.
Керамика: кружка 250 мл vs 400 мл — разный расход глины и глазури.

Во всех этих нишах «один BOM на товар» — это миф, который ломается на первой же партии. Мастер либо заводит каждый размер как отдельный товар (теряя связь между вариантами, путая склад, ломая аналитику), либо смиряется с неточной себестоимостью.

Что с этим делают пользователи Katana

Обычно два костыля:

Каждый размер — отдельный товар. Вместо «Футболка базовая (S, M, L)» заводят три отдельных товара: «Футболка базовая S», «Футболка базовая M», «Футболка базовая L». У каждого свой BOM. Но они теряют связь на уровне продукта — нельзя быстро сменить цвет во всех вариантах, нельзя видеть общий «продаваемость модели», приходится дублировать фото и описание.
Один BOM + ручная корректировка. Мастер вручную пересчитывает себестоимость в Excel после каждой партии и корректирует цены. Работает, но это не учет — это поддерживать Excel параллельно системе.

В обоих случаях продуктивность производственной учетной системы падает до уровня «чуть лучше, чем Excel».

Когда per-variant BOM не нужен

Честно: есть товары, где вариантов несколько, но расход сырья на них одинаковый. Футболки одного размера в разных цветах — разная ткань по цвету, но расход тот же. Мыло одного формата в разных ароматах — одно и то же количество основы, отличается только отдушка. В таких случаях достаточно одного BOM, и Katana-модель работает.

Но как только в вариантах меняется размер, вес, объем или форма — единый BOM перестает быть достаточным. Для большинства производств малого масштаба (швейка, мебель, свечи, косметика с разными форматами, кондитерка с разным весом тортов) per-variant BOM — это базовое требование, а не продвинутая фича.

Резюме

В Zolotenkov каждый вариант товара имеет собственный BOM с собственным расходом материалов и операций.
В Katana один BOM на весь товар — для производств с разными размерами/форматами это приводит к искажению себестоимости и ошибкам при списании сырья.
Выход в Katana — либо разделять один товар на несколько (теряя связку вариантов), либо вести параллельный учет в Excel. Оба варианта съедают пользу от MRP-системы.
Для швейки, мебели, мыловарения, кондитерки с разным форматом, свечей, керамики — per-variant рецепты не «удобная опция», а базовое условие точного учета.