Skip to Content

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

/wp-content/uploads/2012/10/pic1_145259.png

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

/wp-content/uploads/2012/10/pic2_145260.png

      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.

/wp-content/uploads/2012/10/pic4_145261.png

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.

/wp-content/uploads/2012/10/pic3_145263.png

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.

/wp-content/uploads/2012/10/pic13_145264.png

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.

     /wp-content/uploads/2012/10/pic5_145265.png

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 :

/wp-content/uploads/2012/10/pic6_145266.png

                  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.

/wp-content/uploads/2012/10/pic7_145267.png

  • 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 .

/wp-content/uploads/2012/10/pic8_145268.png

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

Pricing of item 30 , sub item-2 :

/wp-content/uploads/2012/10/pic9_145269.png


     – 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

/wp-content/uploads/2012/10/pic10_145270.png

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

Pricing in item 10 , Main item

/wp-content/uploads/2012/10/pic11_145271.png

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 .

/wp-content/uploads/2012/10/pic12_145272.png

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 !


        


To report this post you need to login first.

34 Comments

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

      1. ' MoazzaM '

        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?

        (0) 
        1. saurabh upadhyay Post author

          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 .

          (0) 
          1. ' MoazzaM '

            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.

            (0) 
        1. saurabh upadhyay Post author

          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!

          (0) 
      2. vinay kulkarni
        hi very helpful doc, but 1 question, will not all the condition types above ZDUM will ne inactive as all are price condition types and zdum will deactivate all the condition types above it, only changing the condition type to dis/surcharge they will be active ones, plz provide inputs. tahnks for the article
        (0) 
  1. Navaneetha Krishnan

    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.

    (0) 
    1. saurabh upadhyay Post author

      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 🙂 .

      (0) 
      1. Amit Kumar

        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.

        (0) 
  2. Typewriter TW

    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.

    (0) 
    1. Warren Nash

      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.

      (0) 
        1. Rakesh Kaliyaperumal

          Hi TW Typewriter Sir and @Warren Nash Sir,

              please refer the following link  where i have posted our requirements.

          http://scn.sap.com/message/14336400#14336400

          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.

          (0) 
          1. Typewriter TW

            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!

            (0) 
        2. Warren Nash

          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

          (0) 
          1. Pradeep Mani

            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

            (0) 
            1. Typewriter TW

              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.

              (0) 

Leave a Reply