Global Config Paramters CONSIDER_PROPORTIONALITY & RANDOM_DISTRIBUTION

[vincentverheyen]

Hi,

I have the following situation, where I use a copy operator on aggregated level to copy to a target lower level Key Figure, that lower level Key Figure having the following settings:

• Disaggregation Mode: Equal Distribution
• Proportionality: Other Key Figure - Calculated Values
• Key Figure for Proportionality: XYZ
• Decimals: 0

With copying to a lower level, I mean: lower in non-time attributes, but while staying on the same time period level.

I am aware of note 2916737 - IBP: Disaggregation and rounding strategy - SAP for Me. It explains in detail how the SAP HANA Simulation engine does the rounding (down), and the carrying over of the remainder. It illustrates this by an example where a quantity of 4 on 1 Location is copied using a Copy Operator to a lower level and thus is disaggregated across 5 Products. Each of the Products gets the same value 0.8 before the SAP HANA Simulation engine starts its rounding process.

It says:
"Also, be aware of the following:

1) The order of planning objects is determined internally at runtime, it is not guaranteed that the Product A is always at the first place. Thus, the distribution of values may vary."

However, the note does not explain Global Config Parameters CONSIDER_PROPORTIONALITY & RANDOM_DISTRIBUTION in detail. Instead it refers to articles Disaggregation Mode: Equal Distribution and Disaggregation and Proportionality.

Global Configuration Parameters in the Model Configuration Guide explains RANDOM_DISTRIBUTION:

"If it's not possible to distribute the aggregate value of a key figure equally, the system distributes the remainder automatically to some of the child buckets. By default, the system selects the child buckets for remainder distribution randomly. By setting this global configuration parameter to NO, you can enforce that the system applies a logic when selecting child buckets. As a result, the remainder will always be assigned to the same child node if you disaggregate the same value with the same proportional factors."

And article Disaggregation Mode: Equal Distribution adds, with regards to RANDOM_DISTRIBUTION:

"If you distribute 10 equally to 3 buckets with aggregation mode "Sum" and rounded to zero decimal places, you will get one of the following results: 4, 3, 3 or 3, 4, 3 or 3, 3, 4.

In the default configuration, if you repeat the disaggregation several times, you may get a different result every time. By default, the global configuration parameter RANDOM_DISTRIBUTION is set to YES. If you set the parameter RANDOM_DISTRIBUTION to NO, you will get the same result in each iteration. The parameter doesn't allow you to specify which of the results you will get."

So, does this mean that I should interpret the note 2916737 - IBP: Disaggregation and rounding strategy - SAP for Me about the SAP HANA Simulation engine as explaining only the behaviour if RANDOM_DISTRIBUTION is set to YES (default value)?

And what happens when we set RANDOM_DISTRIBUTION to NO?

The above says "The parameter doesn't allow you to specify which of the results you will get." However, my first question is: what exactly is the algorithm used to distribute the remainder if RANDOM_DISTRIBUTION is set to NO... since my assumption is that note 2916737 - IBP: Disaggregation and rounding strategy - SAP for Me is only relevant for RANDOM_DISTRIBUTION set to YES (default value)?

Could somebody clarify this please? Is RANDOM_DISTRIBUTION only relevant for child buckets (time periods), or also in my case of Copy Operator using "Proportionality: Other Key Figure - Calculated Values", in the case of copying to a lower level in non-time attributes, but while staying on the same time period level.

My second question is about CONSIDER_PROPORTIONALITY.

Global Configuration Parameters in the Model Configuration Guide explains CONSIDER_PROPORTINALITY:
"This parameter controls if the proportionality of the key figure should be considered when distributing remainders or if the values can be randomly distributed. If the value is set to YES or X (case insensitive) the proportionality is considered, otherwise not."

My second question is: what "proportionality" is meant here exactly?

Article Disaggregation and Proportionality adds, gives some examples with regards to CONSIDER_PROPORTIONALITY:

• Distribution when global configuration parameter CONSIDER_PROPORTIONALITY is set to YES
• Distribution when global configuration parameter CONSIDER_PROPORTIONALITY is set to NO and RANDOM_DISTRIBUTION is set to YES

However, the examples are seemingly about 1 Product [for example] which is disaggregated across different time buckets which all have a different period Weight.

This might be different when considering the example given in note 2916737 - IBP: Disaggregation and rounding strategy - SAP for Me.

Could someone clarify how this parameter would influence the example given in 2916737 - IBP: Disaggregation and rounding strategy - SAP for Me, which I understand as being about disaggregation within 1 time bucket (or additionally: several time buckets, but with the same period weight), where we have disaggregation of quantity 4 across 5 Products? This would mimic my own case (in the case of copying to a lower level in non-time attributes, but while staying on the same time period level, simply disaggregating within the same time bucket), where let us say that the Key Figure for Proportionality: XYZ has an equal proportion for each of the 5 Products. So that would result in a value 0.8 before the SAP HANA Simulation engine starts its rounding process.

[vincentverheyen]

I did a test with a copy operator, with a quantity of 4 on Product level before disaggregation, copying down (Copy Level: Product) to a target key figure on Product + Customer level with 5 Customer combinations for that Product. Proportions key figure is equal (value of 1) for every combination. There is no Time Disaggregation. The amount of periods, or 'time buckets' is 61. The results are as follows:

Note: You will notice in Column A, I did 3 Iterations per test case. Where an "Iteration" (a.k.a. run) means: running an application job which first clears the key figure "After disaggregation", then runs the Copy Operator job once again to create new disaggregated values.

Case 1 (Default values):

• CONSIDER_PROPORTIONALITY: NO (= Default)
• RANDOM_DISTRIBUTION: YES (= Default)

What is interesting to note, is that on every iteration, the values do not change. For example: Customer 1 always gets 83.60...% (that percentage is: it received 51 times the value 1, whereas the theoretical maximum would be 61) for every Iteration. Every Customer always receives the same percentage in every Iteration. Not only is this total split (evaluated across the total of the time periods) the same on each Iteration, the reason for this is that even the exact distribution in each time bucket of 'zeroes' and 'ones', is exactly the same for each and every Customer.

In this sense, I wonder if the result of the RANDOM_DISTRIBUTION is skewed by some unknown algorithm, rather than approaching a random outcome, on each Iteration. Of course, theoretically, extended over an unlimited amount of periods, for each Customer individually, this might approach a theoretical random distribution and thus an end result of 80%. However, practically, due to the intrinsically limited nature of Planning, I would like to better understand the algorithm that is responsible for the same skew in Planning-Objects on each and every Iteration. Because we would be hoping for a fair random distribution for each of the Customers, would it not be more 'random' if the random distribution was different on each and every Iteration?

Now let us switch on Proportionality.

Case 2:

• CONSIDER_PROPORTIONALITY: YES
• RANDOM_DISTRIBUTION: YES (= Default)

Again, we see that no random outcome is achieved. The exact values are exactly the same every Iteration.

Now let us turn to another case, where we siwtch off RANDOM_DISTRIBUTION.

Case 3:

• CONSIDER_PROPORTIONALITY: NO (= Default)
• RANDOM_DISTRIBUTION: NO

Again, we see that, on every Iteration, the values are exactly the same. It is always Customer 2 who receives no quantity whatsoever.

In the final case, where we change both default Configuration parameters' values, we notice that it is a different Customer (Customer 1) who receives no quantity whatsoever, on every Iteration:

Case 4:

• CONSIDER_PROPORTIONALITY: YES
• RANDOM_DISTRIBUTION: NO