In this blog, I would like to show how to leverage and implement iterative feature of allocation function in SAP Profitability and Performance Management (PaPM) as highly flexible and easily adaptable solution to fit specific business needs. Using only one PaPM Allocation function through multiple allocation iterations, it is possible to solve common allocation business problems.
How to achieve this high calculation model efficiency and simplicity?
1. Prepare sender and receiver data for allocation calculation
2. Simple set up of PaPM allocation function.
For better understanding of steps, I am going to explain it through an example of intercompany transfer allocation of direct tax among company hierarchy. The business problem is to transfer taxable income from the subsidiary in a tax group to the parent of the tax group, so that group’s tax obligations are paid by head entity of the group. Distribution of individual subsidiary’s taxable income to the parent company and unloading of transferred amount are done simultaneously.
In this particular example, we can assume tax group company’s structure from the picture (left) and group company transfer rules (right).
How to achieve this high calculation model efficiency and simplicity?
1. Prepare sender and receiver data for allocation calculation
2. Simple set up of PaPM allocation function.
For better understanding of steps, I am going to explain it through an example of intercompany transfer allocation of direct tax among company hierarchy. The business problem is to transfer taxable income from the subsidiary in a tax group to the parent of the tax group, so that group’s tax obligations are paid by head entity of the group. Distribution of individual subsidiary’s taxable income to the parent company and unloading of transferred amount are done simultaneously.
In this particular example, we can assume tax group company’s structure from the picture (left) and group company transfer rules (right).
In an iteration, every company does transfer to its parent company and decreases the taxable income to zero. The same calculation is repeated until all tax incomes are distributed to the head entity of the tax group.
As you can notice, in this case there can be only one parent company for each subsidiary, but it is possible to allocate sender amount to more than one receiver based on data in the receiver table.
Allocation function here only performs distribution of taxable income amongst company hierarchy according to distribution bases defined in the receiver table. This means that on the sender side we need to provide determined taxable income (in this example for one fiscal year) on a stand-alone basis. On the other hand, in the receiver data partner company and distribution bases must be defined for each company and fiscal year. Time based fields like fiscal year and period could be used as allocation distribution keys. In that way dynamic changes of company group structure would automatically been taken in calculation.
Technical Solution – Simplicity, No additional formula to manage
When we process an allocation cycles iteratively in PaPM, they are processed dependent on each other, which means the result of one iteration is then used by the next iteration and processed further. In this particular example, the partner company that is used as receiver in one iteration is going to be used again in the next iteration as sender company. So, the intercompany transfer looks like this through cycles according to group company structure and allocation percentages (please refer to pictures above for details):
Therefore, it is necessary to perform at least 3 allocation iterations so the taxable income from child company (for example Company Code 1000) can be processed further till head of company (Company Code 5000).
In Advance tab, iterations number can be configured as:
1. fixed – as number in Cycle Maximum Value, this assures that process is not going beyond specified number, e.g. for performance reasons we don’t want more than 10 iterations; but setting this number as 0 means iteration process would continue till the sender data set is empty/there is something to be allocated. In this example, we can establish that 3 is maximum iteration number.
2. dynamic – assigning Environment Check in Early Exit Check the iteration will be stopped early, if the check is successful. This is helpful if we want to apply a threshold, like if allocation amount get less than 10 USD, the iteration cycle stops.
Allocation function continues to process the iterations until one of those two conditions are valid. In Iteration Counter as optional setting, we can assign field (Field Class must be defined as: Parameter) that will show in which iteration cycle, the record is produced. By using Result Aggregation option, application will aggregate results produced in each iteration, which can be useful in reducing memory consumption.
In result data set of every iteration it is possible to generate additional records as balance to allocated values in that cycle leveraging offset mapping functionality. How to do that?
1. Allocation type must be set either as:
a) Allocation with Offset Records – created records looks like the sender data, but sender’s key figures have the opposite sign.
b) Allocation with detailed Offset Records – provides more traceability since all sender and receiver entity dimensions are kept in results.
2. In Offset mapping under the Advanced Tab, define characteristics/settings of generated offset records during the allocation process which are added to result data set. Here can be specified two types of offset records:
a) Offset – define field mapping,
b) Debit/Credit – define field with debit/credit information with option to set debit/credit sign.
The offset mapping is also used while deriving sender data from the result of previous allocation iteration. E.g. Receiver company becomes the sender company.
Solution – Results and Conclusion
So that’s it from technical perspective, let’s see it from data’s.
Sender Input Data:
Receiver Input Data:
Following above function set up, this is allocated result data set:
Observing ‘Iteration Parameter’ column, we can notice that number of iterations is 3 as configured and investigate result data set of every iteration. For example in the first iteration, Company Code 1000 transfers current taxable income to partner Company Code 3000 according to distribution base from receiver table (100%) and as a balance one offset record is generated. In the offset record: Company Code and Parent Company switched values, ‘R’ as credit sign and Transferred Amount has opposite sign. In the next iteration, only companies that received taxable income in the previous iteration perform transfer again to their partner companies. Receiver is always same in every iteration, but sender is only in the first one. In all others, it changes depending on the previous cycle allocation results.
So, what are new taxable income for Company Code 4000 and Company Code 5000 as only tax payers?
Company 4000 = 551.115.200 – 275.557.600 + 1.960.800 – 980.400 – 31.259.000 + 15.629.500 = 260.908.500
Company 5000 = (275.557.600 + 980.400 – 15.629.500) – 58.166.700 = 260.908.500 – 58.166.700 = 202.741.800
As you can see, leveraging this PaPM allocation functionality, we can create dynamic and automated allocation process using only ONE function without losing traceability.
But if we switched allocation type to Allocation with Offset Records, calculated result data set would be:
This offset allocation can be used (with and without iterations) when the sender has to be reduced by the allocated key figures and the receiver is enhanced, so the overall sum of the key figure values stays the same.
No comments:
Post a Comment