group (statistical) condition

[Former Member]

Hello,

we have the following requirement in SD pricing.

Prices and rebates on item level depend on a so-called "module value". This module value has to be determined for the whole SD order. This means that every item has a specific module value. The sum of all item is the module value for the whole order which determines the prices and rebates of each item.

E.g.: SD order:

item 100 Material 4711 Module value: 0,5

item 200 Material 4712 Module value: 0,6

total value for the order: 1,1

Price for item 100: when total value for the order >1: 100 USD

Price for item 100: when total value for the order <1: 200 USD

Price for item 200: when total value for the order >1: 50 USD

Price for item 200: when total value for the order <1: 75 USD

So the question how to determine the total module value. We thought about a statistical group condition with a group condition key to collect the module value of each item. The problem that in SD standard there is no appropiate scale basis as all end up in value or quantity.

May be some of you have faced a similiar requirement.

Any help is highly appreciated!

Thanks and best regards,

Mark

[Former Member · Accepted solution]

hi mark,

you can use an user exit to calculate the total module value and store it in a sales order field. then you can rite requiements to hit teh pricing conditions basis the value in this field.

saurabh

[Former Member · Accepted solution]

Hi Saurabh,

Hi Glenn,

thanks for your answer. We prefer to have the module value within the pricing procedure as we have implement the same in CRM (IPC) where we like to avoid the enhancement of the CRM-IPC interface. Our approach is as follows:

We like to define a statistical condition type for the module value: "ZVM1" as a group condition in order to sum up module values of all relevant items of the SD order. In this case we need a group key routine to identify the items. The open issue is how to define the condition type ZVM1 regarding the calculation type, scale basis, scale type and unit of measurement (as we need to sum up the module value and no quantities or values)?

We have to assign the module value to each item respectively material master data which is part of the module value calculation. We thought about a workaround apply volume scale to sum up the module value. This means we define a volume for each material and use the volume to calculate the correct scale base. But this solution would mean a lot of work concerning condtion master data (scales).

Do you have another idea?

Thank you very much for further input.

Kind regards,

Mark

.

[Former Member]

you can write a scale formula in VOFM to determine which scale value the real price condition will look at. Not sure what field you are storing the module value in.

You could have a statistical condition for the module value that is a group condition an write that value to say subtotal M (module) in the price procedure, then the formula value on the real price codition could read value in xwertm and make that the scale base value. Then your scale pricing should pick per your example.

[Former Member]

Hi Glenn,

thanks for your answer. Your second suggestion coincides with our idea. We like to define a statistical condition type for the module value: "ZVM1" as a group condition in order to sum up module values of all relevant items of the SD order. In this case we need a group key routine to identify the items. The open issue is how to define the condition type ZVM1 regarding the calculation type, scale basis, scale type and unit of measurement (as we need to sum up the module value and no quantities or values)?

We have to assign the module value to each item respectively material master data which is part of the module value calculation. We thought about a workaround apply volume scale to sum up the module value. This means we define a volume for each material and use the volume to calculate the correct scale base. But this solution would mean a lot of work concerning condtion master data (scales).

Do you have another idea?

Thank you very much for further input.

Kind regards,

Mark