Figure 1: A high-level pricing scheme and its conditions<\/p>\n
The complete table represents an abstract, high-level \u201cpricing scheme\u201d. Which pricing scheme will be applied, this will depend on the material\/product, the customer or a combination of material and customer. Each line in the pricing scheme represents a condition: The price is a condition on its own, the rebate is a condition on its own, etc. In SAP conditions are represented by \u201ccondition types\u201d:<\/p>\n
Several conditions with a different type can exist within a calculation scheme per order item. For instance, the net value of an order item can be calculated from the following condition types:<\/p>\n
- \n
- Basis price: This corresponds to the list price which is created in the SAP transaction VK11. The list price can be valid either on material\/customer level or on material level.<\/li>\n
- Customer discount: In many cases, a price reduction of the list price is granted to the customer.<\/li>\n<\/ul>\n
You define in the calculation scheme which conditions are a) valid and b) needed for the calculation of the sales price.<\/p>\n
As an example, the conditions in sales order 12075 are shown, displayed with SAP transaction VA03. It represents the calculation scheme for one sales order line, which contains two flat screen monitors. The scheme consists of four different conditions (pricing elements):<\/p>\n
- \n
- PR00: Standard Price<\/li>\n
- K007: Customer discount<\/li>\n
- AZWR: Down Payment<\/li>\n
- MMWST: Output Tax<\/li>\n<\/ul>\n
![](\"https:\/\/www.dab-europe.com\/\/wp-content\/uploads\/Publ\/cD\/20140710_SAP_Conditions_D_01.png\")
<\/p>\nThe net value for the flat screens amounts 2407.30 Euro and is calculated based on the conditions \u201cPR00\u201d and \u201cK007\u201d. The output tax is not included in the net value of the sales order item because it only gets relevant when the SD invoice is created. The cash will get relevant at that moment in time when the invoice is cleared.<\/p>\n
Condition types<\/h2>\n
The shortcuts PR00, K007 etc. are called \u201ccondition types\u201d. They are used in SAP SD to identify a condition uniquely. In order to create conditions the corresponding condition types must exist. They are important because they define the general properties of conditions as well as the calculation types. The most important calculation types are:<\/p>\n
- \n
- Percentage (e. g. discount)<\/li>\n
- Fixed price (e. g. minimum order quantity)<\/li>\n
- Quantity dependent (e. g. material) The condition types are maintained in the SAP customizing.<\/li>\n<\/ul>\n
The following example will show which information can be given in the customizing:<\/p>\n
![](\"https:\/\/www.dab-europe.com\/\/wp-content\/uploads\/Publ\/cD\/20140710_SAP_Conditions_D_02.png\")
Some interesting settings from an analytic point of view could be:\u00a0<\/p>\n- \n
- Manual entries: You define in this field whether a condition can be changed manually by the user.<\/li>\n
- Header or item condition: You decide here whether the conditions can be changed on header or on item level.<\/li>\n
- Plus\/Minus: Is the condition a positive (surcharge) or a negative (discount) value or are both amounts possible?<\/li>\n
- Calculation type: Is the condition a percentage, a fixed amount or a quantity?<\/li>\n<\/ul>\n
Condition master data<\/h2>\n
While the condition type describes the general properties of a condition, the condition master record contains\u00a0<\/p>\n
- \n
- The actual value<\/li>\n
- Based on a certain level (Material level, Customer level, Material\/Customer level etc.)<\/li>\n<\/ul>\n
This chapter illustrates how condition master data can be maintained. As example we take the condition type PR00 of order number 12075 which has a value of 1,267.00 Euros (see above). The condition master data can be displayed in transaction VK13. After the entry of the condition type, you are prompted to select the key combination. For this condition type, three levels are defined in the customizing on which the price can be defined.<\/p>\n
![](\"https:\/\/www.dab-europe.com\/\/wp-content\/uploads\/Publ\/cD\/20140710_SAP_Conditions_D_03.png\")
<\/p>\nThis \u201ckey combination\u201d allows making a general price on the material, but having a differentiated price depending on which customer it is.<\/p>\n
After the selection of the combination and the entry of the parameters we get the following result:<\/p>\n
![](\"https:\/\/www.dab-europe.com\/\/wp-content\/uploads\/Publ\/cD\/20140710_SAP_Conditions_D_04.png\")
<\/p>\nPricing scheme<\/h2>\n
In SAP different pricing schemes can be defined. The idea is that in that scheme is defined which condition types are allowed\/can be applied. Which calculation scheme is selected in the sales order, depends on the following parameters:<\/p>\n
- \n
- Sales area (sales organization, distribution channel, division)<\/li>\n
- Document type<\/li>\n
- Customer master data<\/li>\n<\/ul>\n
The assignment is defined in the customizing.<\/p>\n
Relevant tables<\/h2>\n
There are a lot of important tables which contain information about pricing & conditions in SAP. Two important ones will be explained here, KONH\/KONP (Conditions Master Data Item) and KONV (Condition Transaction Data).<\/p>\n
SAP differs between master data and transaction, because on one hand it has to store the predefined set as shown above; on the other hand it is possible to change conditions within a sales order or SD invoice. This means, it is not enough to store the master data, SAP also needs to keep track of which conditions (and which actual values) actually have been applied in each SD sales order \/ SD invoice.<\/p>\n
KONH\/KONP: All condition master data is stored in this table. Each condition is stored under a unique number on item level. In KONH you have the information how long a condition is valid.<\/p>\n
KONV: In this table, all used conditions and their values are listed for each order item. This means that all data records are stored which are listed in the slide \u201cconditions\u201d (see example from figure 1). Therefore the table is very big from experience. The reason why the table not only refers to condition master data but the data are also stored redundantly is that the calculated values are listed and on the other hand the condition can be changed while creating the order. In many cases (e. g. discount) no data record was created in table KONP but the user has entered the condition value manually. In such cases it is about a manual condition. I would like to point out again that a master data record does not have to exist for each condition type. Prerequisite is that a condition type was defined in the customizing which has the required properties.<\/p>\n
In table KONV the used conditions in the SD billing documents are also included. When an invoice is created from an order, the conditions are copied and stored under a new document condition number.<\/p>\n
T683S: Pricing scheme<\/p>\n
Here it is listed, which condition types can be used for a certain pricing scheme. This table is the basis for the price calculation in a sales order.<\/p>\n
Conclusion<\/h2>\n
In this article I have given you a first insight into the topic \u201cconditions\u201d and I have explained how conditions are maintained and used in the sales orders. Due to the complexity of the topic only a small aspect could be covered. Important components for an efficient pricing are the calculation scheme and the access sequence. These aspects and corresponding analyses cannot be handled here because there are lots of complex scenarios which need to be looked at in detail. If you have more detailed questions, don’t hesitate to contact us!<\/p>\n\n\n