Внесение состава изделия, состоящего из большого числа вложенных сборок.

Константин, добрый день. Помогите на конкретном примере разобраться как внести материал в заказную спецификацию. Готовое изделие: мебельный фасад розового цвета. Для облицовки плиты МДФ используем смесь хим. компонетов. В смеси присутствует цветная паста розового цвета. Эта паста розового цвета состоит из 4 покупных монопаст: зеленой, бежевой, белой и красной. При внесении материалов в заказную спецификацию программа не дает внести 4 цвета пасты. Только розовая паста и один цвет монопасты. Вопрос в том как можно указывать несколько компонентов в заказной спецификации, соответственно указывать расход и технологию изготовления смеси?

Здравствуйте,

Давайте начну с пояснения.
Программе, в целом, вообще-то все равно, как называть изделия: деталями, сборочными единицами, ещё как-то. Ей без разницы. На работоспособность, в общем-то, никак не влияет. Важно, что будет указано в составе производственного заказа, и что в технологии написано. А как кого называть – всё равно.

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

Деталью называется обычно изделие из однородного материала, изготовленное путём его обработки без применения каких-либо сборочных операций.

Материалом называется вещество или смесь веществ, которое используется для изготовления из него детали, используется в производственном процессе или используется для придания изготавливаемому изделию определённых свойств.

Сборочной единицей называется изделие, получаемое соединением нескольких деталей в единую конструкцию с помощью каких-либо сборочных операций (свинчивание, клёпка, сварка, пайка, склеивание и т.п.).

Теперь добавим немножко «vogbit’овской» терминологии:

Программа условно разделяет все позиции на изготавливаемые и покупные. Покупные – это значит мы получаем такую номенклатуру сразу в готовом виде от поставщика или подрядчика. И используем её. Изготавливаемое – то, что мы полностью делаем сами (деталь из материала) или в какой-то мере дорабатываем сами каким-либо образом из чего-то покупного (заготовки).
Основным признаком, является позиция покупной или изготавливаемой, для программы является наличие или отсутствие у этой позиции «технологии» - описания как её делать и из чего делать. Есть технология – изготавливаемая позиция. Нет технологии – покупная.
Вообще, это не строгая догма. При наличии возможности и целесообразности можно, как изготовить покупную позицию (поместить её в заказ на производство, выдать задания для участков, отметить их выполнение, сдать готовую на склад), так и купить изготавливаемую позицию (добавить её в заявку поставщику, оприходовать на склад от поставщика). Однако, в большинстве случаев именно по наличию или отсутствию технологии номенклатура в базе разделяется на изготавливаемую и покупную.
При этом любая позиция может быть изготавливаемой. Как и любая может быть покупной. Детали, сборочные единицы, материалы, инструмент, средства оснащения – всё это может быть как изготавливаемым, так и покупным. Никаких ограничений на этот счёт нет. Если изготавливаемое (не важно что: деталь, материал и т.п.) – пишем к нему технологию: как делать, из чего делать.

Теперь возвращаемся к Вашему примеру.

Спецификации, подозреваю, вам не нужны. Ни «конструкторские», ни тем более «заказные». Никакие.
Заказные спецификации бывают полезны, когда речь идёт о сборочном производстве и достаточно сложных изделиях. Когда изделие состоит из сборочных единиц и деталей, те в свою очередь из других сборочных единиц и деталей, и т.д. У Вас нет ни сборки, ни таких изделий. Просто не нужны, мне кажется, в вашем случае никакие «спецификации» в VOGBIT.

Есть изделие – элемент фасада. Оно изготавливаемое. Соответственно у него есть технология. Если собираетесь как-то планировать работы, выдавать задания, отслеживать их выполнение, то добавляем в технологию операции: «резка» и «облицовка» (условно, может быть больше, сколько нужно; если же работы учитывать в программе не будете, то можно вообще операции никакие не вводить). Если собираетесь учитывать материалы (расход, наличие, дефицит, заявки в снабжение), то вводим в технологию, какие материалы используются для изготовления данного изделия: «МДФ» и «Паста розовая» с нормой расхода.

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

И всё. Достаточно. Дальше по мере необходимости формируем производственный заказ на изготовление «пасты розовой» в нужном количестве. На него по ЛЗК выдаём в нужном количестве со склада «монопасты» разных цветов. Готовую «пасту розовую» сдаём на склад.
Запускаем производственный заказ на изготовление элемента фасада. На него по ЛЗК выдаём со склада «МДФ» и «пасту розовую» в необходимом количестве.
Всё.

Примеры:
Изделие «элемент фасада» и технология на него – рис. 1.
Материал «паста розовая» и технология на него – рис. 2.

(все нормы, естественно «от балды»   )

