Moving Average Price changes of structured articles

I decided to post this blog, because there is a topic coming up from time to time by our customers, which causes many confusion and misunderstanding, although it is not so complicated as it looks like to be for first.

I hope after reading my explanation many people will get the answer for their doubts.

When splitting up a structured article to its’ components eg. at the time of posting Goods Receipt (movement 319), the calculation of the MAP (Moving Average Price) of the components will be detailed below.

Some basics first

The MAP calculation works basically as per this formula:

The current MAP is stored in MBEW table (field VERPR).

When looking for the history of a specific MAP, the CKMI1 table will show to necessary entries.
The key (KALNR field) value can be extracted from the MBEW table, by copying the KALN1 field.
It makes sense to enter also a range for the Date in CKMI1, reducing the relevant entries for those days, when the questionable movements have happened. As soon as we display the list of corresponding DB entries, we can easily follow the changes happened to the MAP by posting the different material documents (AWREF field in CKMI1).

MAP of Structured article

Let’s take an example for easier understanding:

Sales set		Components
Cosmetics Gift		2  Lipsticks	+             1  Perfume
	MAP:	10 / PC	200 / PC

The posting value of the components is calculated as per the following formula:

This is nothing else then distributing the posting value of the structured article proportionally to the components also considering the contribution of each components by weighting them in the formula.

If the sales set “Cosmetics Gift” is posted in article document with value of 199, the formula applied for each components:

• Lipstick: 10 * 199 / ( 2 * 10 + 1 * 200) = 9.0454545
• Perfume: 200 * 199 / ( 2 * 10 + 1 * 200) = 180.909090

Checkback:     2 * 9.045 + 180.909 = 199    OK!

Similar example can be found on SAP help portal as well, with less explanation and without formulas.

UPDATE:

In certain cases, the MAP calculation may appear to differ from the above explanation. This is always the result of too low amounts involved in the formula, resulting in rounding issues and similar technical limitations. Here, I present one possible scenario that may cause confusion, and I will also provide the explanation along with it.

Let’ assume we have the following MAP values:

• Sales set (header): 0.01
• Lipstick (component 1): 10
• Perfume (component 2): 20

Now, what will be the new component value for each?

• Lipstick: 10 * 0.01 / (10 + 20) = 0.003333333
• Perfume: 20 * 0.01 / (10 + 20) = 0.006666666

Here comes the technical limitation part of this scenario: these values are stored with 2 decimal places.
Considering this fact, the values stored for each component will be rounded as follows:

• Lipstick:  0.003333333 → 0.00
• Perfume: 0.006666666 → 0.01

When posting a WPUUMS IDoc with movement type 252 (GI) for example, these rounded values will be considered for MAP calculation and also for updating the MBEW table.

However, for the Lipstick, the calculated value was zero, which is understood by the program (ABAP general limitation) as initial value, as if no new value had been provided by the calculation.

This will result in updating the components in MBEW as follows:

• Sales set (header): 0.01  → 0.01
• Lipstick (component 1): 10 → 10
• Perfume (component 2): 20 → 0.01

I would like to highlight that the initially assumed data set is not realistic, and it is obviously the root cause of the currently detailed behavior.

In summary, because this is most probably not the desired result, you need to pay attention avoiding this data constellation by using revaluation with MR21 transaction and setting the MAP of the Sales Set (header) article to 30, which is the sum of the components normally.

Using an extremely low amount of costs during MAP calculation of structured articles always carries the opportunity of unexpected behavior, which results from the distribution of the already low amounts. (Another example of such behavior: when the UoM of the component is in ‘KG’, while the structured article contains only few ‘G’ of it → this may result in  ~0 values once again…)