SD Bom pricing.

[former_member775706]

Dear Advisors,

I wish to seek a clarification on the following case, on pricing of a sales BoM.

  The BoM under review is at single level and has a peculiarity that the price of the parent material is the summation of the components (with possible discounts, surcharges and definitely taxes).  In other words both are priced.

An illustration is as follows:

The line items are priced as below:

Header:

The components are priced as follows:

The above repeats for each line item,ZP32, being the component's basic price and ZP31 being the cumulative price, for the four components.

We propose to bill the first line item at the cumulative price and pass the value to accounting as basic price.

I face the following difficulty:

The underlying pricing procedure is as follows:

The billing(order based, only for the header item) is generated with a value of zero and no value is passed to accounting.

I would be happy to receive views on the above and would be delighted to honour all replies and complement solutions.

Regards,

Gopidas

[Former Member · Accepted solution]

Hi,

is this a SD-BOM, what is the item category of the parent material?

Regards.

[christine_khberger]

Hello again,

I had another look at this and in your screenshot of the invoice it looks like only the main item was copied to the invoice and the components were not copied? If the price is entered for the components and these are not copied to the invoice there is no price there. Could that be the problem? In addition, if the components are copied to the invoice, please check the copy control on item level.

I hope this helps.

Kind regards,

Christine

[former_member775706]

Dear Ms Keuhberger,

Yes indeed!!!

It is a matter of design that the line items shall not be copied to the billing document.

They would not be billed.  Billing is for the entire value of the 'package' or header item.

Due to this, the price of the header item was not being carried forward into billing, a matter of copy control as correctly identified.

The same copy control rules exist for both types of BoM items, both (BoM) header and items.

This is because in customising,the  item (category) was identified as statistical.

This was changed which lead to the item being enabled for receipt of value and onwards transmission to accounting.

I wish to thank you for helping me both understand the problem,redefine and eventually solve it.

Regards,

Gopidas.

[former_member775706]

Dear Mr Ressos,

Thank  you for reading through the case.

Yes, it is a sales. And the BoM is  a simple single level sales BoM.

I have endeavoured to clarify with screen copies.

1.  Header is ZPBH:

2.  Item ZPBI:

[christine_khberger]

Hello,

in your pricing procedure the sum of the net amount starts at line 110 and not at line 100 where your item price is contained. In addition, the price of the header is statistical. You write that header item and components are priced - then the line in the pricing procedure with condition type ZP31 should not be statistical.

It would be a bit easier to read your example if the components would have a different price than the header item. Then it would be clearer that hte 10000 of the net amount of the component are coming from the header and not the component.

[former_member775706]

Dear Ms Keuhberger, (leider kann ich nicht umlaut schreiben,damit,bitte entschuldigen)

Thank you very much for reading the case and choosing to respond.

Firstly, regarding the condition type ZP31 being a part of the price,but being statistical.

     This is keeping with the recommendations of a structural condition,suggesting it being statistical.  As observed and inferred correctly, it would not be relevant for accounting and hence condition type ZP30 is set with 100% value and set as relevant for accounting (ERL).

Nextly, as observed, the condition type ZP32, would have no value for header line item. It is expected to be evaluated as part of structure condition evaluation.   Would the value be provided for the condition or it be included in procedure, I fear the value would cumulate for the header material.  It would however be valid for the components.

I have adopted your advice and tried to price each material with a different price as:

Component 1 =100

Component 2 =200

Component 3 =300

Component 4 =400

Cumulative =1000

Trust the above example serves to clarify.

Regards,

Gopidas

[Former Member]

Dear Gobidas,

i see that your net price is clculated on step 110. I think that it should calculated on step 120 of pricing procedure.

Regards.

[former_member775706]

Dear Mr Ressos,

I indeed uphold your observation,  the cumulative price is calculated at step 110.

It is being copied on to 120 by setting it at 100%.

Regards,

Gopidas.

[Former Member]

Dear Gopidas,

i see your pricing procedure, in  my opinion in the net value you need to add a calculation type.

is the problem only that you do no have a net value or you have errors in accounting too?

Regards.

[christine_khberger]

Hello again,

in your example:

Component 1 =100

Component 2 =200

Component 3 =300

Component 4 =400

Cumulative =1000

What ist the total value of one unit of this material with components?

1000 or 2000?

Are condition records maintained for ZP31 and ZP32?

I find it strange how for the components both condition types have a value. Could you please make a screenshot of the pricing procedure where also the columns further to the right are visible?

Kind regards,

Christine

[former_member775706]

Dear Ms Keuhberger,

Thank you for thinking about the case.  I clarify as follows:

Condition record is entered (manually) only for ZP32.

ZP31 is a structure condition, which is expected to derive its value from the preceding condition type, for each line item of component (ZPBI) and cumulate the amount to the line item of header(ZPBH).  It therefore does not require maintenance.

ZP30 is set to 100 percent of ZP31 in order to release the value to accounting.

The order behaviour of the pricing procedure is satisfactory.

Problem is mostly in billing where the header line item is generated with zero value.

I attach a copy of the pricing procedure for reference and analysis:

Trust it helps you in analysis.

Regards,

Gopidas

[former_member775706]

Dear Mr Ressos,

Thank you for the analysis.

There is one calculation type added for the cumulative condition ZP31, that is '36' as recommended.

As identified correctly, the billing document is generated with zero value and therefore is not relevant for accounting.  Sadly, accounting for that value is the whole purpose of the transaction.

I invite you to kindly reconsider the case in the light of the above information.

Regards,

Gopidas.

[former_member775706]

Dear Mr Ressos,

Thank you very much for your effort.

In fact, your line of thought and analysis,set me thinking. I picked up the thread of thoughts from the accounting problem and realised that the problem was in the document,or rather the document's line item, not being transferred to accounting.

This lead to the conclusion that the item was not being regarded as relevant to accounting, in spite of my badly wanting it to happen.

This in turn is governed by the item category being relevant to accounting, which may be disabled by setting it so at the transaction 'Define pricing by item category'.

Co-incidentally, the line item category ZPBH in our example was set as statistical with value 'X'.

It is also manifest with the line item having zero value on the billing document item overview screen in spite of the item having a price on the pricing details screen.

The transaction was repeated with the item category being relevant for pricing (non-statistical) by clearing 'X'.  The transaction has thenceforth been adopting a price and further transmitting it onward to accounting, as desired.

At this point, I would like to draw a fine distinction between the condition type being statistical in the pricing procedure as well as the item category being set as statistical.

I have attached the customising screen so that they may serve to guide into the future.

The customising steps are as follows:-

The following step:

The decisive setting:

And the consequence(as desired and sought):

Mr Ressos, YOU deserve full credit for 'path-breaking' inspiration.

Thank you.

[former_member775706]

Dear Frl Keuhberger,

I owe you a special complement, because you have helped me question my premise and have served to reassure me that I was at the right point, although on the wrong track.

The expected price according to your illustration was 1000 and not 2000,a point that I had not replied in the previous correspondence.

I would be happy if you would kindly read my observations to Mr Ressos,to know more about the undeclared part of the case.

Vielen Dank,

Freue Weihnachten

in anticipation.

Regards,

Gopidas.

[Former Member]

Dear Gopidas,

thank you very much for your good words.

I really appreciate.

Regards,

George