Аналоги в обеспеченности

Сейчас только если нажать на ней кнопку "замена".
Были уже определённые пожелания на эту тему от других заказчиков, мы их собираем пока что.Да.
Показывать будет, что нет "оригинала". Это упрощённая функция. Она сразу как таковая заявлялась. Сразу оговаривалось, что она не подходит для всех случаев жизни. Иногда годится. Но далеко не всегда. В простых случаях только.

Ну тут то как раз всё нормально. Существующая технология работы с аналогами такие вещи нормально отрабатывает.
У неё есть только ограничение, что она умеет работать с заменами типа "один на один". Замены типа "один на много" или "много на много" она не понимает.
А если деталь и деталь-аналог, и в каких то изделиях допускается замена, в каких-то нет, то тут то как раз всё нормально.

Насчёт обеспеченности, пожалуй, соглашусь. Но формулировка "необходимо" не корректна. Да было бы лучше видеть. Но не сказать, что без это вообще никак совершенно невозможно...
А вот в "расчёте потребности" не вижу смысла. Зачем?

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

Почему это надо отдельно делать: потому что там начинается ситуация из серии "потянули за ниточку, вытащили мамонта".
Один список "что нужно" и "остатки" - это крайне мало вообще-то. Ну хорошо, остатки есть. А брать то можно их или нельзя? А может, там ещё 15 заказов, на которые точно то же самое нужно, и к обеду не останется уже ничего из этих остатков? А может и нет. А может, остатков нет, но вот-вот они появятся? Потому что уже заказали это или оно в производстве уже. А может можно заменить? А то, на что собираемся менять, оно само часом не окажется в итоге "в дефиците" с учётом всех предыдущих моментов?
Я уже не говорю про прочие нюансы типа "жесткого резервирования" под конкретный заказ, давальческое сырьё, поддержание "неснижаемых остатков" и т.п.

Это всё будем навешивать на "расчёт потребности", задача которого просто общий список материалов собрать по составу/техпроцессам?
А зачем?

Поэтому сделано так. В режиме "расчёт потребности" получаем список. Если нужно сохраняем его в виде документа (ЛЗК). Дальше уже по ситуации. В простом случае - сразу и идём с эти списком получать по нему. В более сложной - сначала сверяем, а что есть, чего нет, по этому списку. И начинаем разбираться, что делать с тем, чего нет. Заказать, поменять на что-то в данном конкретном случае (не меняя в техпроцессе, а только в этот конкретный раз) и т.п.
Ещё одним плюсом такого подхода является то, что не обязательно делать такой список строго через "расчёт потребности". То есть сначала писать спецификации, техпроцессы и т.п., чисто для того, чтобы потом список материалов/комплектации получить, что потребуется. Бывают варианты и наоборот. Не нужны пока никакие техпроцессы, состав и т.п. Это потом. А список примерный сразу есть. В таком случае можно в VOGBIT просто вручную запрос на склад (требование) сделать без всякого "расчёта потребности" и, соответственно, исходных данных для него.

Теперь по вопросу "что делать".
Я бы примерно так делал, наверное:
После запуска нового "заказа" делаем на изделие "расчёт потребности" и сохраняем из него ЛЗК. Печатать её в данные момент совершенно не обязательно.
Потом смотрим по ней обеспеченность. Хоть по этому одному отдельно взятому изделию, хоть в контексте других заказов. Как нужно.
Если есть дефицит, разбираемся, что с ним делать.
Конкретно в вашем примере:
Ну вот эта одна деталь и вывалится в дефицит в таком случае. Остальные то конструктор добавил в заказ.
Одна или несколько позиций вывалятся, как "дефицит". По ним посмотреть, есть замена или нет. В том же самом окне это делается, где они "в дефицит вывалились".
Есть возможность - заменяем. Функция "замены" для того и нужна. Она сама показывает на что можно в принципе это поменять, есть или нет и в дефиците или нет то, на что можно поменять. Для чего оно в оригинале нужно (для какого изделия). Допустимо ли в данном случае применение конкретного аналога. И сама в случае выбора аналога и заменяет что нужно в ЛЗК.
Добиваемся чтобы дефицита не было (либо меняем, либо заказываем, чего не хватает).
После этого можно уже и распечатать ЛЗК.
При этом:
- в "расчёт потребности" уже давно не ходим.
- если что-то поменяли на аналоги, то ЛЗК уже получится с учётом этого.

Что тут и где нужно выписывать ну бумажку и где-то запоминать отдельно, и зачем, я пока не вижу.

И кстати, можно и вообще не печатать бумажную ЛЗК, в принципе, при хорошо организованной работе.
Сборщикам она, в общем-то не нужна. У них спецификации есть и чертежи. Да и они и так, обычно, знают, что нужно.
Складу, по большому счёту, бумага эта (ЛЗК) тоже, в общем, не нужна. Им достаточно от неё только номер. Они всё равно отмечать что-либо будут по списку у себя на экране. А для этого им нужно знать только номер документа из всей этой бумаги (ЛЗК), его достаточно, чтобы нужный список у них на экране появился. Или просто знать на какой заказ выдавать, если у них доступ к списку заказов в программе есть.
Бумажная ЛЗК удобна на переходном этапе. Чтобы отладить сам процесс. Что при запуске в производство формируется некий список, что нужно получить на складе. Потом по этому списку отпускается со склада.
А когда процесс отлажен, то становится понятно, что в бумажном виде списки эти, в общем, и не нужны особо.
Мы лет 15 назад, когда внедряли со своей предыдущей программой подобную систему на автобусном заводе, там сначала печатали бумажные ЛЗК. А потом, через год-полтора реальной работы, люди сами сказали: "а зачем мы эти портянки печатаем? давайте печатать только квиточек с заказом, изделием и номером электронной ЛЗК, этого же достаточно..."

Такой вопрос записан. Вы уже не первые, кто его придумал