Script validation error when using *DIM_NONAGGR in *RUNALLOCATION

[former_member353620]

I have a *RUNALLOCATION code within a set of two *FOR/*NEXT loops that works just fine:

*FOR %EACH_PARENT% = %COSTCENTER_SET%

*FOR %EACH_ACCT% = %CAPOPS_ACCT_SET%

  *RUNALLOCATION

  *ACCELERATOR = OFF

  *FACTOR = USING/TOTAL

  *DIM CAPOPS_ACCT WHAT = %EACH_ACCT%; WHERE = <<<; USING = BAS(TOTAL_REV); TOTAL = <<<

  *DIM COSTCENTER WHAT = %EACH_PARENT%.INP; WHERE = BAS(%EACH_PARENT%); USING = <<<; TOTAL = <<<

  *DIM RPTCURRENCY WHAT = USD; WHERE = <<<; USING = BOE; TOTAL = <<<

  *DIM AUDITTRAIL WHAT = INPUT_BASE; WHERE = <<<; USING = ARIES_CALC; TOTAL = <<<

  *DIM PROGRM WHAT = NO_PROGRAM; WHERE = BAS(PROGRAMS_PLUS_SALES); USING = <<<; TOTAL = <<<

  *DIM COMPANY WHAT = 100; WHERE = BAS(G43100); USING = <<<; TOTAL = <<<

  *DIM TIME WHAT = 2016.INP; WHERE = %TIME_SET%; USING = <<<; TOTAL = <<<

  *ENDALLOCATION

*NEXT

*NEXT

I learned of the *DIM_NONAGGR keyword and was hoping to take advantage of it for the CAPOPS_ACCT dimension.  However, when I replace the code above with this:

*FOR %EACH_PARENT% = %COSTCENTER_SET%

*RUNALLOCATION

*ACCELERATOR = OFF

*FACTOR = USING/TOTAL

*DIM_NONAGGR CAPOPS_ACCT WHAT = %CAPOPS_ACCT_SET%; WHERE = <<<; USING = BAS(TOTAL_REV); TOTAL = <<<

*DIM COSTCENTER WHAT = %EACH_PARENT%.INP; WHERE = BAS(%EACH_PARENT%); USING = <<<; TOTAL = <<<

*DIM RPTCURRENCY WHAT = USD; WHERE = <<<; USING = BOE; TOTAL = <<<

*DIM AUDITTRAIL WHAT = INPUT_BASE; WHERE = <<<; USING = ARIES_CALC; TOTAL = <<<

*DIM PROGRM WHAT = NO_PROGRAM; WHERE = BAS(PROGRAMS_PLUS_SALES); USING = <<<; TOTAL = <<<

*DIM COMPANY WHAT = 100; WHERE = BAS(G43100); USING = <<<; TOTAL = <<<

*DIM TIME WHAT = 2016.INP; WHERE = %TIME_SET%; USING = <<<; TOTAL = <<<

*ENDALLOCATION

*NEXT

... and attempt to validate the Script Logic, I receive the error message "For 'NONAGGR' Dimension CAPOPS_ACCT, member count of WHERE,USING must be same".  I was aware of the potentially false error message about the member count of WHAT,WHERE, and have implemented the SAP Note (2003100) to fix that.  However, through my searching, I can find nothing that helps with this error of member count of WHERE,USING.  Is it just not possible to have USING defined like this with *DIM_NONAGGR?

The basic scenario at play here is to allocate planned Opex (which is on special dummy ".INP" Cost Center members in various Opex accounts %CAPOPS_ACCT_SET%) to base level Cost Centers under the parent with the same name as the ".INP" (but without the ".INP" suffix), based on the amount of Production Volume (BOE) already sitting on those base level members.  Production Volume accounts are the ones in BAS(TOTAL_REV).

I'm OK with going back to *FOR/*NEXT because it works, just thought I could perhaps speed up the run-time.  BTW, having *ACCELERATOR=OFF vastly decreased the run-time, in part because I think it spends too much time forming the necessary HANA DB procedures with each pass of the *FOR/*NEXT loop.

System version is BPC NW 10.0, CPMBPC 800 SP13, HANABPC 800 SP7.

Many thanks,

- John

[former_member186338 · Accepted solution]

Hi John,

Can you explain the original calculation logic of this line:

*DIM CAPOPS_ACCT WHAT = %EACH_ACCT%; WHERE = <<<; USING = BAS(TOTAL_REV); TOTAL = <<<

Vadim

[former_member353620 · Accepted solution]

Howdy Vadim,

The Account dimension in this model is called CAPOPS_ACCT.  It consists of a series of Opex accounts as well as a series of Oil & Gas Production/Revenue Accounts (along with others not relevant to his scenario/script).  The idea is that the Region managers budget Opex at high levels in the Cost Center hierarchy, and we want to allocate this Opex down to the individual wells lower in the hierarchy based on the amount of planned Production/Revenue they have.

For example, one such Opex account is Treating Expense.  The user may budget $1,000 of Treating Expense to an overall Area.  Underneath this area are three wells that each have 10, 20, and 30 BOE (Barrel of Oil Equivalent) of Prod/Rev planned to them.  After allocation, each well should get $166.67, $333.33, and $500 of Treating expense allocated to them respectively.

The list of Opex accounts are in the variable %CAPOPS_ACCT_SET% passed via the Data Manager prompt.  The *FOR/*NEXT loop processes each account individually.  The list of Prod/Rev accounts that should be used as a basis in total for the allocation are contained under the TOTAL_REV node of the CAPOPS_ACCT hierarchy.  Hence the USING = BAS(TOTAL_REV) specification.

I was hoping to use *DIM_NONAGGR to keep from having to loop through each Opex account individually.

Hope this clarifies things.

- John

[former_member186338 · Accepted solution]

Hi John,

Can you play with you script in line with note http://service.sap.com/sap/support/notes/1991081

Use simple case...

Instead of USING = BAS(TOTAL_REV)

try USING = SOME_BASE_MEMBER

Vadim

[former_member353620 · Accepted solution]

Thank you, Vadim.

Though I wasn't experiencing the case-sensitivity issue highlighted by the note to which you referred, I decided to include a "pre-aggregation" step to summarize all the Planned Production to a single base member as you suggest.  Under the TOTAL_REV node, there could be a variety of accounts to which Production has been planned.  I aggregate all these to a single PROD_ALLOC_BASIS account and use this account in the USING clause of the Allocation.

This not only worked and allowed the use of *DIM_NONAGGR, but it also reduced the run-time of this allocation by over 83%!  This includes the step to pre-aggregate as well as a follow-up step to clear the pre-aggregation (clear the PROD_ALLOC_BASIS account)!

- John

[former_member186338 · Accepted solution]

I've suspected the thing like this

Pre-aggregation can be also done with RUNALLOCATION.

Vadim