Originally published 201-0-0 on blog.tlarsendataguy.com, and shared here with permission.
Despite my initial impression several years ago, I like SAP. Or rather, I have grown to like SAP. When utilized properly by the business, the wealth of data that becomes available for analysis and decision making is impressive. When combined with ACL’s DirectLink, we in the audit profession have easy access to volumes of data for our testing. Our testing becomes limited more by imagination and understanding rather than lack of data. Unfortunately, lack of understanding can be a significant limiter. SAP is a notoriously complex system, and it has to be for the environment it is expected to operate within. Within SAP, pricing, specifically sales pricing, is a notoriously complicated topic. This post and the next will strive to shed some light on SAP pricing and provide some strategies I have used for extracting pricing data quickly and efficiently.
To begin our journey, let’s start with configuration data. Pricing procedures are the objects in SAP which ultimately define the pricing of a sales document. The T683 and T683U tables contain the list and names of the pricing procedures defined in your implementation. To filter down to sales pricing, you will need to provide values for the usage and application fields. In my experience, these are procedures with usage ‘A’ (Pricing) and application ‘V’ (Sales/Distribution). In and of itself, this table is not very helpful. The magic starts in table T683V, which links sales organizations to specific pricing procedures. Let’s take a look at the key fields in this table and where the values come from.
The sales organization, distribution channel, and division are easy – these are defined directly in the header of sales documents (table VBAK). The document pricing procedure is associated with the document type. You can find this relationship in the TVAK table. The customer pricing procedure is defined in the customer master file; specifically, the KNVV table. A graphical presentation of these relationships is below. The key take-away is that all of the variables required to identify a pricing procedure for a sales document are contained in the VBAK table.
When a sales document is created in SAP, the following values are provided:
- Sales organization
- Distribution channel
- Division
- Sold To
- Document Type
SAP uses these values to look up the appropriate pricing procedure in the T683V table (you can see the pricing procedure SAP chose in the KALSM field of the VBAK table). As an example, assume a sales order is created with the following values:
- Sales organization ‘A001’
- Distribution Channel ’10’
- Division ’10’
- Sold To ‘100000’ has a customer pricing procedure of ‘A’
- Document Type ‘OR’ has a document pricing procedure of ‘B’
If the following pricing procedures are defined, SAP will select PRIPRO2:
From here, SAP looks up the detailed calculations for the pricing procedure in the T683S table. Every condition type that is allowed by the pricing procedure is defined in this table. In our example, PRIPRO2 might have the following values:
A quick synopsis of some of the fields I use is below:
- KSCHL – The condition type at the specified step number and counter. Once you know the pricing procedures you want to look at from T683V, you can pull the associated T683S records and summarize on this field to identify every condition type in your population.
- KAUTO – Identifies whether the condition type can only be entered manually. For example, use this to identify manual discounts in your data.
- KOBLI – Identifies whether the condition is mandatory. You might find this to be the case for conditions such as list prices. If a mandatory condition cannot be determined, the sales document cannot be completed. Non-mandatory conditions which cannot be determined are simply skipped when pricing is calculated.
Some conditions do not reference a condition type. I most commonly find these to be subtotal condition records. You can identify what is being subtotaled by referring to the STUNB (from step) and STUN2 (to step) fields.
At this point, we find ourselves with a new pricing object: condition types. The master and text tables for condition types are T685 and T685T. Continuing our example, let’s look at the values in T685 for condition type PR00 from our pricing procedure:
The field I use most commonly from T685 is the KOZGF field, which identifies the access sequence of a specific condition type. If the access sequence is blank, the condition value is entered manually; otherwise, SAP automatically calculates the value of the condition.
Access sequence master data can be found in table T682, but the important table for our purposes is T682I. T682I defines the condition tables that will be searched for each access sequence, as well as the order in which they will be searched. Condition tables are all of those tables between A000 and A999, which store the key, validity period, and a reference to the condition record in KONH. For example, assume access sequence ACS1 has the following data in T682I:
SAP will begin looking for a matching key in table A561 using data from the sales document (you can find the fields being searched in T682Z, but I am not going to spend any time explaining this table). If it finds a matching key, it will identify the corresponding condition record. If the access sequence is marked as exclusive, SAP will stop executing the access sequence and move to the next condition type. If the access sequence is not marked as exclusive, or if no matching key is found, SAP will move to table A408 to look for a match there, and again in A005*. The key SAP is looking for is defined in each condition table, and each condition table has a unique combination of fields that comprise the key. This design is what gives SAP’s pricing functionality such great flexibility. Furthermore, the ability to search in multiple tables per access sequence allows pricing departments to design schemes which meet their needs. Perhaps specific customers are to receive one set of prices, certain customer groups receive another set of prices, and everyone else receives a third set of prices. In this example, table 561 might link to customer-specific pricing, 408 might link to customer group pricing, and 005 would link to pricing for everyone else. The condition tables in the access sequence are thus listed in order from specific to general to ensure everyone receives the correct price. If a customer is neither a special customer, nor in a special customer group, SAP will fail to find a matching key in tables 561 and 408, but it should find a match in 005.
*SAP will identify all matching non-exclusive keys until it reaches the end of the access sequence or a match is found with an exclusive key. If no exclusive keys are found, the last non-exclusive key it finds becomes the active condition record.
Once a key match is found and a condition record identified, SAP calculates the price using data in the KONH, KONP, KONM, and KONW tables:
- KONH – Contains header-level data such as the source condition table, key, linked promotions, etc.
- KONP – Contains the data needed to calculate pricing, such as amounts, conversion fractions, unit of measures, etc.
- KONM – Contains quantity scale data. For example, if you offer special pricing when a customer purchases more than 50 units, that would be defined in this table.
- KONW – Contains value scale data. For example, if you offer special pricing when a customer purchases more than $2,000 USD, that would be defined in this table.
This process happens for each condition type defined in the pricing procedure and each item in the sales document. It’s a long and complicated process, but once you figure it out a strategy for extracting pricing data begins to emerge. In the next post I will discuss how I download pricing data to support revenue audits and perform continuous monitoring. To wrap up this post, I will leave you with a graphical summary of the pricing process in SAP:
Responses