There are many articles available on Pricing in SAP. In this article i particularly want to share my thoughts on what factors one should consider while designing the pricing structure in an implementation project.
As a beginner in SAP SD 5 years back, I had difficulty in understanding the pricing concept. Everyone use to explain the technical part but after doing many implementations as a SAP SD Consultant I feel it is must to have the logical understanding of this process. If we as consultants are clear on the basics, we can make the client understand the concept very easily and provide them a simple yet a very good solution.
Remember not every good solution has to be a complex one.
This article is especially for the Functional Consultants who have started their career in SAP. The following concept is applicable for pricing across modules such as SD, MM, TM, etc.
What is pricing? The first thing which comes in our mind is its complexity and if we land up discussing a very complex model in pricing with our client, we panic. So to make things simpler, I have listed down few basic things which you must think over before designing the pricing structure for your client.
First, we need to understand how the system works for pricing. It follows the top down approach in any transaction.
For easy understanding, I have taken an example of a pricing in sales orders. It takes the following approach.
1. The pricing procedure is determined.
2. The condition types in that pricing procedure is called for.
3. The access sequence for each condition type is read.
4. The best suitable access/condition table is selected in the access sequence with specific to general approach.
5. Based on the condition record as per the condition table, the price is populated.
I will not go into the detail about what the condition types or access sequences are. Many good articles explaining this are available on internet.
Following are the few suggestions which every consultant must keep in mind during an implementation project.
1. Follow the approach of key business scenarios and the different components involved in arriving at that pricing. For example if the domestic sale (example: India) involves excise duty plus tax and export sale involves excise duty (statistical) and no tax component, then we can either have two different pricing procedures or use routines to capture the differences. The ideal way is to have two different procedures if the component structures are very different so as to fit in the standard pricing instead of writing routines.
2. Avoid creating multiple pricing procedures unnecessarily. For example: if you want to apply 100% discount only on a free sample sales scenario to NGO and not in normal sales then use the routine or item category to calculate the same instead of having two different pricing procedures for different business scenario.
3. Use value lines to copy the condition types for effective further calculation in the pricing procedure
4. Use sub totals to capture the key figures required for reporting. Sap standard sales order and billing tables have 6 sub totals field which can be directly used for reporting.
5. Use of reference condition types in different pricing procedures to avoid duplication of the master data maintenance. For example in STO process: if you have basic price of a material in PO and want the same to be captured in SD billing, then just give the PO condition type as reference condition type in SD. This way you will avoid duplicating the master data.
6. Use variations in Document Pricing Procedure more than Customer Pricing Procedure as this will avoid the risk of wrong master data input. The lesser the CPP the better is chance of avoiding the mistake in master data maintenance.
7. Maintain the condition type in the pricing procedure determination configuration (OVKK) as the amount and value of the same populates at the line item level of sales orders. This comes in very handy for the users to check the value directly in the sales order main screen instead of checking the conditions tab for each and every line item.
8. Follow the specific to general approach while creating the access sequence. Do not forget to check the exclusive indicator in an access sequence to improve the system performance.
9. Use standard functionalities available to put in certain checks for the users to avoid wrong master data entry. For example: in order to avoid more than 100% discount you can set the upper limit as 100 in the discount condition type so that even if the users makes a mistake of entering more than 100% in condition record, the system won’t allow to do so.
10. Check whether the data is pulled from header table (KOMK) or item table (KOMP) in the access sequence if the condition record is not read even after maintaining the condition master.
These are only few things which I have noted among the many things to be considered while designing the pricing structure.
With experience, things always get better.
Please share your thoughts on this.
Regards,
Ruchika