You are on page 1of 8

Pricing of BOM : Dynamic determination of Net value of main item based on sub items

This document will talk about special BOM pricing case where net value of main BOM item is accumulation of cost price(s) , VPRS , of
all the sub items using condition type KUMU .

  For example a BOM structure –

          FG :-                BOM01

          Sub item1 :-      MATERIAL01

          Sub item2 :-      MATERIAL02

              MAP of Sub item 1 > MATERIAL01  = 20 USD

              MAP of Sub item 2 > MATERIAL02  = 30 USD

The net value of FG BOM01 should be =  20 +30 = 50 USD .

Should there be change in MAP of any sub items later ,if a new order is created then net value of order should reflect the new price
from VPRS of sub items .

There are two main issues in this case –

1. How to make sure that net value of sub items reflect the most recent material price (VPRS) ?

2. How to add all the sub item net values to arrive at final value of main item of FG in an order ?

Here is detailed design…

Standard SAP configuration:

Here are few standard config which is by default present in system

 Item category group is ERLA.


 Item category of the main item TAQ – pricing takes place at main item level
 Item category of the sub item TAE – no pricing
 Material master has appropriate value of material item category group .

In order to design this requirement , we need to change the standard configuration .

It is recommended to copy in “Y” or “Z” then only do changes .

Changes to TAE item category

  For enabling calculation of pricing for TAE item category, copy TAE item category and make following changes:-

Pricing = X – so that net value is calculated by system

                Determine Cost = “X” – So that VPRS value is determined automatically at sub item level.
Statistical value = blank   .           

          Above settings are required for net value calculation for BOM sub items.

            

          Please note that this is to help calculation of net value of sales order automatically. There will be no accounting
posting problems as this item category is not relevant for Billing.

Define new condition types

This solution requires defining 3 new condition types to achieve the pricing results.

– Net value calculation on sub items

       Create a new condition type of following attribute

      This is defined as prices and calculation type is percentage. The condition record will be maintained as 100 %.

Example:

Condition record of ZVPS is maintained as 100 % for any combination .

Hence, whenever there is a change in VPRS, automatically value of ZVPS is determined in sales order with same value of
VPRS.

Other elements of screen of condition type definition remain the same. Will see in a while its impact in pricing procedure
and significance.

– Condition type for Discount calculation on sub items:

Since the sub items are now relevant for pricing, we need to introduce a new discount type in pricing so that once
KUMU is determined based on the VPRS; the discount removes the net value from the item. This ensures that while
determining the net value of total order, system does not add up these sub items values to the main item.

ZDIS is defined like any other discounts.


Its position in pricing procedure is important and we will see it in subsequent step .

Condition type for Final Net value price of Main item

Once the sub items net values are determined, we will need this value to be transferred to main

item after accumulating for all sub items.

It can be possible that once the net value is determined, you may want to have further discounts /

taxes/ surcharges etc. Having a new condition type will help in those aspects.

New condition type, ZDUM, on same line of ZVPS is defined.

This is also percentage type and condition record is maintained as 100 %.

Will show you shortly why this is important to have this?

Using condition type KUMU

       KUMU is provided by SAP to be used for BOM related sub items pricing.
This is main condition type which will help in accumulating values across the sub items and then bringing to main item.

     

The main features of this condition type is that Calculation type = “G” Formula

And structure condition = “B” Cumulation Condition

Here is what SAP explains on B :

                  In the pricing procedure, this has to be used with calculation routine 36.

– Changes in pricing procedure

New pricing procedure is created for this demo.

Let us review the main items in this procedure.


 ZVPS will always have same value as VPRS.
 KUMU is used with routine 36. So it will cumulate values of all sub items and pass the value in main item.
 ZDUM condition records are also maintained as 100 % and it always calculate keeping base value of KUMU.

So although KUMU is statistical by using ZDUM, we get net value in main item which is accumulation of all the net
value of sub items!

 ZDIS is added after the gross and is pointed to step 10 (VPRS) . This is important so that net value of sub item is
back to zero once KUMU is determined.

Please note that If this discount appears before KUMU, it will not help in accumulation so it is important to position this
discount only after KUMU is determined.

Create Sales order using above design elements –

Make sure ZVPS , ZDUM , ZDIS conditions records are maintained. The simplest form of maintaining will be on
plant or sales org so that it is one time activity. But depending on case, need to choose the best access sequence
combination. Other steps are standard.

In this order, First item is main item and rest is sub items of BOM1 .

We will see the pricing of sub items and then for main item .

Pricing of item 30 , sub item-2 :


     – ZVPS ( net value of sub item ) is 100% of VPRS . 

     – KUMU has captured this sub item net value and displayed as statistical.

     – ZDIS has been applied to bring the net value to zero else this will be added to overall value of sales order and will
