21.10.2013, 15:33 | #1 |
Участник
|
Pазширение ReqCalc ( Ax 2009 )
Здраствуйте,
Столкнулься стакой проблемой. Нужные ещё 3 параметра мне в ReqCalc классе . Добавил я их : SalesId vtrmSales; ItemId vtrmItem; InventTransId vtrmSalesTrans; Есть три метода которые возвращает значения етих переменных . В классах ReqCalcExplodeSales и ReqCalcExplodeProd в методах newSalesIdPrompt() и newProdIdPrompt() добавил первоначальные значения . Все работает . Суть етого разширения - заполнить в таблице ReqPo новые поля - mainSalesId, mainSalesItemId и mainSalesTransId. Чтобы полегче потом разобраться , групировать и т.д. инфо по заказам продаж. Но вот зашёл менеджер в запланиров.заказах и решил сделать групировку нескольких производ.заказов . После диалога вылезает ошибка, что в классе в методе initParmDefault несовпадает значения . public void initParmDefault() { deleteCoverage = NoYes::Yes; } Етот метод вызван из метода newReqTrans : server public static ReqCalcExplode newReqTrans( ReqTrans _reqTrans, ReqPlanData _reqPlanData // May be NULl ) { ReqCalcExplode reqCalcExplode; ; reqCalcExplode = ReqCalcExplode::construct(_reqTrans.RefType); reqCalcExplode.getLast(); ПРОБЛЕМА Здесь ... ... return reqCalcExplode; } Как понимаю - ето связано с getLast и CurrentList ... Но как ето перебить - пока непонимаю ... Помогите ... С уважением , Римантас |
|
21.10.2013, 15:43 | #2 |
Участник
|
Сначала сделайте инкрементную компиляцию класса.
Попробуйте запустить. Если проблемы останутся, то в заголовке класса найдите строку вида X++: #DEFINE.CurrentVersion(10) Последний раз редактировалось Ace of Database; 21.10.2013 в 15:47. |
|
21.10.2013, 21:11 | #3 |
Участник
|
Цитата:
X++: #DEFINE.CurrentVersion(12) #LOCALMACRO.CurrentList reqPlanId, ... #ENDMACRO #DEFINE.CurrentThreadVersion(2) #LOCALMACRO.CurrentThreadList reqPlanId, processId, ... #ENDMACRO Последний раз редактировалось Rimantas; 21.10.2013 в 21:31. |
|
22.10.2013, 04:49 | #4 |
Участник
|
Цитата:
"Инкрементная компиляция" - как оно делаеться на Ах2009 ?
в нем подменю "Надстройки" пункт "Инкрементная компиляция" Увеличивать CurrentVersion или CurrentThreadVersion в том месте где изменяли соответсвующий список CurrentList или CurrentThreadVersion
__________________
Нет ничего сложного есть простое и неправильное |
|
22.10.2013, 08:43 | #5 |
Moderator
|
CurrentThreadVersion и currentThreadList используются только в многопоточной версии сводного планирования, запускаемой через периодические операции в модуле MRP и срабатывающей только если сводное запущено в пакетном режиме. Соответственно - на разертывание (explosion) они не влияют.
А что у вас за бизнес-задача кстати ? Мне просто кажется что сам выбранный подход изначально неверный и можно что-то поизящнее придумать... Последний раз редактировалось fed; 22.10.2013 в 08:53. |
|
22.10.2013, 11:01 | #6 |
Участник
|
Цитата:
Сообщение от fed
CurrentThreadVersion и currentThreadList используются только в многопоточной версии сводного планирования, запускаемой через периодические операции в модуле MRP и срабатывающей только если сводное запущено в пакетном режиме. Соответственно - на разертывание (explosion) они не влияют.
А что у вас за бизнес-задача кстати ? Мне просто кажется что сам выбранный подход изначально неверный и можно что-то поизящнее придумать... Есть задачя пополнить таблицу ProdTable 3 данными - номер заказа продажа , какой товар из SalesLine и InventTransId из SalesLine . InventTransId - будет спрятан . Я знаю , что такое есть InventRefId и InventRefTransId . Но оно есть только при первой строке , которое соотвествует SalesLine . Но вот - надо что все дочерные субпродкты в производстве от главного товара из SalesLine тоже имели связь с продажным заказом . Ходить по развертываниям - неудобно . А если ещё надо отфилтрировать строки продаж.заказа ? Производ.заказы делаеться из запланированных строк . Так я сперва заполняю таблицу ReqPO етими данными , потом после потвердения все ето переноситься в производ.заказ . Как описал раньше - ето работает . Проблема возникает в других ветках ReqCalc ... Если есть какой нибудь инной способ сделать такое - буду благодарнный за подсказку . |
|
22.10.2013, 11:36 | #7 |
Участник
|
Цитата:
Сообщение от Rimantas
Вплоне могу согласиться ... . Может быть и мой подход неверный ...
Есть задачя пополнить таблицу ProdTable 3 данными - номер заказа продажа , какой товар из SalesLine и InventTransId из SalesLine . InventTransId - будет спрятан . Я знаю , что такое есть InventRefId и InventRefTransId . Но оно есть только при первой строке , которое соотвествует SalesLine . Но вот - надо что все дочерные субпродкты в производстве от главного товара из SalesLine тоже имели связь с продажным заказом . Ходить по развертываниям - неудобно . А если ещё надо отфилтрировать строки продаж.заказа ? Производ.заказы делаеться из запланированных строк . Так я сперва заполняю таблицу ReqPO етими данными , потом после потвердения все ето переноситься в производ.заказ . Как описал раньше - ето работает . Проблема возникает в других ветках ReqCalc ... Если есть какой нибудь инной способ сделать такое - буду благодарнный за подсказку . |
|
22.10.2013, 11:47 | #8 |
Moderator
|
В общем - полное решение задачи излогать долго, но если у вас уровень производства только один и производственный заказ всегда покрывает заказ напрямую (без промежуточных переносов и тп), то можно найти запись относящуюся к текущему производственному заказу в reqTrans (смотрите relation между reqTrans и prodTable), потом найти первый покрытый reqTrans по salesLine (reqTransCov связывает покрывающую и покрываемую записи в reqTrans. ReqTransCov.ReceiptRecId смотрит на запись по производственному заказу, reqTransCov.IssueRecId смотрит на запись по заказу на продажу) Потом из найденной записи по заказу на продажу в reqTrans можно перейти на саму строку заказа (да вообще-то и в самой ReqTrans все что нужно уже есть).
Но все равно - с бизнесовой точки зрения - задача не правильная Производственный заказ может покрывать несколько заказв на продажу, между призводством и продажей может стоять перенос (и не один), могут существовать вложенные производства (в которые по этой логике тоже надо бы ссылку на заказ на продажу тянуть) и тп. Правильнее было бы использовать форму развертывания потребности из производственного заказа. Да - пользователям придется давить на лишние клавиши, но зато результат всегда будет правильный - во всех случаях, а не только в том примитивном, который я тут только что рассмотрел. |
|
|
За это сообщение автора поблагодарили: Rimantas (1). |
22.10.2013, 16:02 | #9 |
Участник
|
Цитата:
Сообщение от fed
В общем - полное решение задачи излогать долго, но если у вас уровень производства только один и производственный заказ всегда покрывает заказ напрямую (без промежуточных переносов и тп), то можно найти запись относящуюся к текущему производственному заказу в reqTrans (смотрите relation между reqTrans и prodTable), потом найти первый покрытый reqTrans по salesLine (reqTransCov связывает покрывающую и покрываемую записи в reqTrans. ReqTransCov.ReceiptRecId смотрит на запись по производственному заказу, reqTransCov.IssueRecId смотрит на запись по заказу на продажу) Потом из найденной записи по заказу на продажу в reqTrans можно перейти на саму строку заказа (да вообще-то и в самой ReqTrans все что нужно уже есть).
Но все равно - с бизнесовой точки зрения - задача не правильная Производственный заказ может покрывать несколько заказв на продажу, между призводством и продажей может стоять перенос (и не один), могут существовать вложенные производства (в которые по этой логике тоже надо бы ссылку на заказ на продажу тянуть) и тп. Правильнее было бы использовать форму развертывания потребности из производственного заказа. Да - пользователям придется давить на лишние клавиши, но зато результат всегда будет правильный - во всех случаях, а не только в том примитивном, который я тут только что рассмотрел. |
|
Теги |
сводное планирование |
|
|