Изменение цен на лицензии - С 01 мая 2024 г. изменятся цены на лицензии ПО VOGBIT

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

Нормы расхода на окраску - Состав и технология
Lyovushkin: Спасибо буду пробовать
Ошибка печати отчета - Отчёты
Константин Чилингаров: Здравствуйте, В версии VOGBIT 23.1.8 (последнее обновление на сегодня, которое недавно вышло) заменены шаблоны отчётов "приходный ордер" ...
VOGBIT Онлайн - Общие вопросы
Константин Чилингаров: Здравствуйте, Клиентское приложение VOGBIT в данном случае ставится не на ваш конечный компьютер, а на сервер. А вы работаете с ним через и ...
Планирование производства - Демо версия
Константин Чилингаров: API есть. Описания базы данных нет (и вряд ли будем делать в ближайшее время). Есть /forum/forum35/ раздел на форуме . Там примеры использования AP ...
Как отслеживать все детали, входящие в заказ? - Прочее
Константин Чилингаров: Чуть добавлю: Ответ кратко: Да, можно будет продолжать работать с тем, что ввели в "демо-версии". Дополнение к предыдущему сообщен ...
Ошибка при открытии спецификации - Прочее
Константин Чилингаров: Здравствуйте! Версия программы старовата. Хорошо бы обновить. Когда-то, давным-давно, кажется, была такая ошибка, но её быстро починил ...
Учет материалов - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Здравствуйте, Вкладка меню "Складской учёт" -> Алгоритм списания -> FIFO.
Обороты по складу - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Здравствуйте, Это какими-то настройками или ещё как-то самостоятельно не решается, к сожалению. Нужно форму экранную саму поменять нем ...
Удаление позиции из номенклатуры - Прочее
mansur: Доброе утро, спасибо, все сделал по второму варианту. 
Ошибка при входе в Vogbit - Прочее
Григорий Клеков: написал: Здравствуйте. ...
Установка Демо версии - Демо версия
Amg: Спасибо большое за ответ. Демо-версию установил на ноутбук, если руководство решит перейти на ваш продукт, то думаю видеоконференция буд ...
Хранение файлов в БД - Общие вопросы
Константин Чилингаров: Если при этом вы хотите потом использовать штатные возможности VOGBIT (например, просматривать эти прикрепленные к операциям файлы в окне ...
Предварительные заявки, ЛЗК, Требования - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Здравствуйте! Периодически возникают похожие вопросы по "Предварительным заявкам", "ЛЗК", "Требованиям". В чём разница, ...
Конструктор фильтра - Прочее
Kochurova.av: Спасибо Вам большое!  Всё как всегда оказалось проще простого)
Свои поля для справочников и вывод их в список. - Общие вопросы
Константин Чилингаров: Здравствуйте, В "Номенклатуре" стандартно есть свойство "Комментарий" и соответствующая колонка в современных версиях VOGBIT ( ...
Список работников поста - Общие вопросы
Константин Чилингаров: Пожалуйста! Пользуйтесь)) Нет. Ссылку не нужно выкладывать. Потом, когда общее обновление соберем, выложим его на сайт, и все смогут ска ...
Вопрос по импорту - Экспорт импорт данных
mansur: Нашел, залил и все работает теперь, спаибо.
Ошибка при запуске приложения - Прочее
Сергей: написал: Если на другое железо переставить Вогбит, как лицензию нам перекинуть? на mailto:info@vogbit.ru info@vogbit.ru  напишите со ссылкой на эту тем ...
Пример создания плагина - Плагины
Сергей: Здравствуйте! Перетащите мышкой из "команд" (рис.3) в нужное место на панели инструментов
Помощник мастера - Установка
Trudovaya-21: Спасибо Вам ОГРОМНОЕ за работу и понимание!!!

Создание заказа на производство с учетом остатков/задела

Другие пожелания и предложения - Прочее - Пожелания и предложения
Страницы: 1
Создание заказа на производство с учетом остатков/задела
 
Примерное обсуждалось ранее, может новые способы появились.