skew the net value of order .

Pricing of item 20 , Sub item -1

Same behavior of ZVPS , KUMU and ZDIS as observed before .

Pricing in item 10 , Main item

Here, the value of KUMU = net value of item 20 + net value of item 30 due to routine 36 .

ZDUM is 100% of KUMU this makes the net value of order main item as cumulative value of all the sub items value .

If there is a change in MAP of these sub items due to any reason, new order created will show the new price
automatically. 

Please note if there is requirement to have any discounts / taxes / surcharges on the main item , it should be added
applied after ZDUM .

Net Value of order is sum of all the sub-items internal cost .


So any change to MAP of sub item , it will automatically change the Net value of order .

Advantages
 There is no enhancement required to SAP design
 Effective use of standard SAP elements
 Integrated approach. Any change in MAP of material sub item will automatically reflect in sales orders.
 No Z table maintenance required.
 Accumulation conditions cannot be used as header conditions and edited manually
 When copying a sales document into a billing document, the condition rate and value of
a accumulation condition are “frozen”. This means that when copying, regardless of the pricing type, the
condition is not re determined. The net values are not added up again even if the individual net values have
changed.

Disadvantages  
 Accumulation conditions cannot be used as header conditions and edited manually
 When copying a sales document into a billing document, the condition rate and value of
a accumulation condition are “frozen”.

Hope this is helpful and clear !

This is an amazing write up and the one I have been doing some exploration for pricing based on BOM using
the cumulated condition types.  This document is going to be very useful to me.
However I have a small point to make. In the example you have created, the Gross Value(Subtotal1) is always
twice the value of KUMU and then you do a discount of 100% on ZVPS using ZDIS to bring it to the actual value. I
dont understand this part and I seem a problem there. I dont see any need to use the condition type ZDIS
The net value of item is 1110 and not 2220 .The idea to use ZDIS is due to fact that once KUMU have the value to
be transferred “up” , make the net value of item to zero via this discount .  If u remove ZDIS , you will observe that
net value of order = value passed by KUMU + net value of sub item hence doubling up the net value on main item .
To counter this , ZDIS is used . Hope i have answered your doubt

This is not standard customizing to cumulate the sub items price into main item. ( only cost cumulation is std - which
you can observe the Delivery- Billing copy control settings)
I assume, that Billing happens @ main item level, But the price maintained for components only. if yes, make
component items as relevant for pricing , but not relevant for billing & main item - item category as relevant for
pricing & billing ( maintain copy controls accordingly)
to cumulate the component prices into main item - write a routine & assign to condtype- if you have seperate cond
type will have more flexibility & will not disturb the other processes.
in standard process of SAP only cost cumulation happens to main item as my mate said.
but if you want to cumulate prices also into mainitem there is only way of solving it that is write a pricing routine and
apply the same against the condition type on which you want to calculate.
for which:
CONDITION TYPES ARE :
ZPR0 - FOR MAIN ITEM
ZPRXX - FOR SUBITEM
ZPYY - FOR SUB ITEM.
.********************************************************************************************************************************

Scenario for BOM


Posted onOct 19, 2010 at 06:09 PM | 20 Views
Follow
 RSS Feed
Dear All,
Good Morning,
I have 3 Materials A, B and C. A is the main Item. B and C will be the part of Material A in BOM. As per the standard
SAP SD if the Item Category Group is ERLA I will have Pricing and Inventory at Main Item. If my Item Category
Group is LUMF I will have Pricing and Inventory (Goods Issue) at Item Level.
As per my requirement I want to have Pricing at Header Level i.e at Material A and Inventory at Material B and C i.e
in my Deivery Goods Issue should be done from B and C and not from Material A. Is this scenario possible by
Customising my Item Category?. Please provide your valuable Inputs.

Its possible. This is the reuirement from some of the clients in automobile industry.
Where they dispatch the components & pricing will be @ Main Item level.
Before configuring this, you should consider the Costs also & Controlling reports.
Byfine tuning item categories & copy controls you can achieve this.
Few of them,
- main item , item cat - should relevant for pricing & respective copy controls should be maintained from Delivery -
billing
- Component item category- should not relevant for pricing, there should be any copy controls maintaiend from
Delivery - Billing.
- Dispatch happen @ component level, so PGI accounting document triggers based on std cost maintained for
components.
- Cumulate all the costs of components to main item. To do so, In Copy control @ item level. tick mark " Update
cost" for main item item category
- In Billing, Cost will be copied from components in Main item & profit margin calculation done accordingly.
NOTE:
This should be agreed by FI, then only you can take this further.
The above input provided with normal sales scenario only. other SD functionalities need to check like
Rebates/Credit Mangament/Free Goods / BOM Returns / batch management etc..,
From SD perspective, it doesnt have much impact.

You might also like