Большое обновление системы. Новая версия VOGBIT 21.2 - Выпущено большое обновление программы. Значительные изменения произошли как в обще-системной части, так и в плане расширения возможностей программы и повышения удобства работы с ней.

Последние темы на форумах VOGBIT

Редактирование состава заказа - Прочее
Константин Чилингаров: Здравствуйте, Нужно обновить программу вам на самую новую версию. Новее, чем та, которая сейчас на сайте выложена. В прошлом году осень ...
Штрих код на деталях - Производство
mansur: написал: Возникает вопрос по имеющимся вводным: А что так сложно то? Зачем? Оператор на первой операции может некоторые заготовки забр ...
Распределение работ - Производство
mansur: Благодарю вас, Константин.  Будем практиковать, в принципе ничего сложно нет.
Приемка ОТК - Производство
mansur: написал: После сдачи из производства продукция попадает не сразу на склад, а не контроль (технически – отдельный «склад» в программе). ...
Обслуживание БД - Прочее
Владимир Белов: Павел, время доброе! Это логи SQL сервера, БД Vogbit на них не влияет. Я так понимаю, у вас SQL Server установлен на Linux? На Linux по умолчанию не про ...
Лимитные карты - Общие вопросы
Czvetkov-91: написал: купная, то в составе "производственного заказа" она вообще, в принципе, не должна никак фигурировать и присутствовать. Ей ...
Проблема с подключением к базе данных - Установка
Константин Чилингаров: написал: Можете скинуть мне ссылку с точной инструкцией установки SQL и программы? /support/5211/ Подробная инструкция Для "быстрой упр ...
Создание копии базы данных - Прочее
Владимир Белов: При восстановлении БД на другом SQL-сервере, "слетает" SID владельца БД. Для исправления: 1. распакуйте SQL-скрипт FixDbOwnerSid.sql из приложе ...
Обслуживание базы - Прочее
Константин Чилингаров: Здравствуйте, Взять тот же самый дистрибутив, с которого вы делали последнее обновление. Запустить Setup -> Выборочная установка -> Об ...
Ошибки ВОГБИТ - Общие вопросы
Константин Чилингаров: Здравствуйте, Окно "Детальный график" актуально только при использовании "максимального" уровня. Окно "Работы", помимо ...
Автоматическое обновление экрана. - Интерфейс программы
Константин Чилингаров: Имеется в виду, когда операции стрелочками "вверх" / "вниз" передвигаешь? Починено. В ближайшем обновлении будет исправлено. ...
ЕИ по умолчанию - Состав и технология
Константин Чилингаров: Здравствуйте, Можно написать плагин (будет кнопка специальная), чтобы на все выделенные строчки назначить выбранную единицу измерени ...
Печать чертежей - Обновление
Константин Чилингаров: Действие по двойному щелчку настроить нельзя. Можно настроить "горячую клавишу".
Автор ТП - Обновление
Константин Чилингаров: Я выше уже написал.  Что Ваше пожелание записано в общий список пожеланий и предложений. Когда очередь до него дойдёт, сказать сложно. ...
Назначить очередь - Производство
Fomina: Хорошо, попробую удалить параметр. Спасибо
Выделение текущей даты на графике - Интерфейс программы
Константин Чилингаров: Здравствуйте, Записал в общий список предложений.
Фильтрация по сортаменту материалов в графике производства и новом задании - Общие вопросы
Fomina: Спасибо, Константин
Помощник ориентации окна - Общие вопросы
Balukov: Здравствуйте. Нет. Эту штуку отключить нельзя. Такой вопрос был недавно. https://vogbit.ru/forum/messages/forum24/topic2724/message16739/2724#message16739 VOGBIT Прикрепление/ ...
Ошибка приложения - Прочее
Константин Чилингаров: Можно попробовать /forum/messages/forum15/topic1366/message8486/#message8486 сбросить сохраненные настройки . Может быть, поможет. Но вообще, версия очень старая ...
Прикрепление/открепление окон - Общие вопросы
Константин Чилингаров: Здравствуйте, Нет. Эту штуку отключить нельзя. А чем она так сильно прямо мешает?

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

