Pricing of BOM : Dynamic determination of Net value of main item based on sub items
Dear Gurus ,
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 !
great work man. I will test this in my DEV. Thanks for sharing this.I need exactly this. 🙂
great work done by you. Thanks for sharing.
Thanks ! . Hope this helps in your case .
Hi Saurabh.
This is very helping but I am confuse how to utilize this. I have both materials (with Sub items and without sub items) e.g. Sales BOM sale and normal sale. I have to use same document type, same customer, same sale area and same pricing procedure. Can I do normal sale and BOM sale in this same pricing procedure?
Hello ,
In my case i was able to have different doc type for BOM sales and Normal sales due to complexity involved . But looking at your prob statement , you may try condition exclusion technique to not trigger list price if ZVPS is triggered or some logic similar to this .
I am also thinking the same and going to try this. But my pricing procedure will get very complex which already is 🙂
Let me try and I will update you.
Dear i have one doubt on this pl tell me what stranded condition types you have selected
pl tell me ,,good job
thanks a lot
Hello Venu - KUMU is the standarad condition type used here . Other condition types are fairly common and you can refer the screen shots to see different attributes used .
Thanks!
Great Job....................Thank you
thanks!! just what I needed here too.
maybe I dont need ZVPS at all, but it seems to be fine
Hi Saurabh,
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.
If you can explain this it will be great.
Otherwise, this is a great document.
Hello Naveen , Thanks ! .
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 🙂 .
Hi,
I am clear now.
Thanks for the clarification. Good thought about the use of ZDIS.
Saurabh..i guess you could have made Statistcal Value = X or Y for component's item category TAE. it would have stopped the net value of components added up to the document level. And we may not need ZDIS in that case..
Nevertheless great knowledge sharing..
Cheers
Amit.
Good Concept and good work.
Nice document Saurabh, great work !!
Thanks for enlightining !
saurabh,
Very nice! Creative use of pricing!
Two comments -
1. If the prices (can be equal to costs) at sub-item are calculated, then the total shall be available in VBAK-NETWR. Probably there is no need for tranferring the Net value to the main-item level!
Ofcourse, I don't know the exact business requirement.
2. Generally why would a company want to sell its goods at cost price?
Suppose a company sells a mouse and also sell this mouse as a BOM; if it sells the mouse at cost price in BOM, it would be difficult for the company to sell it with profit when sold separately.
2. I agree. I can only think that there is another material used in the sales order then the business agrees to recover the BOM material at cost.
Waza,
Could you please give more details about your comment?
Hi TW Typewriter Sir and @Warren Nash Sir,
please refer the following link where i have posted our requirements.
By following this Document i was successful in transferring the material cost of Sub item to the Main item.
Somehow i tried and successfully transferred selling price(PR00) of sub item to main item, but in that case my SO net vale is become double.
Main Item - INR 30.00 ( Transferred Price of Sub Items)
Sub Item 1 - INR 10.00
Sub Item 2 - INR 20.00
Net Value is - INR 60.00 + Taxes.
Regards,
Rakesh K.
Rakesh,
When you maintain the value of PR00 in both main and sub items, then the system shall populate net value as double the "should be" price.
In this example, saurabh has not maintained any net value at sub item level. The price is maintained ONLY at main item level.
You either have to maintain price at main or sub item level. NOT at both levels!
I can only a Client where they had special SO type where a userexit was used to set a status profile for approval. The BOm had two alternatives and if I remember correctly one of the alternatives was at cost because they wanted to get rid of the stock, and it was linked to something like the use of "sets".
Regards
Waza
Good work Saurabh,
Pls tell me how the ZDUM value is calculated we have maintained it as 100%,
but no base for calculating is mentioned,how it calculates taking KUMU as base,we have not maintained any From/To,Subtotal etc for the condition type ZDUM in pricing procedure
Pradeep
Pradeep,
Yes in the pricing procedure, for ZDUM no from to values are maintained; the default is the total of all the values before it - so base value is add step 10 to 30
But here step 20 condition type ZVPS would not populate as it is being "screened" (not selected because of the condition record has material that is the main item.
So ZDUM base value is step 10 and step 30.
Condition record maintained for 100% of the above.
saurabh upadhyay
In the example, the main item has cost (VPRS) = 1USD, why?
Is the cost of the mainitem = main item cost + cost of sub items?
This is a Valuable Document and Applauds for your Efforts.
Fantastic document with great explanation.
Very informative and useful in BOM usage.
Thanks for sharing.
Hi all ;
Well explained document of structure condition , also can be implemented for variant configuration. Also this implementation can be developed for more demands...
Thanks for sharing saurabh upadhyay
M.Ozgur Unal
nice document.
Thank you for this very useful document!
Regards,
João