|
11.05.2011, 09:47 | #1 |
Участник
|
Замена комплектующих по условию
После выполнения определенного количества операций получаем заготовку, для которой используется шайба. Размер шайбы зависит от величины зазора после выполненных операций. Для каждого зазора в примечании спецификации указывается размер шайбы. Как реализовать данную ситуацию? Необходимо ли здесь указывать все варианты шайб в спецификации?
|
|
11.05.2011, 10:15 | #2 |
Участник
|
Вы хотите спросить как отразить факт такой ситуации? или как предусмотреть возможность такой ситуации при планировании комплектующих?
Я знаю идинственный способ планирования подобного рода неопределённостей - это использование страхового запаса. |
|
11.05.2011, 10:24 | #3 |
Участник
|
Как отразить?
|
|
11.05.2011, 10:27 | #4 |
северный Будда
|
Как вариант:
Да и вообще ном. аналитики - редко используемый функционал, могут и всякие неожиданности выползти
__________________
С уважением, Вячеслав |
|
11.05.2011, 10:43 | #5 |
Участник
|
Ну раз такая экзотика пошла, то тогда расскажу какая мысль пришла в голову мне.
Можно в спецификацию включить дополнительный фиктивный узел "шайба подходящая". И в этом узле насоздавать кучу версий спецификации под каждую шайбу. Тогда для потребления необходимой в данный конкретной ситуации шайбы нужно будет создать ПЗ с сооветствующей версией спецификации на "производство" "шайбы подходящей" и уже её потребить в основной ПЗ. |
|
17.05.2011, 15:21 | #6 |
Возьми свет!!!
|
Цитата:
Сообщение от bum10
После выполнения определенного количества операций получаем заготовку, для которой используется шайба. Размер шайбы зависит от величины зазора после выполненных операций. Для каждого зазора в примечании спецификации указывается размер шайбы. Как реализовать данную ситуацию? Необходимо ли здесь указывать все варианты шайб в спецификации?
И все переменные у меня представлены так ширина - поле ширина из ProdTable, высота - высота из ProdTable, количествокомпоненты2 - количество из ProdBOMа второго, ну кроме того я еще сделал приоритет т.е. по производственному заказу бегают мои запросы(у ProdTable в запросе подставляется критерии ProdId = текущий пр.заказ) сначала те которые с более высоким приоритетом, что то что подпадает под запрос - расчитывается по формуле, и более не расчитывается если даже подпадает под запрос с более низким приоритетом. А для xppCompiler у меня строиться функция xppCompiler.compile("real calcQty(real _width,real _height,real _controlLength) { return "+Моя формула с заменными строчками + "};" и я ее вызываю xppCompiler.execute(ширина из ProdTable,высота из ProdTable,длинауправления). Ну и соответственно то у чего количество 0 из производственного заказа удаляется. Может вам поможет :-)
__________________
Axapta 3.0 sp 5 Oracle Я могу взорвать вам мозг!!! Последний раз редактировалось Murlin; 17.05.2011 в 16:48. |
|
17.05.2011, 16:06 | #7 |
Member
|
То, что вы описали, реализовано в стандартной фунциональности в модуле Конфигуратор продукции. Там сделано нечто вроде макропрограммирования в MS Access с возможностью использования кода Х++ где угодно.
Но вариант S.Kuskov не смотря на потребность в полуручном режиме управления тоже может быть приемлемым. Опасение pitersky насчет сводного планирования для дефолтовой версии спецификации с шайбой нулевого размера нужно решать переводом этой виртуальной шайбы на ручное планирование покрытия. Соответственно закупки под нее не создадутся. А после выбора реальной версии спецификации уже создадутся закупки реальные. Действительно поскольку версию могут выбрать в последний момент потребуется держать страховой запас.
__________________
С уважением, glibs® |
|
|
За это сообщение автора поблагодарили: Murlin (1). |
17.05.2011, 16:09 | #8 |
Возьми свет!!!
|
Цитата:
Сообщение от glibs
То, что вы описали, реализовано в стандартной фунциональности в модуле Конфигуратор продукции. Там сделано нечто вроде макропрограммирования в MS Access с возможностью использования кода Х++ где угодно.
Но вариант S.Kuskov не смотря на потребность в полуручном режиме управления тоже может быть приемлемым. Опасение pitersky насчет сводного планирования для дефолтовой версии спецификации с шайбой нулевого размера нужно решать переводом этой виртуальной шайбы на ручное планирование покрытия. Соответственно закупки под нее не создадутся. А после выбора реальной версии спецификации уже создадутся закупки реальные. Действительно поскольку версию могут выбрать в последний момент потребуется держать страховой запас.
__________________
Axapta 3.0 sp 5 Oracle Я могу взорвать вам мозг!!! Последний раз редактировалось Murlin; 17.05.2011 в 16:29. |
|
17.05.2011, 17:22 | #9 |
Member
|
Формулы простой инструмент. Для сложной продукции — отдельный модуль. С т.з. системы тут все ОК.
__________________
С уважением, glibs® |
|
17.05.2011, 17:39 | #10 |
Возьми свет!!!
|
Цитата:
Вот таким образом я заменил целый модуль
__________________
Axapta 3.0 sp 5 Oracle Я могу взорвать вам мозг!!! |
|
|
|