Производство не большое. Изделия имеют до 4-6 уровней вложенности сборки. Что-то между мелкосерийным и позаказным. Некоторые сборочные единицы разной вложенности применяются в нескольких изделиях, детали впрочем также. Присутствует сезонность. Не в сезон, можем сработать на склад по каким-то деталям или сборкам. Цикл производства изделия может занимать, иногда, полгода и более. Есть масса деталей которые держать на складе нет смысла или даже вредно, поэтому "празитные" бумажные принять-выдать - зло. Покупные и подобное пока опустим.

Логично выдать производству по заказу следующий перечень данных: чего и сколько произвести, что взять на складе  (или  в пути или в незавершенном, неважно как в общем) отдельными деталями или уже собранными узлами, сколько надо материалов и покупных.
И вот с подготовкой такого перечня в вогбит проблема.
Некоторые варианты испробованы. Забудем пока про бумажное сдал/принял.

Первый.

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

Второй.
В техкарту заказа ставим только само изделие (сборку верхнего уровня). Рассчитываем потребность по этой техкарте, в технологии же у нас описано что в изделие входит. Сохраняем расчет, пусть как, предварительную заявку. По этой заявке смотрим обеспеченность и заказываем столько, сколько нужно новым производственным заказом или новой техкартой к первому. Теперь рассчитываем обеспеченность по вновь созданной техкарте.  И проделать это придется столько раз сколько уровней вложенности+1. Вроде вот он путь. Только забор заявок, заказов или техкарт делает заказ похожим на фарш. Гибкость системы позволяет сформировать ЛЗК на весь заказ. И в ЛЗК будет получить все детали  и сборки (и изготавливаемые и те, что там уже есть) со склада. Можно конечно отсортировать или/и сгруппировать где надо и все узнать. По итогу танцев с бубном заказ на изделие превратился в стопку отдельных заказов на каждый уровень вложенности и не сильно понятные документы на получение, да еще и придется все изготовленное оформить на склад. А потом выдать. Иначе считать начнет не так. По сути - наплодили виртуальных сущностей и понятней не стало. Работы стало больше, проще не стало. К понятному заданию на производство мы не пришли.

