Skip to Content
-2

VPRS condition not higher then PR00

Aug 07 at 10:56 AM

113

avatar image

Hi,

I want to know how to customize in price price procedure or condition type that in condition type VPRS can not be higher then condition type PR00? Is posssible to control than one condition type can not be higher then other by value. I face problem that VPRS cost is in billing higher then Pr00 price. That is not ok. How to avoid this situation? solution with any routine in price procedure?

thnx for answer.

10 |10000 characters needed characters left characters exceeded

ok. Thanks.

br

0
* Please Login or Register to Answer, Follow or Comment.

2 Answers

Jelena Perfiljeva
Aug 07 at 07:59 PM
1

I opened Google and typed in: VPRS must be lower than net site:sap.com

This was the top link, it's an answered question: https://archive.sap.com/discussions/thread/2017837

Show 2 Share
10 |10000 characters needed characters left characters exceeded

Yes this is a solution, thank you Jelena for link.

0

Thanks Jelena for answer and link. it work fine. Thanks you. BR

0
Uros Troha Aug 09 at 12:06 PM
0

Hi yes this setting routine 5 on condition VPRS in price procedure work fine on Sales order. i got message "Contribution margin for item 000001 is too low" and order is incomplete.

But we have situation that in sales order VPRS (from MMR) is lower than net price PR00. At time of PGI on delivery we get costs from stock. Costs are higher than PR00. When we create invoice from delivery on VF01 sistem not trigger same message like in order. i want that this functionality will work same on creating invoice. please for help.

price-procedure-routine-5.png


Show 6 Share
10 |10000 characters needed characters left characters exceeded

Hello Uros,

The source of VPRS value for a Material in Sales Order and Invoice would be same - Moving Price or Standard Prince in Material. If you are using Moving Price, it may change with every new purchase / sales transaction.

However in your case, since the Sales Order was also blocked for Price being lower than cost, what is the need to block Invoice creation?

The goods have already left the premises and what would be the benefit of blocking the Invoice creation?

1

I agree with Jignesh. PGI is already completed, so the ship has sailed. If anything, in this scenario you'd have to stop the PGI too.

In real life, what will actually happen in this situation? The order was confirmed with specific price, then somehow you find that the cost is higher. So, now what? You're going to ask the customer for more money? Cancel the order? Either way the customer won't be happy, I suspect.

0

hi,

I need to tell that cost can be higher at PGI becouse of mistake on Production order (production order give product on stock) that someone type higher cost price. We face this problem many times. Cost was higher x100 becouse someone was type by mistakecost 200.000 eur insted of 200 eur. So also block PGI is alternative to block, or like i sad creation of invoice in vf01. I want to solve this situations because storno of all documents in process after is dificult. In other cases we have right costs that are not different order-invoice.

0
becouse someone was type by mistakecost 200.000 eur insted of 200 eur

Try to educate the users instead of implementing lot of unnecessary validations which will only affect the system performance.

1

In this case user training is needed and not system validation.

Apart from affecting system performance, this approach is million dollar solution or 10 dollar problem. Why would you like to implement this check in system, rather than educating the users?

Thanks,

1

It is impossible to catch all such human errors. You could work around this, e.g. see why exactly are the users making mistakes (inconvenient UI, source data not clear, etc.) and try to address those issues.

For example, once we had a problem that sales reps were making changes in the sales orders and constantly typing over the material description (some ladies had very long nails, apparently). So we simply made a config change to disable entry in that field. We did not try to block the result of a wrong entry, we simply prevented it. The same needs to happen in your situation.

2