Подготовка исходных данных, описание изделий и процесса их изготовления - Состав и технология - Работа с программой
Страницы: 1
Внесение состава изделия, состоящего из большого числа вложенных сборок.
 
Добрый день!
Возник вопрос по добавлению сборочных единиц, да и в целом по работе модуля Состав изделия.

1. Отсутствуют кнопки, отвечающие за добавление деталей и компонентов
вот так выглядит у меня



так в Вашем примере



Или теперь все делается через первоначальное создание деталей и изделий в базе, а потом из них собирается структура?

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



но только в данном случае уровней всего 3, а у нас на производстве таких уровней в глубину может быть в разы больше - 10-15 в глубину. То есть у меня есть например такая вот структура:



Соответственно, я бы хотел полностью ее отобразить в Составе изделия.

3. Понимаю, что вопрос больше импорта касается, но все же и состав он тоже задевает.

Стандартных средств по импорту состава изделия через xml/csv как я понимаю нет? Это все уже относится к доп. работам по внедрению?
 
Цитата
Sassa_s написал:
Отсутствуют кнопки, отвечающие за добавление деталей и компонентоввот так выглядит у меня
Всё правильно.
Эту нижнюю панель отломали много лет назад. Осталась только на старых картинках.
Убрали, потому что никто не пользовался. Неудобно.
Проще 2 окна повесить: "Номенклатура" и "Состав", вводить и мышкой перетаскивать.
Удобнее и быстрее.
В общем, эта панелька нижняя не прижилась. Неудачная идея. Никто не понимал и не пользовался. Убрали.

Цитата
Sassa_s написал:
Или теперь все делается через первоначальное создание деталей и изделий в базе, а потом из них собирается структура?
Да. Так проще и быстрее.

Цитата
Sassa_s написал:
Если я хочу сделать сложный состав изделия, состоящий из многоуровневых сборок - как правильно мне их заводить в систему?
Завести обычные конструкторские спецификации сборочных единиц (всех, какие там есть), потом нажать кнопку и "дерево" из них само построится. Пример

Цитата
Sassa_s написал:
но только в данном случае уровней всего 3, а у нас на производстве таких уровней в глубину может быть в разы больше - 10-15 в глубину
Не имеет значения.
Просто больше сборочных единиц разных. Принцип никак это этого не меняется.
Мы дизель полностью заводили (несколько тысяч позиций) как-то раз. Нормально, в целом.

Цитата
Sassa_s написал:
Соответственно, я бы хотел полностью ее отобразить в Составе изделия
Нет ничего проще :)
См. выше. Вводим спецификации сборочных единиц. Нажимаем кнопку - из них получается дерево (заказная спецификация).
Если вопрос в том как правильно, и именно "состав", то так правильно.
Вопрос - нужно/не нужно всё полностью и именно в таком виде - оставляем за скобками. Это от задачи зависит на самом деле.
Когда сложные изделия, то обычно да, полезно.

Цитата
Sassa_s написал:
Понимаю, что вопрос больше импорта касается,
Вот это - неочевидная совсем, с моей точки зрения, мысль.
"Состав" - составом. "Импорт" - импортом.
Импорт - это просто автоматизация ввода. Можно руками добавить все детали в "номенклатуру", перетащить их в спецификацию, проставить количество. Импорт делает всё ровно то же самое по сути, только программа это делает. Быстрее получается. В некоторых случаях...
А в плане "правильности"/"неправильности" и общей логики - нет разницы вводить руками спецификацию или "импортом" заливать. Можно и руками сделать неправильно, и импортом криво залить. Как можно и наоборот. А если всё правильно, то одно и то же в результате и получится.

