cancel
Showing results for 
Search instead for 
Did you mean: 

How to identify pricing in sale order (PR00) difference from price master VK11 maintained

Former Member
0 Kudos

hi guys,

During sale order creation system can auto populate PR00 price from master data. incase user changes the price PR00 which is different from the price master. then is there any system variable to identify during runtime ?

i tried checking konv-kmprs , konv-kherk ,komp-cepok , komp-mprok ,  which is not correctly shown.

kindly advise

Accepted Solutions (0)

Answers (6)

Answers (6)

former_member184881
Active Participant
0 Kudos

Hi,

Create one more condition ZPR0 only for display and calculation for difference between PR00 and ZPR0.

Also maintain a stapes in pricing procedure to calculate the difference value (PR00 - ZPR0).

Like:

PR00:                     100

ZPR0:                     90

Diff (PR00 - ZPR0): 10

In condition Type: PR00 maintain option for manual changes

And condition Type: ZPR0 maintain option for no manual changes.

Also this condition value should be negative

In pricing procedure maintain two condition and calculation stapes:

So in sales order price will come automatically by VK11 and if users manually change a price condition PR00 then PR00 and ZPR0 difference will come.

Example:

Here PR00 condition change option is open to change the value but ZPR0 change option is not open.

thanks

Md. Enayet Hossain

phanikumar_v3
Active Contributor
0 Kudos

Dear--I dont understand the logic why you kept from and to Columns-- as 10 and 11 for the Pr00 and ZPRO???(I can understand this for the diff you can keep in step 12)

Phanikumar

former_member184881
Active Participant
0 Kudos

Hi Phanikumar,


yes, it is easily to understand for users that manual and autometic price difference if they maintain.


thanks


Md. Enayet Hossain

Jelena
Active Contributor
0 Kudos

I don't think it's feasible to identify whether the price was changed manually or updated from the pricing condition. For the program it's all the same, I believe. There are only flags available for BAPI update or when update is in background (e.g. by a job).

However, it's been pointed in this forum many times that it is actualy not a good idea to use the same pricing condition as both manual and automatically determined. If there needs to be an additional discount or just a price override then this should be done using additional conditions. This provides much better control and visibility.

As a matter of fact, in our organization we had ZPR0 condition that was both manual and automatic and it caused nothing but trouble. We changed it and had no issues since.

former_member205178
Contributor
0 Kudos

Hi Jelena,

Attn :: Kumar.


You are spot on also in advocating Best Practice of having separate Condition Types for Auto and Manual Pricing as this provides better control [who can update price] and visibility[reporting becomes easy]. I have done that in many assignments.

EVERYONE who is contributing to this discussion:

The point raised by Kumar seems to be related to when/during the Sales Order being created and not after it is created.


Technically, you can see the Original Condition Record in the Pricing Analysis details and the changed Price in the Initial Condition Tab screen but that is a pretty unsatisfactory way of doing that.

Once you save the order at that time, the Environment > Change Area does not capture this.

Kumar:


Some pointer to have the Auto Price and Changed Price visible during the transaction creation is to have a copy of PR00 which is only Manual and then have Condition Exclusion Logic Built in and kick in where Manual Price is input. That way you have both situations visible with the Auto Condition Inactivated when Manual is present. This way, as Jelena points out there will be no issues and users will be at peace.

Further, I am sure you must be aware how to access when the Price is changed after the Sales Order is created. Either way, I will just sum them up for you.

If we just want to check if there has been any Price Change - Manually in the transaction after it is saved it can be done in the following way.

1) In the Sales Order : Environment > Changes  [as articulated by Lakshmipathy]

OR

2) In VBAP-MPROK Manual Price Change Indicator check on but no comparison between Original and Changed Price

3) As indicated in the 3rd Paragraph

I am sure there are other ways to like in KONV and something which Phani pointed out.

Hope this helps.

Thanks.

Former Member
0 Kudos

Dear Dee sea,

Thanks for your reply,

U r correct, during the sale order creation, i need to check does the line item price (PR00) was modified OR same as price master. Based on this i need to deacivate discount condition type (RA00).

during runtime i tried using the structure konv , komp but i couldnt identify any flag or indicator.

thanks for help.

former_member205178
Contributor
0 Kudos

Hi,

For this the way, I look at your solution options are :

OPTION # I:

Step # 1: Have a Condition Exclusion, as I had pointed out in the earlier reply - PR00 Auto and ZPR0 Manual.

Step # 2: Create another one with RA00 and ZPR0 where ZPR0 becomes Exclusive when it is active and RA00 is deactivated.

OPTION # 2:


