Unwanted re-pricing in graduated-to interval scale condition type.

[former_member418377]

Dear Experts,

We  are using  graduated scales for one of our pricing requirements. A condition type ZLBI is being used. This  condition type has scale type D (Graduated-to interval scale) maintained in configuration. The scales are accessed through condition records maintained  with a key combination  of price package( “customer grp 2” field maintained at contract header level Addition data A tab) and the  material. 

Business Scenario

An existing open  contract has price package ‘A’  maintained at header level. The line items have ZLBI condition type with values  based on scales maintained in condition record for price package ‘A’. There are other  condition types as well(normal condition types  with  no scales)  in  line items and  they  use  similar key combination table (material & price package).

Now  the price package is changed to ‘B’, and the contract is saved. Expected behavior is that the change in price package should not retrigger pricing for existing line items as the field is not a price sensitive field.

Issue:

Reopening the changed contract, it is observed that  ZLBI  condition value has changed in all existing  line items, and is  now showing values as per  condition record for price package  ‘B’. The other condition type  values are  not changed, and  have values as  per price package A only.  The issue is why ZLBI condition type value changes when  pricing has not  retriggered at the line item.

Please let me know if you have across this issue in graduated scales condition type and know the resolution.  

Thanks,

Kunal

[former_member418377]

Also, If I try to replace the scale condition type with a condition type with a VOFM  formula utilizing some Z tables for maintaining scales, same issue occurs.  it is noticed that the condition formula is re-evaluated for all line items  everytime I  open a contract

[Former Member]

HI Kunal,

AS you have already reached a Point where you are thinking about a PRICING ROUTINE. so the ABAP developer can do the code as per the Requirement (as was your first Post ).

As far as the last point mentioned above - the Revaluation of pricing. since the routine will be developed, the developer can put a check i.e in case the order is opened using VA02, check if any change has happened in the price if not then don;t revaluate the price

this can be the parameter for starting of the calculation logic of Prices. so if the order is being created/ price is changed - the Calculation for price will happen else No Calculation will happen.

[Former Member]

Hi Kunal ,

refer SAP Note 930537.

It might be helpful.

Regards

Vinu

[former_member418377]

Hi Vinu,

I went through this note earlier. It is clear that the condition get revaluated everytime you change something that might affect the scale base value. The concern is if I don't change anything at that line item, how should I stop this revaluation of pricing result.

Regards,

Kunal

[Former Member]

Hi Kunal ,

I would like you to check the condition type ZLBI without mentioning the scale type D and see how the system behaves. If you still have issues then we can narrow down that the issue is due to scale type D.

Also analyse what is the difference(Customizing) between the ZLBI Condition Type and others Condition Type. If you provide this input, it would be easy for the forum members to guide you better.

Regards

Vinu

[former_member418377]

Did that already before  I posted it here.  Once I remove the scale type D, the issue is gone. But  I cant remove it since that's the core here.

Regards,

Kunal

[Former Member]

Hi Kunal,

Since it looks mostly due to scale type D, a workaround  would be -

- Move ZLBI to a new condition type with Manual entries='C' (not to check if a condition record exists)

- De-activate ZLBI if the new condition type is found through a new requirement

- Further, use the step of the new condition type to calculate the subtotal.

Though the 2nd & 3rd steps are definitely possible, I'm not sure if the first step will work seamlessly and may sound too much of a workaround.

Regards,

Preetham

[former_member418377]

Hi Preetham ,

Yes thats too much of a work around. Also, I  had tried this earlier using a slightly different approach. My finding was that it behaves the same even if your condition is in-active.

regards,

Kunal

[Former Member]

Hi Kunal ,

Check the pricing analysis for different condition type. try to carry out new pricing and check the system behaviour.

[former_member418377]

Hi Vinu,

Carrying out new pricing  will update all condition type values as per the changed price package at header which is OK if I carry that out manually by clicking update price button.ll. Point is I don't want the existing line items to have any condition type changed unless I carry out new pricing. They should stay where they were after I change the price package.  Somehow, all other condition type stay same but  ZLBI  is getting changed which is an issue.

[former_member182378]

Kunal,

Somehow, all other condition type stay same but  ZLBI  is getting changed which is an issue.

Do condition types other than ZLBI have a field Pricing package in their respective access sequences?

If not then all those condition types shall remain the same value in other words these condition types are "immune" to the changes in pricing package field.

Note: Giving you an "extreme example", to prove that your basic thinking is flawed.

For customer C1, give 10% discount.

For customer C200 give NO discount

In the sales order, when the user is changing the Sold to party from C1 to C200, the system shall not still give 10% discount to the customer.

Your requirement is even if customer is changed to C200, give the discount.

That was not the "agreement" therefore condition records (for both customers) where maintained differently.

[former_member418377]

Hi TW,

Yes, the other condition type has the same access sequence.It  has a condition record maintained as well for the combination of  material and that new price package B.

My scenario is different. Let me throw some more light. I  maintain the price package at the header level. Whenever  a new line item is added to the contract, the price package at the contract header level at that time  should govern the price for that item. Now this work fine. Whenever I add a new line item, it picks the price package at the header and pulls the price accordingly.  The issue is  with the existing old line items. Whenever I change the price package, I see a change in price in line items because of ZLBI condition type (NOT other condition type which use the same access sequence) pulling a new price. This should not happen.

Reason(functional): Old line items were added when price package was A. Now that the price package has changed to B, it should only affect new line items I add but not old line items which have already been  agreed  with the customer as per price package A.

Reason(technical): The field I changed ,unlike the example you gave above of sold to party, is not a price sensitive field. A price sensitive field triggers new pricing. Customer grp 2 field is not price sensitive. I have not used any uerexit  to make it price sensitive.

You may try to replicate this scenario in std SAP IDES system using PR02 condition type and another condition type(non scale), both using the same  sequence(may use K305). Create a contract. Change the condition record for both condition types.Come back to the same contract. You will see the new price for PR02.  Surprisingly you will not notice the same thing  with other condition type.

Kunal