А что, если техкарту заполнить вручную, с учетом остатков, раскрыть все подсборки. Идея безумная, не для того все это мы затеваем, но всеж. Это будет как, заказная спецификация, только количество поправим. И расчет потребности не захочет посчитать так, как надо((. Допустим в сборку входит 10 одинаковых деталей, а в спецификации мы оставим их только 8 (2 есть готовых). Расчет потребности посчитает материал на эти 8 деталей и не посчитает что, 2 недостающие нужно взять со склада.  


Дальше фантазии.
Нужно составить техкарту и посчитать потребности правильно.
С потребностями, видимо, решить просто.
А вот техкарту.. Скрестить расчет комплектации с обеспеченностью. На вход техпроцесс изделия(й). Раскрываем первый уровень, с учетом остатков создаем список, если есть куда раскрывать - раскрываем с учетом обновленных остатков...


 
 
Цитата
написал:
Примерное обсуждалось ранее, может новые способы появились.
Вот тут последний раз.

Из серии именно "разворачивания" принципиально нового не появилось чего-то. Так, доводка того, что было...
Какие идеи есть, в принципе, на эту тему - обсуждалось по ссылке выше.

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

Цитата
написал:
Есть масса деталей которые держать на складе нет смысла или даже вредно
Вам, возможно, подойдёт схема с использованием "групп планирования". Поделить все детали и узлы на "группы" - кто бывает в заделе (на складе, соответственно), а кто нет. И потом сразу при формировании заказа большая часть, скорее всего за 1 заход сформируется в производство. А остальное уже через "Обеспеченность".
Резко сокращает количество действий в программе и упрощает. Как в плане "разворачивания матрёшки", так и в плане того, что не нужно "сдавать/выдавать на склад" то, что физически реально не сдаётся туда на самом деле. Кратко по этому способу есть по ссылке в начале сообщения.

Цитата
написал:
Используя состав изделия по заказной спецификации рассчитаем обеспеченность и отминусуем, то что есть.
Нет. Неправильный способ. Сразу отметаем.

Цитата
написал:
В техкарту заказа ставим только само изделие (сборку верхнего уровня).
Рабочий вариант. С определенными недостатками. Но они проистекают от того, что этот вариант заточен под определенную ситуацию, определенным образом организованное производство (большое, обычно). И в таких условиях, как те, подо что данный способ заточен, он хорошо работает. Когда его начинаешь применять в случаях он не совсем таких до совсем не таких (что встречается часто в более простых и маленьких производствах), то начинает выглядеть несолько "громоздко".
Подробно это все перетиралось по в теме по ссылке в начале сообщения.
Там же приводились и наши идеи, что ещё можно было бы сделать по теме. Но пока, за отсутствием реального (платежеспособного, желательно) спроса, отложено, занимаемся более срочными вещами...

Цитата
написал:
Скрестить расчет комплектации с обеспеченностью. На вход техпроцесс изделия(й). Раскрываем первый уровень, с учетом остатков создаем список, если есть куда раскрывать - раскрываем с учетом обновленных остатков...
Была такая идея. Что-то немного на эту тему было,  вроде бы, даже в обсуждении по ссылке выше.
На мой взгляд будет жизнеспособно, и наверное, удобно, в случае когда в контексте изделия/заказа ситуация по большей части компонентов из серии "скорее всего нет на складе, но может что-то и есть".
Грабли при таком подходе будут разложены вот в каком месте:
Предположим, вы "запланировали" потратить что-то, что есть на складе сейчас, под некий заказ. Всё спланировали, посчитали, запустили.
Через неделю ситуация поменялась... И по какой-то, не важно какой, причине, вы решили то, что собирались взять со склада для этого заказа, срочно взять для чего-то другого. Ну нужно так стало... Причем, не всё, а часть.
Вот тут начнутся танцы с бубном...
Где что и как поменять, чтобы все сошлось в итоге.... И ничего не забыть при этом...
А если через неделю обратно? Или ещё раз такая же ситуация но с другой позицией? Вот тут граблей разложено будет целое поле....
В то время как способ с "матрешкой", он то как раз отрабатывает все такие ситуации корректно и, что важно, автоматически. Забрали не на то, на что изначально собирались? Ну и не проблема. Само все пересчитается автоматом (обеспеченность), покажет, где и чего когда нужно теперь (или не хватает). Никаких при этом правок чего-то ранее созданного/запущенного - ничего не нужно вообще.

Вот какая штука ещё есть... Тут может так получиться при определенных обстоятельствах, что упрощая себе жизнь сейчас и в одном месте, потом усложняешь её себе же потом, сильно, и в других местах. Не обязательно, конечно, но вариант такого развития событий тоже нельзя не учитывать...  
 
Цитата
написал:
Вот тут  последний раз.Из серии именно "разворачивания" принципиально нового не появилось чего-то. Так, доводка того, что было...Какие идеи есть, в принципе, на эту тему - обсуждалось по ссылке выше.


Этого обсуждения не видел. Вопрос там, действительно, тот же. И решения те же.
Цитата
написал:
Вам, возможно, подойдёт схема с использованием "групп планирования". Поделить все детали и узлы на "группы" - кто бывает в заделе (на складе, соответственно), а кто нет. И потом сразу при формировании заказа большая часть, скорее всего за 1 заход сформируется в производство. А остальное уже через "Обеспеченность".
Не подойдет. Есть много деталей из листа разной толщины, разной формы и размеров. Формируется раскладка раскроя по листам и остаются свободные участки произвольной формы, каждый раз разные. Можно вставить туда какие-то детали для заполнения, что лучше влезло то и вставили (та еще магия, но план тут не построить). Это один из нескольких примеров, как рождаются эти запасы.
Цитата
написал:
Рабочий вариант. С определенными недостатками. Но они проистекают от того, что этот вариант заточен под определенную ситуацию, определенным образом организованное производство (большое, обычно)..
Дело не только в размере производства. Это заточка на серийное производство, когда количество произведенных изделий много больше их номенклатуры. А у нас котел 25 тонн в сборе, около 4000 штук деталей 300 наименований в 62 сборках и это без покупных, метизов и вспомогательного оборудования. Срок от заказа до отгрузки 3-6 месяцев. Поэтому разворачивание заказа по схеме заказ-расчетКомплектации-заявка-обеспеченность-заказ создает много несуществующих промежуточных сущностей и надежно скрывает что и для чего заказано. Да и многократное путешествие по разным вкладкам и модулям, где можно, что то не включить или наоборот, не способствует сокращению ошибок.
Цитата
написал:
Но пока, за отсутствием реального (платежеспособного, желательно) спроса, отложено, занимаемся более срочными вещами...
Это, к сожалению, не в моей власти.

Иногда предложение рождает спрос. Уверен, найдутся: "А что, так можно было? Дайте две."
Цитата
написал:
Грабли при таком подходе будут разложены вот в каком месте:Предположим, вы "запланировали" потратить что-то, что есть на складе сейчас, под некий заказ. Всё спланировали, посчитали, запустили.Через неделю ситуация поменялась... И по какой-то, не важно какой, причине, вы решили то, что собирались взять со склада для этого заказа, срочно взять для чего-то другого. Ну нужно так стало... Причем, не всё, а часть.Вот тут начнутся танцы с бубном...
Тут такое дело: корректировки, дозаказы, мелкие попутные заказы - сплошь и рядом. Но тут (мелкие и простые заказы, даже рядом с большими) формируются легко и "обеспеченность" работает отлично.
Цитата
написал:
В то время как способ с "матрешкой", он то как раз отрабатывает все такие ситуации корректно и, что важно, автоматически.
Автоматизировать бы матрешку, да в одну техкарту..
Цитата
написал:
Расчет потребности посчитает материал на эти 8 деталей и не посчитает что, 2 недостающие нужно взять со склада.  
Может кнопочку какую добавить, считать так, сяк..
 
Цитата
написал:
Есть много деталей из листа разной толщины, разной формы и размеров. Формируется раскладка раскроя по листам и остаются свободные участки произвольной формы, каждый раз разные. Можно вставить туда какие-то детали для заполнения
Знакомая история.
Встречались с такой задачкой, только немного с другой стороны. Как учесть эти "доп. детали" и "провести их через программу", чтобы штатным образом на них "задания" сформировались в VOGBIT, потом на склад их можно было сдать по стандартной процедуре из производства, при том, что заранее невозможно составить "производственный заказ", т.к. неизвестно, сколько и чего будет "доложено". Это никто не знает, кроме технолога, который, собственно, докладывает эти детали при раскрое для заполнения пустых мест на листе. И он сам не знает, пока не разложит  :) .
Делали даже специальную функциональность для такого случая. Чтобы корректно учитывать такие дополнительно появившиеся детали. Делается в процессе интеграции с раскройными программами. Вроде такого: пример, пример, пример.

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

Цитата
написал:
Автоматизировать бы матрешку, да в одну техкарту..
Подумаем...
 
Вот, кстати, вопрос:

Цитата
написал:
котел 25 тонн в сборе ....... в 62 сборках
И что, любую из этих 62-х сборочных единиц вы можете без заказа на котёл, просто заранее, на всякий случай, сделать в задел, полностью собрать и положить на склад? Просто, чтобы была, может, понадобится?
Что-то мне подсказывает, что вряд ли это так... ;)
А значит, за счёт "групп планирования" таки можно сократить количество шагов в "матрешке". Причём, возможно" очень значительно. Вплоть, может быть, даже до 2х-3х. А это уже сильно облегчает ситуацию.
Но так, смотреть нужно, конечно. Чтобы более точно сказать.  
 
Цитата
написал:
И что, любую из этих 62-х сборочных единиц вы можете без заказа на котёл, просто заранее, на всякий случай, сделать в задел, полностью собрать и положить на склад? Просто, чтобы была, может, понадобится?Что-то мне подсказывает, что вряд ли это так...  А значит, за счёт "групп планирования" таки можно сократить количество шагов в "матрешке". Причём, возможно" очень значительно. Вплоть, может быть, даже до 2х-3х. А это уже сильно облегчает ситуацию. Но так, смотреть нужно, конечно. Чтобы более точно сказать.  
62 - это вхождения сборок, уникальных меньше. Есть сборка "дверца". Она применяется в других сборках и эти сборки находятся на разных уровнях вложенности.

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

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

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




 
 
В целом, проблема понятна.
Будем думать, конечно, как улучшить. По мере наличия времени.
К сожалению, не получается всем одновременно заниматься, чем бы хотелось...
Страницы: 1
Сейчас на форуме
Всего зарегистрированных пользователей: 3987
Приняло участие в обсуждении: 415
Всего тем: 804
Всего сообщений: 6067

×
Вход на сайт