In this article I will describe elements of “Pricing & Conditions” in SAP® module SD (Sales & Distribution). Pricing and conditions are an important topic for data analytics. Very often we do get questions like “What do I have to know regarding conditions in SAP®?” “How can I find out if conditions can be changed manually?” “In which tables do I find conditions master records and the transaction history for conditions?” Here I will explain which kinds of conditions exist and how they impact the pricing procedure, e.g. the calculation of the product net value.
The net value for the flat screens amounts 2407.30 Euro and is calculated based on the conditions “PR00” and “K007”. 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.
Some interesting settings from an analytic point of view could be:
- Manual entries: You define in this field whether a condition can be changed manually by the user.
- Header or item condition: You decide here whether the conditions can be changed on header or on item level.
- Plus/Minus: Is the condition a positive (surcharge) or a negative (discount) value or are both amounts possible?
- Calculation type: Is the condition a percentage, a fixed amount or a quantity?
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:
- Sales area (sales organization, distribution channel, division)
- Document type
- Customer master data
The assignment is defined in the customizing.
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).
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.
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.
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 “conditions” (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.
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.
T683S: Pricing scheme
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.
In this article I have given you a first insight into the topic “conditions” 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, please contact me under the email address firstname.lastname@example.org anytime.