P.S.
"Спецификации" в VOGBIT в таком производстве теоретически могут понадобится вот в каком случае: если "паста розовая" замешивается в строго ограниченном количестве ровно на нарезаемые фасады и сразу наносится, и ничего не остается. Например, заказали 3 разных элемента фасада, но все розовые. И нужно замесить розовой пасты сразу ровно столько, чтобы хватило на все эти три фасада, и сразу вся она будет нанесена. На складе "розовая паста" не хранится, делается ровно столько, сколько нужно, и сразу вся используется.
Вот в этом случае для уменьшения количества действий в программе и автоматизации заполнения заказов на производство можно применить "спецификации", Только по смыслу они не будут в данном случае соответствовать понятию "спецификации" по ЕСКД (потому что последняя подразумевает список элементов по сборочному чертежу, из которых состоит сборка, а тут никакой ни сборки, ни сборочного чертежа нет в помине). Но можно сделать в VOGBIT специальные "вырожденные спецификации", чисто для такого случая, для решения указанной задачи. И они будут "работать" в контексте описанной задачи.

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

По остальному - общие принципы следующие:

Вы можете при желании выстраивать сколько угодно "уровней вложенности".
Есть деталь, для её изготовления нужен некий "материал" для покрытия.
Этот "материал" в свою очередь делается из некоей "смеси" и "красителя" (или других каких-то материалов).
"Смесь" в свою очередь сама приготовляется из некоего набора материалов. И сама используется как материал в сочетании с разными красителями и др. материалами для приготовления других материалов. Можно сказать, что "смесь" делается не из материалов, а из некоего "компаунда" и ещё материалов, а "компаунд" сам по себе делается из материалов и ещё кроме этой "смеси" для чего-то идёт. И т.д. Сколько угодно в глубину можно вкладывать в технологию материал, который сам делается из других материалов, которые тоже делаются из третьих материалов и т.п.

Дальше начинается творчество. Выделять ли некий материал/смесь и т.п. как отдельный объект производства (номенклатуру)? Или нет? И считать изготовление этого материала/смеси, частью технологического процесса (операцией) того, для чего он(а) нужен(а)?

Если выделять, как отдельный объект производства, то соответственно, можно выдать отдельно задание на изготовление "смеси" (в любом количестве, какое нужно), учесть изготовленное количество, потраченное, оставшееся, которое можно в следующий раз потратить и не делать. С одной стороны это плюс. С другой стороны увеличивается при этом и количество позиций в заказах на производство. Которые сначала должны тем или иным способом попасть в эти заказы, потом по ним нужно выдать задания, отметить готовность. Может быть, в зависимости от дальнейшей организации работы, оформить передачу на склад, выдачу со склада, если смесь на складе засохла не использованная, списать её нужно. И т.д.
Каждое действие это в отдельности, в принципе, простое. Но чем больше "дробим", тем в разы больше становится таких действий.
Стоит ли возможность учитывать более точно эти "компоненты", их изготовление и остатки, кратного увеличения для этого количества действий в программе? Нет однозначного ответа на этот вопрос. На каком-то предприятии да, стоит. На каком-то нет смысла, овчинка выделки не стоит.

Что касается "спецификаций" и заказов на производство. Тут есть два основных пути.

Путь 1.

Заказ на изготовление материала (смеси, не важно чего) оформляется исходя из потребности в нем и свободных остатков, оставшихся с прошлых времён. Тогда общая последовательность такова:
1.1. в заказ на производство вставляем только само изделие (материал), которое нам нужно. Никакие "спецификации" для этого не нужны, соответственно. Совсем.
1.2. формируем к созданному заказу ЛЗК - что нужно взять со склада.
1.3. в "обеспеченности" видим наличие/дефицит нужных материалов (компонентов, смесей) и сохраняем его в заявку на производство - сколько минимум нужно ещё запустить того, что нам не хватает, с учётом текущих свободных остатков;
1.4. в заявке на производство ставим то количество, которое будем запускать, и оформляем как заказ на производство.
1.5. делаем по данному заказу соответствующий материал (смесь, детали и т.п. - не важно), оформляем передачу на склад.
1.6. по ЛЗК (1.2) делаем расход соответствующей позиции на основной заказ (1.1.), в рамках которого в свою очередь получаем желаемое изделие.
Остатки сданной (1.5), но не израсходованной (1.6) продукции оседают на "складе" и соответственно могут использоваться для следующего заказа при определении, сколько запускать в следующий раз (1.3).

Если "вложенность" многоуровневая, то всё по кругу несколько раз:
- заказ на изготовление изделий, ЛЗК на материал, дефицит материала (1.1. - 1.4.)
- заказ на изготовление материала, ЛЗК на смесь, дефицит смеси (1.1. - 1.4.)
- заказ на изготовление смеси, ЛЗК на получение материалов (1.1. - 1.4.)
- тратим материалы, получаем смесь, передаём на "склад" (1.5. - 1.6.)
- тратим смесь, получаем материал, передаём на "склад" (1.5. - 1.6.)
- тратим материал, получаем изделие, передаём на "склад" (1.5. - 1.6.)
- отдаём изделие заказчику.

