Я бы, наверное, в вашем случае делал так:
1. Про «склады»
Промежуточный склад я бы в VOGBIT вообще, как «склад» именно не заводил. Не вижу пока смысла в этом какого-то.
Именно как «склад» в программе я бы завёл склад готовых деталей. И оформлял в VOGBIT передачу на него тех деталей, которые полностью готовы. И соответственно, оформлял бы выдачу с него готовых деталей на сборку (об этом см. ниже). А также выдачу сторонним каким-то организациями в случае, если эти детали продаются отдельно, как запчасти, например.
2. Про НЗП
Детали, находящиеся в разной степени готовности, оформил бы в VOGBIT, как открытый(е) «производственный заказ(ы)». И в этом производственном заказе соответствующие «партии» этих деталей, запущенные в производство.
Если одни и те же детали, но запущены по разным вариантам изготовления, например: часть полностью сами изготавливаем, и где-то там они в процессе, часть – отдаем отдельные операции сторонним контрагентам, и они тоже где-то в середине своего пути, то это соответственно будут разные «партии» с разными маршрутами. Что и отразил бы, соответственно, в технологии/заданиях для каждой такой партии.
Проставил бы в соответствии с текущей реальной ситуацией готовность по операциям по маршруту. Что где сейчас реально находится. И в дальнейшем бы это поддерживал в актуальном состоянии. Для начала на "среднем" уровне. А там видно будет...
Для деталей, которые, как вы пишете, месяцами ездят по кооперации, я бы завел дополнительно в маршруте «Транспортные» операции. Чтобы было понятно, по крайней мере, уехали детали к контрагенту, или нет, а также когда и сколько. Саму операцию, которая выполняется внешним контрагентом, в маршруте так бы и заводил обычной операцией («термообработка», например, «цинкование» и т.п.), только в качестве «исполнителя» («участка») для такой операции/задания ставил бы не свой участок, а стороннюю организацию. Такое можно в VOGBIT сделать. Отметка о готовности по самой такой операции (выполняемой внешним контрагентом) по смыслу означает, что детали эти приехали от подрядчика обработанные.
Это всё касается деталей полностью или частично обрабатываемые у себя, а часть операций по маршруту может делать подрядчик. Если детали полностью изготавливаются подрядчиком, из его собственного материала, то это оформляется в программе, как «заявка на закупку» у соответствующего контрагента данных деталей. И потом, когда пришли детали, соответственно, приход по этой «заявке» на склад.
3. Про сборку
Я бы всё-таки завел кое-что и по «сборке» тоже.
«Посты» сборочные и сварочные – вот это совершенно точно вам не нужно пока. И возможно вообще никогда вам «посты» именно не понадобятся. «Посты» - это вообще про другое и для другого.
Я бы завел по крайней мере сами изделия собираемые (обозначение, наименование) и технологию по ним, что называется, по «минимальному» уровню. То есть в техпроцессе изделия указал бы только комплектацию – что нужно получить (выдать) со склада для сборки данного изделия со склада (какие детали, сколько на 1 шт. изделия).
После чего сделал бы «производственные заказы» на сборку, что известно на текущий момент. Какие изделия, сколько штук надо будет собирать. Дата.
И к этим «производственным заказам» сборочным сделал бы штатными средствами ЛЗК – список деталей, что под них со склада нужно выдать будет (ради этого комплектацию в технологию, собственно, и заводили).
В чём тут плюс:
Во-первых, в «обеспеченности» сразу видно каких деталей из тех, что сейчас в разной степени готовности, хватает, а каких нет, и нужно ещё запускать или размещать заказы и сколько минимум.
Во-вторых, в режиме «обеспеченность по заказам» сразу выстроится «очередь» на комплектацию для сборки и будет сразу видно: на этот «заказ сборочный» (изделия) всё есть уже, все детали готовые есть, на этот «заказ» - не хватает столько то позиций, каких именно деталей, сколько по количеству нужно к какому числу. Сразу отсюда можно «провалиться» и увидеть, в каком сейчас состоянии изготовления эти детали, где они вообще находятся сейчас. Если уже находящихся в процессе изготовления деталей на все «сборочные» заказы недостаточно, то сразу будет видно, на каком месте уже запущенные детали «кончатся» (надо ещё запускать, чтобы к этому моменту были уже готовы и сколько должно минимум быть готово).
В-третьих, в режиме «Потребность в ДСЕ» видно будет сразу ситуацию со стороны заготовительного (механического) цеха: каких деталей из тех, что сейчас запущены (в процессе изготовления), к какому числу, сколько нужно доделать до конца, т.е. сдать на склад (и под какие это заказы). Опять же, можно сразу «провалиться», посмотреть, а где они там сейчас, в какой стадии вообще эти детали. Также видно и итого, хватает ли того количества, что уже в процессе изготовления, на все известные потребности сборки, или надо ещё запускать.
В-четвертых, выдачу деталей со склада будет проще намного оформлять в программе. Просто выбираешь, на что сейчас выдать нужно детали, и сразу готовый список у тебя на экране: какие детали выдавать, сколько штук, сколько у тебя на складе их числится (все/не все есть по списку, разными цветами), сколько забрали уже, если не за один раз забирают. И ничего руками вводить не нужно при выдаче деталей со склада. Если все детали выдаёшь по списку, то просто «Ок» нажимаешь, и всё, они выдаются. Если не все, то количество ставишь, сколько реально сейчас каких деталей выдаёшь, и «Ок» нажимаешь. Но сам список деталей, по крайней мере, уже есть составленный. Всё очень просто в «выдачей» со склада получается.
Итого: плюсов очевидно много, если так данные вести по «сборочным» заказам. А по трудоёмкости ведения, я бы не сказал, что в совокупности это сложнее, чем руками «отгрузку» оформлять без наличия предварительно созданных «сборочных заказов» и ЛЗК к ним.
4. Про общий порядок
Всё вышеперечисленное я бы не стал ни в коем случае делать сразу «в промышленных объемах». То есть вводить сразу тотально по всем деталям реальную информацию, по всем сборкам, что в работе. Я бы взял 2-3 для примера. Или если большие сборки, то вообще бы сделал специальный упрощенный пример. Взял бы реальные детали, но не 250 наименований, например, как в реальной сборке, а штук 5 или 10 завел бы. Как будто это все детали в данной сборке. И таких несколько «сборок». Смоделировал бы на этом десятке деталей весь описанный процесс от начала до конца. От запуска деталей до полной выдачи всей комплектации на сборку. Смоделировал бы разные варианты на этих деталях: сами полностью делаем, делаем часть операций сами, часть подрядчик, заказываем полностью готовые детали из материала подрядчика (на самом деле бывает теоретически ещё один вариант выше не упомянутый – заказываем у подрядчика полностью изготовление детали, но под это дело ему отправляем свой материал). Как отмечаем движение деталей, как передаем готовые на склад, как выдаем со склада на сборку. И вот когда на таком простом примере из 2-3 «сборок» и 10-20 «деталей» всё это промоделировал, всё понял, как оно что работает от начала и до конца процесса основного, вот после этого бы озаботился уже вопросом, как теперь сделать так же, но только по всем «заказам» и деталям.
