An allocation is defined as the process of sending amounts and/or quantities from one (or more) sender object(s) to one or more receiver objects. In SAP Business Planning and Consolidation a business calculation engine known as script logic can be used to systematically define and run allocation functions.
In the SAP help documentation for BPC 7.0 NW, it offers the following example of an allocation.
*****************************************************************
*RUNALLOCATION
*FACTOR USING/TOTAL
*DIM ACCOUNT WHAT= LeaseCost; WHERE=<<<; USING=SquareFootage; TOTAL= <<<<br />*DIM ENTITY WHAT= GLOBALOPS; WHERE=>>>; USING=>>>; TOTAL= BAS(ALL_ENTITIES)
*ENDALLOCATION
*****************************************************************
Translated to English, this example intends to allocate lease costs from an entity called GLOBALOPS to all base entities using a driver called SquareFootage which is defined using the account dimension.
The example above is rather straight-forward to understand. That is why I became interested to look at this function closer after reading about RUNALLOCATION in SAP Note 1413180 which was released this month on December 8, 2009. In the note it says that RUNALLOCATION may result in different calculations between the NetWeaver and Microsoft versions of BPC. The note goes on to provide the following example.
*****************************************************************
Assume that ABC is a parent node, and it has three children (base member): A, B and C.
*RUNALLOCATION
*FACTOR = USING
*DIM P_ACCT WHAT = BAS(ABC); WHERE = BAS(ABC); USING = E
*ENDALLOCATION
This will be resolved in SAP BusinessObjects Planning and Consolidation, version for NetWeaver as:
(A+B+C) * E -> A
(A+B+C) * E -> B
(A+B+C) * E -> C
As RUNALLOCATION in BPC NW is designed only for disaggregation, the engine assumes that you want to add all source values and use value E to disaggregate. As the target (WHERE) is also same as source (WHAT), you will get same value in all target members.
However, in BPC MS, this allocation will be resolved as:
A * E -> A
B * E -> B
C * E -> C
This is a use case for Driver Based Budgeting. BPC MS RUNALLOCATION function is designed to cover Driver based budgeting as well.
*****************************************************************
The math is simple enough to follow, but if you are like me, it helpful to understand what is going on by seeing a worked example of the above. So that is what I set out to do in this weblog.
Let's begin with a report of BPC data in the Planning cube. This starting place is valid for either BPC for NetWeaver or BPC for Microsoft.
The current view related to this report is as follows.
The Entity dimension hierarchy is as follows. We will focus our attention on entities C9000 and C2000.
The account dimension hierarchy is as follows. We'll focus our attention on accounts CE0004200 - CE0004230 and CE000800010.
Our goal is to demonstrate an allocation of the three Advertising Costs accounts from entity C2000 to entity C9000 using the Sales - Domestic account as the factor.
The script logic code is as follows.
*XDIM_MEMBERSET Category = PLAN
*XDIM_MEMBERSET Entity = C2000,C9000
*XDIM_MEMBERSET P_ACCT = BAS(CE0004200)
*XDIM_MEMBERSET P_Activity = NONE
*XDIM_MEMBERSET P_DataSrc = MANUAL
*XDIM_MEMBERSET RptCurrency = LC
*XDIM_MEMBERSET TIME = 2009.OCT
*RUNALLOCATION
*FACTOR = USING*-1
*DIM P_ACCT WHAT= BAS(CE0004200); WHERE=BAS(CE0004200); USING=CE0800010
*DIM ENTITY WHAT=C2000; WHERE=C9000; USING=C9000;
*ENDALLOCATION
Upon execution of a Data Manager package for this allocation and a refresh of the report we get the following outcome in BPC for NW.
Thus we can see the BPC NW system did exactly as explained in SAP Note 1413180. Namely it accumulated the "what" values within account group CE0004200 which were equal to 10,000 LC and multiplied this by the 50,000 LC value in "using" account CE0800010 and wrote the 500,000 LC result to each of the three accounts in the "where" destination.
Looking at the result from BPC for MS we also get the answer predicted in SAP Note 1413180. Each "what" account within the group gets multiplied by the using factor individually so that Advertising Expenses of 1,750 LC multiplied by 50,000 LC in Sales equals 87,500 LC and similarly with the other two advertising related accounts.
Given this outcome in BPC MS, I can follow the explanation that the RUNALLOCATION function can be used for driver-based budgeting. Consider if this example had been headcounts posted as accounts to various cost centers and a rate/unit was posted globally. We would expect the system to multiply the values as shown above.
But I can't think of an example where a planner would seek to cause the system to behave like it does with BPC NW. Nor do I really relate the mathematics to a what I would call a "disaggregation scenario". But given this is the way the system currently behaves in BPC NW, it suggests to me that for most planning scenarios you would never want to select multiple members in the "what" and "where" parameters. Otherwise you may multiply your data inadvertently. A simple work around of course is to separate multiple members of the "what" and "where" into separate RUNALLOCATION snippets.
2 Comments