Прекращение поддержки работы VOGBIT на оборудовании x86 - В 2025 г. мы планируем прекратить поддержку работы VOGBIT в 32-битных (x86) операционных системах

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

Распределение работ. Дискретность настройки - Прочее
Константин Чилингаров: Здравствуйте, В этом окне, насколько я помню, сохраняется только список "постов" выбранных. При закрытии/открытии окна. Порядок сл ...
«Шаблон техпроцесса» - Состав и технология
Sidneyanton: Спасибо, за подробное разъяснение!
VOGBIT Онлайн - Общие вопросы
Владимир Белов: написал: Добрый день! Такой вопрос. Могу я установить базу данных на съемный диск и пользоваться на разных компьютерах - переставляя то ...
Создание нового производственного задания - Производство
Константин Чилингаров: Здравствуйте, написал: еперь при создании заказа в окне "Производственные заказы" этот самый заказ "дублируется" в окне " ...
Вопрос на тему "Технология подробно" - Состав и технология
Zms.komissarov: Нужно открыть, какой-нибудь (из какого удобно печатать) вариант "подробного" графика производства, там выбрать соответствующую опе ...
Не отображается выпадающий список, а также неактивна кнопка "Импорт" - Ошибки в работе
Сергей: написал: Не отображается выпадающий список при нажатии на стрелочку Напишите на mailto:info@vogbit.ru info@vogbit.ru Попробуем починить
Вывод DXF или моделей в отдельную папку - Терминалы
Константин Чилингаров: Здравствуйте, Обычно, непосредственно с терминала выгружают управляющие программы какие-нибудь, к заданию, которое берется в работу. Н ...
График производства. Выполнение (по выделенным) - Производство
Zms.komissarov: Спасибки.
Комментарий к операции - Состав и технология
Zms.komissarov: Спасибо.
Пример создания плагина - Плагины
Bochik_88: С этим вопросом разобрался, спасибо)
Состав изделия - Состав и технология
Константин Чилингаров: К сожалению, проблема хронического отсутствия времени пока не позволила сделать. Лежит заготовка под второй ролик с лета. Пока отложена ...
График производства. Не отображает ТТП. - Производство
Константин Чилингаров: написал: Честно говоря, "средний" уровень как-то никогда не рассматривали для работы. Всё меняется... 10 лет назад там действитель ...
Множитель - Состав и технология
Константин Чилингаров: написал: Можно, пожалуйста, выложить скрины, как это реализовано Пожалуйста: Рис.1 - Параметры в справочнике. Которые я использовал, ка ...
Ошибка программы после обновления - Общие вопросы
Константин Чилингаров: Здравствуйте! Да, встречали такую ситуацию. Но, к сожалению, пока никак не можем научиться её стабильно повторять. Не можем пока найти к ...
Календарный план - Прочее
Veruz: Благодарю за ответ.
Установка - Установка
Константин Чилингаров: Здравствуйте, На совсем понял, если честно вопрос в Вашей терминологии. Давайте попробуем ещё раз разложить всё по полочкам…   Вы ...
Обновление тестовой базы - Обновление
Glavtech: Спасибо, проблема устранена
Сортировка по алфавиту и фильтр - Интерфейс программы
Константин Чилингаров: Здравствуйте, Ок. Принято. Записал в список пожеланий. Спасибо!
Единица нормирования при создании производственных заданий - Состав и технология
Константин Чилингаров: Здравствуйте, Вместе с расчетом материала на 7 шт. еще и штучное время поделилось на 7 В этом есть логика. Обычно эту "единицу нормир ...
На экране "распределение работ" при обновлении происходит смещение вправо. Приходиться каждый раз проматывать обратно - Производство
Константин Чилингаров: Здравствуйте, Не совсем понятно. Если речь идёт об окне, где отражается график работы и загрузки постов по дням и сменам (высокий/максим ...

Учет заделов по сборочным единицам

Всё, что связано с расчётами и учётом материалов, покупных изделий, комплектующих и др. ТМЦ - Материалы, Комплектующие, Складской учёт - Работа с программой
Страницы: 1
Учет заделов по сборочным единицам
 
Здравствуйте Константин

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

Цитата
написал:
Как наиболее простым способом получить производственный заказ на изделие с учетом заделов по складу составляющих его узлов и деталей если на складе могут быть как отдельные узлы так и детали для них ? (не только детали).

По принципу «Матрёшки». По шагам.

Сначала делаем производственный заказ на сборку нужного кол-ва изделий «А».
Без всяких расчётов комплектации, заказных спецификаций и т.п.
Просто заказ на сборку изделия «А» в нужном количестве. Из одной строчки, грубо говоря.

К нему делаем ЛЗК (или «Предварительные заявки») – то есть запрос на получение со склада всего, что необходимо для сборки заданного количества изделий «А».

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

Дальше по аналогии, то же самое. Для созданного производственного заказа на сборку изделий «Б» и «В» формируем запрос на склад (ЛЗК/Заявку) на то, что нужно для сборки заданного кол-ва таких сборочных единиц. Смотрим обеспеченность. Если чего-то не хватает, то формируем производственный заказ на изготовление этого. В процессе определяемся с количеством, сколько этого сейчас имеет смысл запустить.
Кстати, в более сложных случаях и не всегда и производственный заказ. Можно, например, если своих мощностей не хватает, и заказать что-то где-то на стороне в этот момент (то есть, по сути, вместо заказа на производство сделать заказ на «закупку»).

И так далее…
Если уровней вложенности больше трёх (то есть в «Б» и «В» входят ещё подсборки, которые могут быть на складе, которые, в свою очередь, состоят из деталей, которые могут быть на складе), то количество итераций, соответственно, увеличивается.

Это общий универсальный принцип. Гарантированно работающий. В том числе и при не очень качественных исходных данных, и при наличии в них ошибок (что, в общем, не редкость). И с учётом разных возможных нюансов.
Правда за универсальность и работоспособность в любых условиях приходится в более простых случаях платить несколько большим общим количеством действий.

В чем плюсы такого способа:
1. Он работает в т.ч. и на больших изделиях и достаточно сложных производствах. Когда на каждом "шаге" принцип определения количества сколько конкретно сейчас чего запускать из того, чего не хватает, может отличаться. "Шаги" эти могут быть разнесены во времени, а не сразу сверху до низу все проходиться за раз. Решения по разным позициям по запуску могут принимать разные люди. Что-то вообще может на сторону быть отдано. И т.п.
2. Контролируемый полностью процесс на каждом "шаге". Например, если кто-то в технологии где-то в комплектации забудет количество указать, единицу измерения неправильную поставит и т.п., то это можно (с достаточно высокой долей вероятности) сразу в процессе на соответствующем "шаге" выявить (глазами просто увидеть). А если все будет считаться автоматом "под столом" и из-за каких-то таких ошибок пара позиций (из 1000, например) просто "выпадет", то никто этого даже и не заметит, скорее всего, на общем фоне. И может потом в конце это очень боком выйти...



Что тут нужно ещё понимать и учитывать:

Первый момент:

Данный принцип и механизм заточен, в первую очередь, под большое достаточно производство с реальным буферным складом между механическими цехами и сборкой. С большой унификацией деталей и узлов. То есть, когда реально между цехом(ами), который делает детали, и сборочным производством есть большой склад. На этом складе реально постоянно куча всего: сборок, подсборок, деталей. И сборка комплектуется именно со слада. В момент комплектации очередного заказа там обычно почти все есть уже готовое. За редким исключением. И сборку мало волнует, что там и как делает в данный конкретный момент цех, и что в каком количестве он там у себя запускает. Главное, чтобы вовремя комплектовались заказы. А цех занимается постоянным поддержанием нужной комплектации. С оглядкой на будущие потребности сборки (уже известные на сегодня). С запасом по ходовым позициям.
Что-то вроде такого…

Именно под такого рода организацию производства изначально был заточен вариант работы с программой, описанный выше. При том он достаточно универсален, и будет работать и в более простых случаях тоже. Но отчасти, получится из серии «из пушки по воробьям».

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

Была ещё такая идея:
реализовать некий «Мастер проверки обеспеченности и создания заказов». Чтобы, с одной стороны, сохранить общую универсальную схему и принцип (что описано в начале сообщения), которые работают и в более сложных случаях тоже. А с другой стороны, часть «рутинных» действий, которые при более простых случаях просто «прощёлкиваются на автомате» по одинаковому алгоритму (открыть окно, поставить фильтр, нажать кнопку, ничего не меняя нажать «Ок», закрыть окно, открыть другое окно, там выбрать то, что создали из предыдущего, нажать кнопку и т.п.) – автоматизировать, чтобы они просто сами "Мастером" "под столом" выполнялись.
Пока тоже только в рамках идеи. Не нашло пока горячей поддержки среди пользователей. Ещё лучше платёжеспособной  :) .


