cancel
Showing results for 
Search instead for 
Did you mean: 

RUNALLOCATION in Default Logic - Question

former_member192555
Participant
0 Kudos

Hello,

I am trying to distribute from members 2015.INP to base level members of 2015.TOTAL which are 2015.01,2015.01...

While this script is working, I would like to limit the RUNALLOCATION program to start only when a .INP member is changed. In the following case the RUNALLOCATION is executed every time no matter I do changes only to the base level members of .TOTAL.

*SELECT (%YR%, "[YEAR]", S_TIME, "[ID] = %S_TIME_SET%")

*WHEN S_TIME

  *IS <> %YR%.INP

       *RUNALLOCATION

       *FACTOR = 1/12

       *DIM S_TIME WHAT = %YR%.INP ;WHERE = BAS(%YR%.TOTAL); Using = >>>; Total = %YR%.INP

       *ENDALLOCATION

*ENDWHEN

With *When and FOR/NEXT that could be done, but what about RUNALLOCATION?

Accepted Solutions (1)

Accepted Solutions (1)

former_member186338
Active Contributor
0 Kudos

Hi Emiliyan,

In general it's a not perfect idea to use RUNALLOCATION in default.lgf...

And you code with RUNALLOCATION inside WHEN/ENDWHEN is completely wrong! Only REC can be used inside WHEN/ENDWHEN.

The main issue is that multiple years YYYY.INP can be send simultaneously. You have to use something like:

*SELECT (%INPS%, "[ID]", S_TIME, "[ID] = %S_TIME_SET% AND [ISINP]=Y")

//ISINP - property set to Y for YYYY.INP members

*SELECT(%YRS%,"[YEAR]",S_TIME."[ID]=%INPS%")

*FOR %YR%=%YRS% //If no INP members - no loop at all!

*RUNALLOCATION

*FACTOR = 1/12

*DIM S_TIME WHAT = %YR%.INP ;WHERE = BAS(%YR%.TOTAL);

*ENDALLOCATION

*NEXT

Vadim

P.S. In general the calculations like this is better done in write back badi (look on disaggregation sample badi how-to)

P.P.S.

Instead of:

*SELECT (%INPS%, "[ID]", S_TIME, "[ID] = %S_TIME_SET% AND [ISINP]=Y")

//ISINP - property set to Y for YYYY.INP members

*SELECT(%YRS%,"[YEAR]",S_TIME."[ID]=%INPS%")

the following:

*SELECT (%YRS%, "[YEAR]", S_TIME, "[ID] = %S_TIME_SET% AND [ISINP]=Y")

//ISINP - property set to Y for YYYY.INP members

can be used (no issues with duplicated year)

former_member192555
Participant
0 Kudos

Hi Vadim,

Thanks for the tips.I forgot about multiple INP members , because it is one steap ahead. I was with only one INP member for the current test.

My issue was different and probably I was not clear enough.I want for example to enter 2015.INP and distribute the amount to the rest of the months with RUNALLOCATION, but when I do this I want to enter adjustments in the months in the same template.

                    2015.INP     2015.01     2015.02     2015.03     2015.04.....

Account          120               10              10          1015               10

With the current code when I enter in 2015.03 "15" the system will overwrite it from runallocation.

With the following code I am able to do it, but have issues on the next step where I don't want equal distribution, but seasonally adjusted based on coefficients in Assumptions model using LOOKUP.

*WHEN S_TIME

  *IS %YR%.INP

  *FOR %MONTH% = 01,02,03,04,05,06,07,08,09,10,11,12

  *REC(EXPRESSION = %VALUE%/12, S_TIME = %YR%.%MONTH%)

  *NEXT

*ENDWHEN

former_member192555
Participant
0 Kudos

btw. When we have allocations what is the best practice?

1. To have PERC/COEFIC account in the model itself where the calculations are executed

or

2. To have ASSUMPTIONS model where all the PERC/COEFIC for all models will be stored

or

3. It will be hybrid where the calculations are maintained in ASSUMPTIONS, but pushed to the models to related PERC/COEFIC accounts?

former_member186338
Active Contributor
0 Kudos

Please look on my code from previous answer - it will run RUNALLOCATION only if INP member is changed:

*SELECT (%YRS%, "[YEAR]", S_TIME, "[ID] = %S_TIME_SET% AND [ISINP]=Y")

ISINP - TIME dimension property set to Y for YYYY.INP members

For 2015.03 "15" - %YRS% will be empty (ISINP<>Y)! End FOR/NEXT will not run...

Vadim

former_member186338
Active Contributor
0 Kudos

In our system we use 3. But it depends...

former_member192555
Participant
0 Kudos

Yep, you were right!

former_member192555
Participant
0 Kudos

Thanks for sharing!

Answers (0)