Skip to Content

RUNALLOCATION – a worked example to accompany SAP Note 1413180

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.




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.

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.

Current View

The Entity dimension hierarchy is as follows.  We will focus our attention on entities C9000 and C2000.

Entity Dimension

The account dimension hierarchy is as follows.  We’ll focus our attention on accounts CE0004200 – CE0004230 and CE000800010.

Account Hierarchy

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 Entity = C2000,C9000

*DIM P_ACCT WHAT= BAS(CE0004200); WHERE=BAS(CE0004200); USING=CE0800010

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.

NW Report After Allocation

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.

MS Report after Allocation

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.

You must be Logged on to comment or reply to a post.
  • Hi,

    A better example would be to have the ratio in the factor. In the above example, the factor should be advertising and not sales. with that see if the results would be same across nw and ms


    • Hi Muthu and thanks for the reply.  I agree that a ratio in the factor is more likely scenario; however I wanted to make an example which follows the SAP note.  The point of the note [and this blog] is that if more than one member is in the sender (what) and the target (where), BPC behaves differently in NW when compared to MS.  Had the example been only one member in the sender (what) with multiple receivers (where) and factors (using), which is a more common scenario, then the resulting allocation would be handled the same in NW and MS.