Второй момент:

Есть на самом деле ещё один подход в данном случае - если не считать тотально все детали в изделии «задельными» (то есть изготавливаемыми заранее и с запасом), а поделить все детали и узлы в изделии на 2 группы:
- те, которые делаются партиями и берутся сборкой со склада (группа «со склада» назовём их).
- те, которые никогда не делаются в задел, а только в том количестве, сколько нужно на конкретную партию, конкретных изделий.

Под такую схему в VOGBIT есть хорошо работающий механизм «групп планирования». Общий принцип: когда запускаю изделия «А», то в производственный заказ сразу попадают не только сами изделия «А», но и сразу все входящие позиции, кроме тех, которые помечены, как «со склада» (вот тут как раз с заполнением через «расчёт комплектации», с заказными спецификациями, но с определенными нюансами). А вот те узлы/детали, которые «со склада» - они по методу «Матрешки», но только они.

Тоже вполне работоспособное решение. Может сильно упростить планирование и отслеживание. Но требует определенных усилий от руководства в организационном плане. Чтобы на «группы» эти правильно поделить. Чтобы всем причастным объяснить, как и что делаем и почему так. Зачастую руководителям либо просто не хочется в это вникать и заниматься, и действует принцип «Да ладно, пусть все детали и сборки будут «со склада», да и всё, чего заморачиваться?», либо на самом деле в конкретном случае «овчинка выделки не стоит». Соответственно, тогда возвращаемся к общей универсальной схеме, описанной в начале сообщения.
 
Здравствуйте Константин

Все понятно. Спасибо. Так и сделал. Просто данный вопрос не очень понятен из описания. А вопрос на мой взгляд весьма важный. Возможно имеет смысл добавить эту информацию в руководство по Обеспеченности ?
 
Подумаем.
Вообще есть в планах со временем сделать отдельный демо-пример (с руководством к нему) на тему "Обеспеченности". Но начнем, наверное, там с более простых вещей. Для начала.
А там посмотрим.
Спасибо за предложение!
Страницы: 1
Сейчас на форуме
Всего зарегистрированных пользователей: 4114
Приняло участие в обсуждении: 426
Всего тем: 804
Всего сообщений: 6067

×
Вход на сайт