# Universal Allocation – Iteration Flag test on S/4 HANA 2021 !

Hello, friends!

Some days ago, I read the blog “Universal Allocation in SAP S/4HANA 2021” written by Daigo Imai. According to the blog, in S/4 HANA 2021, the Universal Allocation APP (ID F3338 ) allows iteration, a functionality that was missing in previous versions. Let’s see an excerpt from Diago’s blog:

*Excerpt of Blog – Daigo Imai*

With this great news, I decided to do a test of the functionality and, of course, share with you my results! If you are interested in recursiveness, you can find other interesting blogs I created in the past at the following links:

Recursiveness in Cross Company Margin – SIT Business Function

Recursiveness allowed with Material Ledger

If you are not familiar with the Universal Allocation APP, I recommend you follow Daigo Imai as he has good content published about the topic.

If you are not familiar with iteration functionality, please read the SAP Help.

Let’s Start! For example, I created four cost centers:

COC1ALOS01, COL1ALOR01, COL1ALOR02, COL1ALOR03.

Then, I created a “simple” allocation cycle with two segments and modeled a recursiveness scenario between them. In a nutshell, we can describe the scenario in the following way:

- Assume that all the costs incurred by a sender cost center are redistributed.
- The recursiveness occurs on the cost centers COL1ALOS01 and COL1ALOR03, because COL1ALOR03 has a sender-receiver relationship with COL1ALOS01.
- I said this is a “simple scenario” because both COL1ALOS01 and COL1ALOR03 are going to end the cycles with a net value of ZERO.
- The next pic shows the name of the cycle and segments; the sender, receiver, and the percentage of allocation.

If you are a visual person, the next pic will clarify the loops better. COL1ALOS01 assigns values to COL1ALOR03, whereas COL1ALOR03 assigns amounts to COL1ALOS01:

Now, with the model created, the idea is to show you in simple words the math you can use to interpret the results of the app. Now, we are going to enter the app “Manage Allocations” and see the details of the cycles.

Our cycle is UA00001, with 2 segments.

Next Segment 1: You see, the sender is COL1ALOS01. The receiver screens show the allocation percentages.

Then comes segment 2: The sender is COL1ALOR03, and the receivers are COL1ALOR01, COL1ALOR02, COL1ALOS01.

In order to have data to do our test, the next step is to debit our sender cost centers. For this example, I’m going to post 10,000 on COC1ALOS01 and 1,000 on COL1ALOR03. The next screen shows the initial state of the system on the app Cost Center-Actuals.

That is! The system is ready. Our model is complete with the debits posted on the cost center. The next step is calculate the values to be allocated, of course, in excel! I’m going to show you the 2 first iterations and then share with you an XLS that ends the flow.

**Iteration 1 – Segment 1: **The original value of Sender COL1ALOS01 is 10,000. 100% of the amount is distributed. 10,000 multiplied by 0.1, 0.3, and 0.6, respectively.

**Iteration 1 – Segment 2: **Sender COL1ALOR03 has an original value of 1000, and Cycle 1 adds 6,000; so the total value to be assigned is 7000. Assignment is proportionally to 0.3, 0.3 and 0.4 respectively.

At the end of Iteration 1, cost center COC1ALOS01 had an open value of 2,800. This amount enters as an input for iteration 2.

**Iteration 2 – Segment 1: **Iteration 2 begins with 2,800 on cost center COC1ALOS01. The 100% of this amount is assigned again to the receivers of the segment proportionally to 0.1, 0.3, and 0.6 respectively.

**Iteration 2 – Segment 2:** Segment 2 begins with the amount of 1,680 that comes from the segment 1. The process is the same as the iteration 1, where the amount was distributed to COL1ALOR01, COL1ALOR02 and COC1ALOS01.

At the end of iteration 2, cost center COC1ALOS01 had an open balance of 672.

The next steps are to repeat the same process of iteration 2 until the end balance of cost center COC1ALOS01 is close to zero.

Then we repeat this process until the open value of the cost center COC1ALOS01 is close to zero. For this example, I do 11 iterations, accomplishing the expected close to zero open balance on the cost center with a value of 0,0018.

In the app “Allocation Result”, the system shows how this sender-receiver graph works. Let’s understand what these numbers mean.

There are multiple ways to interpret these results. The easiest and most natural thing is to begin from the receiver side::

- Cost Center COL1ALOS01 show a value of 3,684, This value is the sum of the amounts received on each iteration. 1st iteration: 2,800, 2nd; 161 and so on!
- Cost Center COL1ALOR01 show a value of 4,132. Same concept: In the 1st iteration, it receive 3,100; in the 2nd 748 and so on.
- The other cost centers are calculated in the exact same way.
- In the next screen how the amount each cost center receive on the iterations, and the sum of the values!

Now, analyse the sender side:

- In the app, Cost Center COL1ALOS01 shows a value of 13,684 as the sender. This value is the sum of the amounts received (3,684 ) plus the original amount it had: 10,000.
- Again in the App, Cost Center COL1ALOR01 shows a value of 9,210. Same concept: this value is the sum of the amounts received ( 8,210 ) plus its original amount of 1,000.
- The other cost centres are calculated in the exact same way.
- On the next screen, we can see the amount each cost center receives on the iterations and the sum of the values!

Now resume what we see on the next screen! The sum of the senders’ (13,684 + 9,210 = 22,894) equals the number of the receivers: (3,684 + 4,131 + 6,868 + 8,210 = 22,894).

Now, the next step is check the financial document. Lets see the Journal Entry Analyzer (app F0956)

The final result can be validated on the Cost Centers-Actuals app. Here, we see both COL1ALOR03 and COL1ALOS01 with a net value of 0 (debit with the original account and credit the assessment account), and the cost centres COL1ALOR01 and COL1ALOR02 have open balances of 4,132 and 6,868 respectively, both with the allocation account. The allocation account have a balance of 0 (-1,000 -10,000 + 4,132 + 6,868).

And that’s is! The amounts calculated by the app were calculated by hand and the numbers match. I hope you enjoy this blog and that it helps you with your future projects. As previously said, this is an easy example of iteration, but gives you the foundation to solve your own business cases.

Disclaimer

I’m a newbie on Fiori & Odata, which means I don’t check the code the Universal Allocation programme uses. In my other blogs related to recursiveness, I spend some time checking the code to validate my own calculations. In spite of that, the algorithm I use to solve the example is quite generic and intuitive, and I guess it matches with the apps’ logic.