How to Implement minimum Price check in Sale order and billing.
If client gives you a requirement that they have two prices. Invoice price and bottom price. End users should have access to enter manual discount within this limit e.g If invoice price is 100 and bottom price is 90, end user can enter discount only 10 or less. How to map this in standard configuration.
For this you have to follow these steps.
1. Create Pricing condition for bottom price ZBAS and maintain condition records in it for bottom price. Also add this condition in your pricing schema and tick static. Dont assign any account key with it.
2. Create a pricing routine with following logic. Take help of your ABAPER if you don’t know how to create pricing routine.
Logic of Routine:
- Assign any sub total variable from XWORKD to XWORKM to your credit amount. The amount you are transferring in FI or customers ledger.
- Compare bottom price condition value with this variable. This is the comparison of net price with bottom price. You can have your other requirements too like if you want to exclude some user or condition from this check you can exclude.
This logic will work against ZBAS condition.
IF it_komv-kwert > XWORKF.
komp-cepok = ‘B’.
This field KOMP-CEPOK will take this order to incomplete and change its status. This order can not be processed until you rectify its pricing issue.
You can modify this as per your own requirment. I have excluded my user SD-02 from this check and also If there is ZMON condition in sale order line item system will not run this bottom price check because ZMON condition is exclusively for discounts below bottom price.
3. Assign this routine to your manual discount condition types and ZBAS condition in pricing procedure in field Calculation type.
4. Ad field VBAP-CEPOK in your sale order line item incompletion log and assign to your order types in Incompletion log node in IMG.
5. Now maintain prcies as 100 invoice PR00 90 bottom ZBAS and enter discount 11 and system will put this order incomplete. Users are not able to process order untill some authorize person corrects its pricing.
6. This field CEPOK works only in sale order. If you want restrict users to enter manual discounts during creating billing in VF01 you can control this with SHD0. Condition fields can be put in display mode with SHD0 in VF01.
No comments 😯
Could be very useful as it covers many important topics e.g. routine, CalTyp, condition types, pricing procedure, incompletion log.
To further my learning I have few questions -
1. Please give a business example for this requirement (invoice price and bottom price)
2. In the pricing procedure: why ZBAS should be marked as statistical? why ZBAS should not have any account key?
3. For the routine in which program and in which userexit this code is being written?
4. In step 3, why condition type ZEDA (which is a manual condition type) the CalTyp is not assigned (i.e. 904)?
Side comment - I request you to write more of these blogs (real time requirements).
Thanks a lot TW for liking and giving your feedback. I feel always good to answer your questions because you always ask logical questions 🙂
1. A business example I can give is from my own company. In my company we sell electronics home appliances goods like TV, AC, Washing machine etc. We offer monthly sales policies to facilitate our customers and give them benefits as per their business volume. We give a policy that which customer ill buy Rs 500000 goods he will have 3% discount, for 800000 there will be 3.5% and for 1000000 discount will be 4%. This discount will be given on end of every month on meeting certain requirements e.g payment term, payment mode etc. This is one policy only. We offer many similar policies with different ways. If a material's invoice price is 100 and after deducting all discounts (on invoice and monthly) its price is 95 then it means if a customer buys goods on advance cash and meeting all requirments for discount then end user will enter discount in manual discount condition on invoice. For restricting this limit we maintain bottom price and invoice separately and we have implemented this minimum price check.
2. ZBAS should be marked statiscal because it has no impact on net value and we dont want to post it in accounting. This is static price maintained only for comparing invoice value and net value (Bottom price like in above example).
3. This code is not written in any user exit. This is simply written in pricing routine. This routine can be created in VOFM Tcode and in Formula > Condition Value. Then assign this routine in pricing schema.
4. ZEDA is not a manual condition in my pricing schema. In screenshot I didn't noticed this. The manual tick was by mistake. We have only ZBOK and ZBOP conditions as manual condition. Sorry for misunderstanding. You can assign this routine 904 to all discount conditions. The purpose of assigning is that system will check this routine if it is assigned against condition which we are using in schema.
Thanks once again and I will write some more real time business processes too very soon.
Thank you for your reply!
The above is just an example but would like to explore it little further.
The variable discount (3%, 3.5%, 4%) you give in retrospect (after a month), this is similar to rebate.
- How is the variable discount configured; meaning for Rs 500000 give 3% discount and so on?
- Has your business combined Terms of payment (X% discount when paid in 15 days, Y% discount when paid in 30 days) with giving discounts retrospect (after a month)?
In my company we have very competitive sales team 🙂 . U know what I mean. For meeting their silly requirements we cannot use rebate. Silly requirements are in SAP but if we see them as market situation they are also valid. Some of these requirements are
Discount will be given if there is advance cash received from customer. This advance cash is posted in SAP with A indicator.
There is no over due in case of some policies.
There are groups of customers and different policies for different groups.
Policy can be change during month.
There are also other checks which I am not able to remember at the moment.
For these purposes we have developed a Z application which checks all certain requirements and if a customer meets them it posts credit note using accruals. We have used BAPIs for automatically posting credit note with VA01 and VF01. End user runs Tcode ZPOLICY and give customer number, sale area, materials group and select policy radio button. System checks, calculate and show discount amount in ALV. End user verify it and post.
small doubt in this scenario exactly where we have to maintain that limited discount ex 10 percent
plz share where it will be maintained
We will not maintain that discount. We will maintain sale price and bottom price and difference of these prices will be discount margin which system will calculate automatically when user will enter discount.
One question - Why include incompletion log & VBAP-CEPOK in this solution? We have a rountine which does the calculation, if condition is not fulfilled, then let the routine itself populate the error.
Involving incompletion log will add to configuration. Further those many item categories for which this requirement is needed, incompletion (field) needs to be added.
Which Routine you are talking about??
Pl Let us know.
Phani, 904, see in screenshot of pricing procedure. TW
Thanks a lot for sharing this wonderful business scenario. I also would like to thanks to Mr. TW, who mostly discuss real time business scenarios.
It is nice effort however needs more clarity.
1) No logic provided regarding routin.
2) You are missing T-Codes & path throughout the blog.
3) While creating Z condition types like ZBAS, you have not mentioned which standard condition type you have copied?
4) No reference of condition type ZMON?
Please elaborate it more.
Your points are helpful but I would like to comment on points 2 and 3 -
2) A member working (preparing) in SD can find the t-code and path for most of the information provided in the blog e.g. condition type, pricing procedure, incompletion log etc.
If he/she involves in searching in SAP system or from internet, it would add to his/her learning.
3) ZBAS is a price condition type. If member compares PR00 and ZBAS, it would give an indication of (probably) copied from which condition type.
Furthermore ZBAS copied from which condition type is not that key, as the screen shot for ZBAS has been given.
Thank you for your pointers! 🙂
Thanks for your feedback and sorry of inconvenience. Actually it was my first document so I thought that Tcodes and path are very basic things for that person who is configuring this but I will mention Tcode and path in my next documents.
1, I have attached screenshot of routine so logic can be easily understandable. But yes, you are right. I missed one thing regarding logic. I will update it. Thanks.
2, I will mention Tcodes and paths in my next documents. As TW said I think V/06 and V/08 are common Tcodes for a person configuring this thing. But still i will mention in my next documents.
3, ZBAS is copy of my condition ZCOM and ZCOM is copy of PR00. I have changed them as per requirement that is why I have added screenshot.
4, As I said in my point # 2 that ZMON condition is discount condition and it is used only for discounts which are greater than this limit (Invoice price - Bottom price). If we have to give some material on Management's special approval we don't change ZBAS. We enter discount in ZMON condition and system don't check this in bottom price check. That is a business requirement. 🙂
Mashallah its really a good document presentation keep it up.
Thanks a lot brother. I would like to request you to please rate this document too 🙂
Logic has been added.
Good Efforts Moazzam keep it up.
The Courage guy shall take an action / initiative to create this type of Document .Drastically this will be reduced so much time who wants this type of scenario to make their system.
Nice worth Man..........Mind It.
Thanks Mr. Narendra. I will appreciate if you rate this document 🙂
Well said Naren...nice comment.
Dear MoazzaM Ali
Really a nice one...Keep it up!
Thanks Ashish 🙂
Great work, Keep it up in future as well.
This report helped me a lot.
I haven't done VOFM routine before, however your explanation can make it possible.
Thank you in advance.
I have one thing to inquire.
What if ZBAS condition is not maintained in condition master, how can I check bottom price? Can you give small guide?
A material - net price is 100 GBP(no discount), ZBAS is 110 GBP.
B material - net price is 100 GBP(no discount), ZBAS is not in condition master.
For material A, formula routine works well and it will show incompleteness error message.
While, material B how can I check bottom price is exceeded or not?
I try to tic ZBAS as mandatory condition but it seems not appropriate.
I will be great to hear answer from you.
Jin hyun Kang.
For running bottom price check or minimum pric check this is prerequisit that first minimum price has been maintained. If system don't know what is minimum price then system will not be able to compare it with net price.
If you can not maintain minimum price in condition record, you can calculate it with some predefined formula but if there is no ZBAS then no minimum price check.
I hope you understand.
My sales team wants to inform when 'ZBAS' condition is not maintained, so I
add a logic to check 'ZBAS' condition is exists in pricing procedure.
Before move on to logic, pleas note this.
My company uses same pricing procedure for 2 order type and for one of them it needs to be checked. So I couldn't make it as mandatory condition.
So I make a requirement routine -600 in VOFM. Then assign that to pricing procedure.
the logic works when I chase up debugging. (update KOMP-CEPOK = 'B')
However, sales order saved whether bottom price is greater or less.
As I check pricing analyzer, it says condition is ignored. (requirement 600 not fulfilled).
I also check log of incomplete, it has been assigned.
Where can i check further?
I concern this situation is different from what you did but if you had any relevant experiences or knowledge, please share with me.
Jin hyun Kang.
In my above document if bottom price ZBAS is greater or less then net value sale order is saved in both cases but the difference will be that if ZBAS is greater then it will be incomplete. Have you checked that your order is complete or not?
Make sure yu have added field VBAP-CEPOK in completion log and assigned this incompletion log to your item category.
If possible paste the complete coding you have done in 600 routine.
Thanks for posting.
Thank you dear 🙂
Thank you Srinivas for appreciating the document.
Thank you Tasneem Hamidi
Moazzam for you Tasneem Comments are of immense importance.............. 😉
Yes it is Mohsin Abbasi 🙂 Infact every one's is important for me.
yet another blog from the leader, thanks for sharing this document will be useful.
Thank you Sukant for these nice complement.
Thank you for sharing this document.Really useful document.nice effort.
Thank you for the compliments.
Informative & thanks for sharing.
I say it is a splendid document. Great work. Awaiting for more posts. 🙂
This is really nice to see this comment. Thank you and will share more.
Sincerely appreciate your effort and support. Thank you...!!!!
I also want to publish a document in ERP sales and distribution. How to publish. I have both screenshots and explanations in english. The screenshots are not getting pasted in the main body section when I click on " write a document ". Do I need to attach my word file and then will it come auotmatically in the main body section ?
You have to add screenshots using Insert image Icon which looks like a camera image and it is there on top of the text body. Copy paste the text from your .doc file and insert screen shots manually.
I tried to do this with standard and i am able to do without any enhancement for your requirement(if i understood your requirement correctly)
Note:i may be wrong but please see the steps i followed.
this requirement has been broken in the following way:
1.Maintain a price TR00(Invoice price)(Copy of PR00) in step 10 with subtotal--D
2.Maintain one more condition type (TBAS--Base price)(copy of pr00) in step 11 with statistical and subtotal E
3.Now these two condition types difference will be taken into separate step with statistical and alternate calculation formulae 12.
4.Now take one more condition type TDIS(discount condition type based on the difference amount of TR00 and TBAS with required from step Number.
5.Here the issue is ---user should not give the discount more than This difference value.for this maintain upper limit(as 1%---due to Minus sign) and lower limit as (100%- ).
So when user wants to give more than difference value--system will not allows with error.
Please see the screen shots below.
Sometimes there are several ways to do something. This is another approach to fulfill this requirement. I liked your approach and the way you did this. This is the reason I am here that we alway learn something new from here. Thank you for sharing this and keep up the good work.
' MoazzaM '
Nice blog MoazzaM and good tips from Phanikumar. For information, the other standard option is you can copy condition types EDI1 & EDI2. In standard, both Statistical and Manual check boxes would have been checked in pricing procedure. To automate the control on validating the price or value, you can remove the manual check box, maintain access sequence and condition record.
By doing so, when you create a sale order, system will give a warning message "no access sequences are permitted for this condition category". This you can eliminate by applying OSS note 175045 subject to the version you are working. If you are in ECC6, then system will take care of this and system wont give any warning message.
Also by having condition price and value, if either of this is not meeting the expectations, then, system will automatically go into incompletion log which you have to release it via V.25.
I learnt this tip by following your valuable suggestions in different threads.
So this credit goes to both of you only.(i am nothing here)
Needless to mention that service of both of you at SCN is priceless &
I pray GOD on behalf of you to continue the same in future too.
Thank you Phanikumar for best wishes and for being so kind. I saw some very good and remarkable posts from your side and I am sure that you are a valuable member of SD forum. Keep up the good work 🙂
Thank you for sharing another idea. I actually followed the same logic. I got this idea from a thread and I just changed the logic of routines that we assign with EDI condition. If I remember correctly EDI allows order only if selling price is equal to EDI price but I was looking for selling price greater than or equal to EDI. For this reason I had to change the logic of routine and I created my own.
Nice Document very informative
But in case where i want to have restriction on the basic price
like for example if now the price is maintained as Rs 40 in sales order but at the time of billing user want to increase the price by Rs 2 that will make it Rs 42 here system should restrict user to enter lesser price he may enter more price but restrict to enter lesser price can it be done with same logic ?
After reading your document and some of the posts, I think G Lakshmipathi
has made a valuable contribution by mentioning EDI1 and EDI2, standard condition types which can fulfill similar requirements.
Alt cal type 8, assigned to EDI2 computes difference between overall value minus EDI price, and allows this deviation upto a particular limit.
' MoazzaM '
Awesome Article. Nice flow esp with the Screenshots.
Keep it up! Awaiting more such gems.
good work bhai 🙂
Needless to say awesome document. Appreciate all your work.
I was going through your nice document and for my further understanding can you please advise me on my comment .... I think this requirement can also be satisfy by using Standard Condition Type PMIN with AltCty 15 (Minimum Price) and Req. Routine as 2.
Condition Record for this Condition Type PMIN can be maintained as per business requirement. As you rightly said once in your attached comments that there are multiple ways to do a single thing still wanted to check my understanding.
Hope to get more valuable documents in future from you !
I didnt check this in system. Have you check this? Is it working fine? If yes then I'll test this and yes you are that there are always multiple solutions of one requirement in SAP.
I shared this document so that I could learn from other user's ideas 🙂