Часто на практике мы сталкиваемся с ситуацией, когда товары продаются в виде готовых изделий (например, шкафов различных размеров и цветов), но на складе они хранятся в виде отдельных комплектующих: фасадов, профилей и фурнитуры. Возникает логичный вопрос: как настроить программу так, чтобы менеджер мог видеть, сколько именно готовых наборов можно собрать из имеющихся остатков деталей? Проанализируем эту задачу на примере конфигурации 1С:Управление торговлей 11.
Разберем ситуацию подробнее. Допустим, у нас есть комплектующие для шкафа: фурнитура (универсальная), профили (разных цветов и размеров) и фасады. Если мы попробуем создать простой отчет, который считает доступное количество готовых изделий, мы неизбежно столкнемся с проблемой комбинаторики. Если на складе лежит 1 набор фурнитуры, 2 вида профилей и 2 вида фасадов, некорректно настроенный алгоритм может показать, что мы можем собрать 2 или даже 4 шкафа. В реальности же «узким горлышком» является фурнитура — собрать мы сможем только 1 полноценный шкаф.
В терминах 1С это называется задачей обратного разузлования. В общем виде (сколько вообще разнообразных готовых изделий можно сделать из всей кучи запчастей на складе) эта задача крайне сложна для вывода в единый типовой отчет, так как требует ввода жестких приоритетов распределения общих деталей. Однако, посмотрим, как можно элегантно решить потребность бизнеса с помощью стандартных инструментов системы.
В конфигурации 1С:Управление торговлей 11 существует два принципиально разных механизма для работы с составными товарами. Понимание этой разницы — ключ к правильной архитектуре учета.
Товар), которая имеет реальный физический остаток на складе. Он появляется там после того, как мы отразили операцию сборки из деталей.Рассмотрим, как настроить систему, если мы не хотим заранее собирать шкафы на складе, а продаем их "с колес".
Для начала грамотно настроим справочник Номенклатура:
Набор.ХарактеристикиНоменклатуры, чтобы задать размер и цвет (например, «Дуб, 180 см»).Как система считает доступность? Если менеджер создает документ РеализацияТоваровУслуг или ЗаказКлиента и выбирает наш набор, он может дважды кликнуть по строке и открыть форму «Состав набора». Именно в этот момент 1С автоматически рассчитывает доступное количество наборов конкретной комплектации. Расчет идет по принципу «слабого звена» — система ищет деталь с минимальным остатком и показывает, что наборов можно продать не больше этого числа.
Кроме того, в настройках вида номенклатуры мы можем гибко управлять тем, как набор будет выглядеть в печатных формах для клиента: можно выводить только название "Шкаф", можно выводить полный список деталей, а можно комбинировать оба варианта. Цену также можно задавать либо за весь набор целиком, либо рассчитывать ее как сумму цен комплектующих.
Если заказчику критически важно видеть готовые шкафы в стандартных отчетах по остаткам склада (например, в отчете ОстаткиИДоступностьТоваров) или выгружать эти данные на сайт, динамические наборы не подойдут. Рассмотрим альтернативный сценарий.
Товар.ВариантыКомплектации (аналог спецификаций). В них жестко прописываем, сколько фурнитуры, фасадов и профилей требуется.СборкаТоваров.Этот способ позволяет всегда иметь точную картину готовой продукции на складе и без проблем выводить данные в любые отчеты и прайс-листы.
Выясним причину, почему стандартные отчеты не могут сразу показать таблицу со всеми возможными комбинациями шкафов. Типовой функционал рассчитывает возможный остаток только в момент обращения к конкретному набору в документе. Он не умеет предиктивно перебирать все возможные комбинации деталей для массового вывода.
Если бизнес-процесс требует именно массового расчета («сколько всего разных шкафов мы можем собрать прямо сейчас»), потребуется создать внешнюю обработку или расширение конфигурации. В таком коде необходимо реализовать алгоритм, который будет перебирать все настроенные варианты комплектаций или составы наборов, обращаться к виртуальным таблицам остатков и находить минимальные значения по каждой группе комплектующих. Однако перед тем как браться за такую доработку, рекомендуем убедиться, что пользователям действительно недостаточно типового механизма расчета доступности непосредственно в форме заказа.