Путь 2.

Заказ на изготовление "материала", "смеси" и т.п. формируется автоматом, исходя из некоторого заданного количества на единицу изделия, для которого оно нужно.
То есть говорим программе, какие изделия и сколько нам нужно сделать, а она добавляет нам в состав заказа на производство эти самые изделия и сразу же второй (N-ой) строчкой в этот же заказ на производство и материал (смесь и т.п.), какой нужно приготовить, чтобы сделать такое количество таких изделий. По нормативам. Не глядя на "склад".
Вот тут как раз нужны "спецификации". Именно они и есть то место, откуда в данном случае берётся, что ещё помимо основного изделия сразу вставить вместе с ним в заказ на производство и сколько. Можно так же использовать в этой схеме несколько уровней вложенности (вот тут как раз нужны "заказные спецификации" - дерево). Тогда сразу несколько строчек попадёт в заказ на производство: Изделие, материал для него, смесь для материала.

Плюсы в данном случае - намного меньше действий: создал заказ на изделие, туда сразу же добавился в этот заказ и материал для изделия, который нужно приготовить (суммарное количество для нескольких разных изделий на них на все, если одновременно "заказ на производство" делать на них через "расчёт комплектации", и материал один и тот же нужен на них на все).
Дальше берём со склада материалы, какие нужны, из них делаем сразу "смесь/материал" (одна позиция заказа на производство) для основного изделия, никакой сдачи/выдачи на склад не обязательно делать в данном случае (всё равно ж все израсходуем, что сделали), просто сразу отмечаем изготовление самих изделий (другая позиция того же заказа на производство).
Всё. Готово.
Минусы - никак не учитываются в этом случае (кроме как вручную править количество в заказе на производство, что сложно и чревато ошибками при больших объемах и скорости) "остатки" какие-то, оставшиеся с предыдущих раз. Потому что количество в заказ на производство ставится по некоему количеству заданному в спецификации на единицу основного изделия и количества этих основных изделий. Ибо, если нужно с учётом остатков, то это нужно сначала вычислить эти свободные остатки. А там, если копнуть глубже, это не такое простое дело, учитывая, что остатки эти нужны могут быть под разные совершенно нужды и не всегда сразу же забираться со склада. И в итоге это и приведёт к (1).

Вот, в общем, как-то так.
Более конкретные рекомендации, как именно Вам делать, на форуме вряд ли дам.

Потому что это нужно уже подробно разобрать ваш конкретный пример, показать разные варианты, как что можно вводить, как в каком случае дальше будет выглядеть работа - а это уже нужно в детали процесса вашего "влезать" и пример делать. Время нужно на это.
Можем заняться, если интересно, в рамках платной поддержки. Подробности, если интересно, по почте.

Нужно вот эти все узлы и детали, которые составляют это дерево, разделить на группы. Обычно, хватает двух (названия условные, называйте, как нравится):

1-ая группа:
Это узлы целиком или отдельные детали, которых ТОЧНО НЕ может быть ранее зачем-то сделанных до запуска в производство некоего "заказа" (изделия/партии).

2-ая группа - "стеллажные", "задельные", и т.п. по разному можно называть, позиции:
Узлы целиком, подсборки или детали, которые, в принципе, могут быть ранее изготовленные или находится в производстве, которые можно оттуда забрать, а не запускать новые (запущенные в большем, количестве, чем было нужно на заказ, запущенные в каком-то количестве ранее под будущие заказы и т.п.).
К этой группе могут относиться, как сборочные единицы целиком, так и отдельные детали.

Деление производится не по принципу "есть сейчас или нет". А вообще, в принципе, в теории возможен для данной детали/сборочной единицы вариант отнесения её к "группе 2" или точно нет, и 100% только к "группе 1".

Соответственно, в предельных случаях все компоненты изделия относятся к "группе 1" (чисто единичное производство) или все к "группе 2" (такое тоже видел, но реально так очень редко на самом деле). Но чаще всего, есть в том или ином виде разделение на "группу 1" и "группу 2".

Далее при запуске изделий:
1. Формируем производственный заказ, куда через "расчёт комплектации" сразу включаем всё, что относится к "группе 1". При правильных всех настройках и исходных данных - это пару кнопок нажать.
2. Формируем ЛЗК на получение со склада (настоящего или условного) всего под этот заказ, что относится к "группе 2". При правильной настройке и данных, опять же, это ещё пару кнопок нажать.
3. Через "обеспеченность" смотрим, сколько нам реально не хватает чего из "группы 2", что нужно запускаем в желаемом количестве (тоже не сложно).