I do not know if this is technically feasible at all or if it is how easy it is but here is how you can try your solution.

Have a requirement attached to RA00 which checks if PR00 Condition Type has KOMV-KMPRS is checked ON and deactivates RA00. Of course this is a Structure and hopefully your ABAP Resource can help.

OPTION # 3:


I do not know, if there is technically feasible at all or if it is how easy it is but here is how you can try your solution.

A combination of Option # 1 and Option # 2, where you have Condition Exclusion between PR00 and ZPR0.

In RA00, have a requirement which checks if ZPR0 is present in Pricing and deactivates RA00.

Hope this helps. 

Thanks.

former_member182378
Active Contributor
0 Kudos

Jelena,

As a matter of fact, in our organization we had ZPR0 condition that was both manual and automatic and it caused nothing but trouble. We changed it and had no issues since.

What kind of issues did your company face?

I think that one pricing condition type would be sufficient to have the price populate from the condition records and if needed, occasionally this could be changed by the user; in the sales order.

former_member205178
Contributor
0 Kudos

Hi Kumar,

Sorry for hijacking the discussion.

Apologies to Jelena and TW.

Let me just guess this for kicks sake

1) REPORTING: You will not know what is the recommended price[read Auto Price] for a particular transaction;

2) AUTHORIZATIONS: You will not have an idea who changed it. This of course can happen with other Condition Types too ;

3) MSRP: Lower MSRP messes with the Profitability big time. If you already have discounts built in and if they do not have any check on what is the MSRP being played around with it, it hits the bottom line for the transaction;

4) COPA: Profitability gets impacted directly in COPA;

5) SALES Vs. FINANCE: This is a classic hot button issue between Sales and Finance because of the points 3 & 4 mentioned above.

Let us see on how many points I am spot on.

Thanks.

Jelena
Active Contributor
0 Kudos

@TW: when we had a condition as both manual and condition-driven not a week would go buy without someone screaming "where did this price come from?!!!". It was very difficult to pinpoint what was changed by the user and what the right price should've been. As pointed out above, when an order is changed, at least we have a change document (and even then the users would claim "the system did it"). But during the order creation it is virtually impossible to tell whether the price came from the condition records or was changed by a user. Since we were also SOX compliant at the time, it caused creation of additional reports and tasks, etc. Now it's very clear - if it's condition X then it's set by the user, otherwise it's set by the system. The management only needs to watch for conditions X, not all the orders.

There is no indicator available for such change, the best shot at any comparison would be before saving to practically run the price determination again for every item and then compare the determined price with the actual net value. This is inefficient, to say the least.

phanikumar_v3
Active Contributor
0 Kudos

Dear Jelena,

We can see the price changes even in Net value or item value--by going to VA03--Enter the number (Dont press enter)Just go to environment--Changes--Select the time of change and Additional info--here you can have the old and new values time wise/Userwise by double click on date.

I had the same issue in my Client level and get it clarified later.

Phanikumar

Jelena
Active Contributor
0 Kudos

Phanikumar V wrote:

We can see the price changes even in Net value or item value--by going to VA03--Enter the number (Dont press enter)Just go to environment--Changes--Select the time of change and Additional info--here you can have the old and new values time wise/Userwise by double click on date.

Yes, these are called the change documents. It's already mentioned above that the change documents don't capture changes made while creating the order (because it's not a change transaction, it's creation). Also these won't capture how the price was changed - e.g. whether the user typed in a different price or it was redetermined because of a condition change or any other change that influenced pricing.

keyur_mistry1
Active Participant
0 Kudos

Kumar,

I also don't know how to check. Have desire to know this.

But we can prevent this.

We can put this condition type control as manual entry not possible.

Or else if you have configured Credit Mgmt then we can put this PR00 as a critical field. So that, if a user will change this PR00 amount then that sales order will get blocked.

phanikumar_v3
Active Contributor
0 Kudos

"""komp-cepok , komp-mprok """"--KOMP is a structure.

How you checked?

Phanikumar

Lakshmipathi
Active Contributor
0 Kudos

If you want to check the changes happened in sale order, you can very well check from top menu bar "Environment > Changes".  On the other hand, if you want to check the pricing master record, execute V/LD, select the combination for which pricing condition record is maintained where system will show different prices with different validity periods.

G. Lakshmipathi

former_member205178
Contributor
0 Kudos

Hi,

Can you clarify a little more on this ?

Are you looking for some variable or field or indicator, during the Pricing Calculation process of the Sales Order Program where you want to identify if this is a Auto OR Manually Input Price OR is there something else you are looking ?

Else, is this something of a report requirement and you want to capture the Original and Changed Prices easily to compare the changes ?

Thanks.