Цитата
Sassa_s написал:
Стандартных средств по импорту состава изделия через xml/csv как я понимаю нет? Это все уже относится к доп. работам по внедрению?
Стандартный модуль загрузки спецификаций из Excel - 15 т.р.
Если интересно, пишите на почту. Вышлем описание краткое: для чего предназначен, что входит в стоимость.
Если хочется загружать из какого-то своего формата, то это за отдельные деньги.
 
Константин, добрый день. Помогите на конкретном примере разобраться как внести материал в заказную спецификацию. Готовое изделие: мебельный фасад розового цвета. Для облицовки плиты МДФ используем смесь хим. компонетов. В смеси присутствует цветная паста розового цвета. Эта паста розового цвета состоит из 4 покупных монопаст: зеленой, бежевой, белой и красной. При внесении материалов в заказную спецификацию программа не дает внести 4 цвета пасты. Только розовая паста и один цвет монопасты. Вопрос в том как можно указывать несколько компонентов в заказной спецификации, соответственно указывать расход и технологию изготовления смеси?
 
Цитата
Hohlova написал:
Константин, добрый день. Помогите на конкретном примере разобраться как внести материал в заказную спецификацию. Готовое изделие: мебельный фасад розового цвета. Для облицовки плиты МДФ используем смесь хим. компонетов. В смеси присутствует цветная паста розового цвета. Эта паста розового цвета состоит из 4 покупных монопаст: зеленой, бежевой, белой и красной. При внесении материалов в заказную спецификацию программа не дает внести 4 цвета пасты. Только розовая паста и один цвет монопасты. Вопрос в том как можно указывать несколько компонентов в заказной спецификации, соответственно указывать расход и технологию изготовления смеси?
Не указала: каждый компонент мы принимаем как деталь, а смесь как сборочную единицу.
 
Здравствуйте,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приведу наш пример:

Фасад односторонний (есть еще и двухсторонние и витрины и т.д. другие конструкции) розового цвета:
Состав одностороннего фасада розового цвета:
1.Плита МДФ, облицованная составом для плиты с одной стороны и потом распиленная в размер заказчика;
2.Кромка по периметру приклеенная (состав кромки - это некое вещество, его мы по рецепту делаем сами и потом формуем из него кромку), кромку тоже клеим на смесь (клей) собственного приготовления).
Идем далее. Состав для облицовки плиты и состав для изготовления кромки он разный, хотя он одного и того же цвета. Но есть в этих разных составах и общие "узлы". Эти "узлы" мы готовим тоже сами из покупных материалов. На склад эти "узлы" мы не сдаем и можем хранить до следующего дня в цехе (т.е. не четко под изделие, переходящие под следующее изделие).

Вопрос в следующем: как в технологию будет правильно занести эти "узлы". Повторюсь именно два "узла" входят в вещество для кромки и в вещество для облицовки поверхности МДФ. Не хочется "тащить" два раза одно и то же в материалы, да и разное количество этих "узлов берется" на облицовку МДФ и на приготовление состава для изготовления кромки. Либо у меня еще вариант, что сделать данные "узлы" полуфабрикатами и в спецификации конкретно на деталь "плита МДФ, облиц." и деталь "кромка" их внести? А далее в технологии мне останется указать их количество, в соответствии с расходом на 1 МДФ плиту? А остальные материалы тогда притяну со склада, так как они просто в определенном количестве берутся со склада в составы (для облицовки МДФ и для приготовления смеси кромки)?  
 
Цитата
Ирина Хохлова написал:
все таки думаю, что фасад это сборочная единица и спецификация нужна
Если "фасад" это некая конструкция, состоящая из нескольких отдельных "элементов" фасада, то да, это можно рассматривать, как сборочную единицу, в стандартном понимании этого слова или, по крайней мере, близко к нему.

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

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

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

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

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

Путь 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

×
Вход на сайт