В некоторых случаях п.2 и 3 могут повторяться. Когда есть узел, который может быть изготовленным целиком заранее и сложенным на склад в каком-то количестве, и в тоже время, в составе его, в свою очередь, есть сборочные единицы или детали, которые сами по себе, отдельно взятые могут быть в каком-то количестве сделаны заранее и сложены на склад.

Дальше, по опыту, в реальном производстве всё упирается в целесообразность отнесения в реальной жизни тех или иных позиций к "группе 1" или к "группе 2", и обеспечении должного порядка в самом производстве на эту тему. Опять же, какие-то совсем мелкие и простейшие детальки из "группы 2" можно для упрощения вообще не учитывать по приведенной схеме, а просто считать "расходником": материал на них списывать по факту, а работы по их изготовлению учитывать через терминалы, как "вспомогательные" (вроде погрузки, зачистки материала дополнительной, если плохой пришел и т.п. - одним словом "вспомогательная работа", которую иногда от случая к случаю нужно делать, без дальнейшей детализации и учёта).

Тут много подводных камней.

1. Ну, как бы, когда одно "дерево" - это ещё ладно. А вот когда их ...дцать таких "деревьев" одновременно в работе, да плюс по ходу прямо они меняются в процессе, приостанавливаются, приоритеты меняются и т.д. - вот тут несколько сложнее всё получится. Мягко говоря.

2. Чем больше изделия и больше "уровней разворачивания", чем чаще в них что-то меняется или появляются новые, тем больше риск "сбоя" по пути. Кто-то где-то забыл количество поставить. Единицу измерения случайно или по незнанию не ту поставил. "Место хранения" какое-нибудь оказалось неизвестно для чего-то (может, так и задумано, а может и нет, программе откуда знать?) - не попало в "потребность" итого. И т.п. Вариантов много. Когда делаешь по шагам и контролируешь визуально (не цифру в каждой строчке, но хотя бы основные этапы и отсутствие явных ошибок), как-то более осмысленно получается результат. Если всё делается автоматом, то запросто что-то (в т.ч. что-то важное) из за таких "сбоев по пути" может в итоге в результаты расчёта просто не попасть вообще, и ты этого даже не заметишь в большом массиве информации. Ну посчиталось что-то и посчиталось. Правильно-неправильно, ну фиг знает...

Вообще, я повторюсь в своем мнении. Мне кажется что в основном:
Да, в каком-то смысле проще  "отнести всё тотально к "группе 2", да и всё. В плане, что думать не надо. Есть алгоритм, делаем по нему всегда, не задумываясь.
Другая сторона палки - больше нажатий и действий получается. Больше "заказов". Ну вы сами знаете, в общем.
Но, в тоже время, если по каким-то позициям на самом деле в подавляющем большинстве случаев получается, что по сути то в конечном итоге запускаются партии реально по принципу "группы 1", то выходит "сам себе злобный буратино"... Получается, что делаем 1000 раз лишние по сути действия, из-за того, что теоретически, возможно, наступит некий 1001 раз, когда будет не так. Так, может, зайти с другой стороны и договорится, чтобы просто не делать в принципе с такими позициями этого "1001 раза" никогда? Если 1000 всё равно не делаем так.
Видел ещё другие примеры: когда "группа 2" по определенным позициям появляется не из-за объективной какой-то необходимости или явных плюсов, если делать именно так. А из-за элементарно отсутствия порядка. Не потому было сделано больше, что нужно реально так было, а просто потому что кто-то взял и сам решил так сделать. Ему лично показалось, что так будет лучше. Видел и такое. Тут в плане планирования какого-либо, программы, управления совсем плохо все. Никакие расчёты и программы не помогут, пока не наведешь порядок. Ибо как реально что-то планировать, когда ты предполагаешь (даешь задание) делать одно, а по факту получаешь другое, заранее не зная что? Получается не управление процессом с помощью программы а "вечная погоня" за ним. Что-то навводили в программу - оказалось не так на самом деле. Исправили. Пока исправляли - стало уже опять не так. И так далее, до бесконечности...
Хотя, есть и другие совсем примеры, конечно...

Важное пояснение:
Я тут в данном случае не намекаю ни на что, и не говорю, что Вы именно неправильно что-то делаете. Я не знаю просто про Вас. У меня недостаточно информации. Просто делюсь опытом, как бывает. Написал, потому что просто видел случаи именно такие в жизни. Когда неоправданно усложняется весь процесс из-за неких очень редких, фактически гипотетически возможных случаев. Или просто из-за отсутствия порядка. Как видел и ровно обратные примеры: когда люди принимая и реализуя определенные правила для себя самих путем несложных управленческих воздействий резко сами себе упрощали жизнь в плане того же планирования и учёта.