Pазширение ReqCalc ( Ax 2009 )

[Rimantas]

Здраствуйте,

Столкнулься стакой проблемой. Нужные ещё 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 ... Но как ето перебить - пока непонимаю ... Помогите ...

С уважением , Римантас

[Ace of Database]

Сначала сделайте инкрементную компиляцию класса.
Попробуйте запустить.
Если проблемы останутся, то в заголовке класса найдите строку вида

#DEFINE.CurrentVersion(10)

Увеличьте значение текущей версии на 1.

[Rimantas]

Цитата:

Сообщение от Ace of Database

Сначала сделайте инкрементную компиляцию класса.
Попробуйте запустить.
Если проблемы останутся, то в заголовке класса найдите строку вида

#DEFINE.CurrentVersion(10)

Увеличьте значение текущей версии на 1.

Непомогло с номерами версии ... . Выпробывал всякие варянты ... Добавлял и к CurrentList ... Ни как неподдаеться . "Инкрементная компиляция" - как оно делаеться на Ах2009 ? Я вижу только команду "Компилировать" ... еще вопрос - а именно в каком месте повысить версию ? В ReqCalc есть два места :

    #DEFINE.CurrentVersion(12)
    #LOCALMACRO.CurrentList
        reqPlanId,
   ...
    #ENDMACRO

    #DEFINE.CurrentThreadVersion(2)
    #LOCALMACRO.CurrentThreadList
        reqPlanId,
        processId,
   ...
    #ENDMACRO

В ReqCalcExplode повысить также ?

[jasper]

Цитата:

"Инкрементная компиляция" - как оно делаеться на Ах2009 ?

на классе вызоваете контекстное меню
в нем подменю "Надстройки" пункт "Инкрементная компиляция"

Увеличивать CurrentVersion или CurrentThreadVersion
в том месте где изменяли соответсвующий список
CurrentList или CurrentThreadVersion

[fed]

CurrentThreadVersion и currentThreadList используются только в многопоточной версии сводного планирования, запускаемой через периодические операции в модуле MRP и срабатывающей только если сводное запущено в пакетном режиме. Соответственно - на разертывание (explosion) они не влияют.
А что у вас за бизнес-задача кстати ? Мне просто кажется что сам выбранный подход изначально неверный и можно что-то поизящнее придумать...

[Rimantas]

Цитата:

Сообщение от fed

CurrentThreadVersion и currentThreadList используются только в многопоточной версии сводного планирования, запускаемой через периодические операции в модуле MRP и срабатывающей только если сводное запущено в пакетном режиме. Соответственно - на разертывание (explosion) они не влияют.
А что у вас за бизнес-задача кстати ? Мне просто кажется что сам выбранный подход изначально неверный и можно что-то поизящнее придумать...

Вплоне могу согласиться ... . Может быть и мой подход неверный ...

Есть задачя пополнить таблицу ProdTable 3 данными - номер заказа продажа , какой товар из SalesLine и InventTransId из SalesLine . InventTransId - будет спрятан . Я знаю , что такое есть InventRefId и InventRefTransId . Но оно есть только при первой строке , которое соотвествует SalesLine . Но вот - надо что все дочерные субпродкты в производстве от главного товара из SalesLine тоже имели связь с продажным заказом . Ходить по развертываниям - неудобно . А если ещё надо отфилтрировать строки продаж.заказа ? Производ.заказы делаеться из запланированных строк . Так я сперва заполняю таблицу ReqPO етими данными , потом после потвердения все ето переноситься в производ.заказ . Как описал раньше - ето работает . Проблема возникает в других ветках ReqCalc ...

Если есть какой нибудь инной способ сделать такое - буду благодарнный за подсказку .

[Rimantas]

Цитата:

Сообщение от Rimantas

Вплоне могу согласиться ... . Может быть и мой подход неверный ...

Есть задачя пополнить таблицу ProdTable 3 данными - номер заказа продажа , какой товар из SalesLine и InventTransId из SalesLine . InventTransId - будет спрятан . Я знаю , что такое есть InventRefId и InventRefTransId . Но оно есть только при первой строке , которое соотвествует SalesLine . Но вот - надо что все дочерные субпродкты в производстве от главного товара из SalesLine тоже имели связь с продажным заказом . Ходить по развертываниям - неудобно . А если ещё надо отфилтрировать строки продаж.заказа ? Производ.заказы делаеться из запланированных строк . Так я сперва заполняю таблицу ReqPO етими данными , потом после потвердения все ето переноситься в производ.заказ . Как описал раньше - ето работает . Проблема возникает в других ветках ReqCalc ...

Если есть какой нибудь инной способ сделать такое - буду благодарнный за подсказку .

Кажеться такое местечко я нашёл ... :-) . Класс ProdTableType метод insert() . Достаточно заполнять мои поля из pordTableparent или из salesLine ... А всегда новая запись будет первыми из salesLine ? Как то ненадежно мне кажетьса ...

[fed]

В общем - полное решение задачи излогать долго, но если у вас уровень производства только один и производственный заказ всегда покрывает заказ напрямую (без промежуточных переносов и тп), то можно найти запись относящуюся к текущему производственному заказу в reqTrans (смотрите relation между reqTrans и prodTable), потом найти первый покрытый reqTrans по salesLine (reqTransCov связывает покрывающую и покрываемую записи в reqTrans. ReqTransCov.ReceiptRecId смотрит на запись по производственному заказу, reqTransCov.IssueRecId смотрит на запись по заказу на продажу) Потом из найденной записи по заказу на продажу в reqTrans можно перейти на саму строку заказа (да вообще-то и в самой ReqTrans все что нужно уже есть).

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

[Rimantas]

Цитата:

Сообщение от fed

В общем - полное решение задачи излогать долго, но если у вас уровень производства только один и производственный заказ всегда покрывает заказ напрямую (без промежуточных переносов и тп), то можно найти запись относящуюся к текущему производственному заказу в reqTrans (смотрите relation между reqTrans и prodTable), потом найти первый покрытый reqTrans по salesLine (reqTransCov связывает покрывающую и покрываемую записи в reqTrans. ReqTransCov.ReceiptRecId смотрит на запись по производственному заказу, reqTransCov.IssueRecId смотрит на запись по заказу на продажу) Потом из найденной записи по заказу на продажу в reqTrans можно перейти на саму строку заказа (да вообще-то и в самой ReqTrans все что нужно уже есть).

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

Спасибо вам Фед за ето обьяснение - оно поможет мне . Думаю что некий вид оттыскивания и буду пробывать ... А так вы правы - с производ.заказами бывает всякого . 99 % у нас там все на том же самом уровне , а остающимся 1 % будем работать ещё ...