# 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:

• 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…)

### Assigned Tags

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

Pretty good illustration there on calculating the price adjustments.

Andras Strobl
Blog Post Author

Thank you James 🙂

Hi Andras,

when you say: "If the sales set “Cosmetics Gift” is sold with value of 199" do you mean cost value (MAP) of the sales set or Retail Sales price?

Also, why would the sale of the set alter the cost price of the components? Isn't this against the logic of SAP according to which the Sales/Consumption value is ( MAP * Consumption qty ) ?

Andras Strobl
Blog Post Author

Hi Nikolaos,

Thanks for pointing out to this sentence - I have corrected it. Actually the sales set's final price (for which the consumers can buy it, is not the MAP of course, hence final price includes taxes, etc.) The above description of the implemented logic shows how the MAP changes are calculated and saved in case of structured articles (incl. components).

Sorry, your question regarding altering the cost of components would be against SAP logic is not clear.
The Sales Set consist of it's components. If the components are inventoried (exploded in the goods movement), their MAP have to be updated as well. And it is important to understand (this is why this blog post has been released), that updating the MAP of the components is not calculated simply on proportional way - how it is expected by most of our customers, but there is a weighting considered here as well, as you could see above in the formula.

Best regards,
Andras

Dear Andras,

In our ECC 6 Ehp 8 Retail system, when performing a 317 movement for creating 1 Sales Set A (with components B (1PC) and C (1PC)) the accounting entries performed by the system are:

Set Article A (317 +)

• Debit: Stock Account: (1* MAP of article A) EUR
• Credit: Offsetting P&L Account:  (1* MAP of article A) EUR

Component B (317-)

• Credit: Stock Account: (1* MAP of article B) EUR
• Debit: Offsetting P&L Account:  (1* MAP of article B) EUR

Component C (317-)

• Credit: Stock Account: (1* MAP of article C) EUR
• Debit: Offsetting P&L Account:  (1* MAP of article C) EUR

Same logic is applied by Std. SAP when an inbound idoc from the POS system is processed for a retail sale of 1PC of sales set A, having an additional line of the 251 movement.

On our system, the creation of a sales set does not change either the Moving Average of the set or of the components as all movements are valuated at the current stock price of each material. Nevertheless, movement 317 creates a P&L effect in case the moving average price of the sales set is different from the sum of the cost values  of the components

What you describe happens when a structured article (Display Set) is split to it's components via movement 319.

Can you please validate/invalidate my thoughts/findings from the system?

Thank you very much,

Nikos

Andras Strobl
Blog Post Author

Updated on 29.09.2023