SAP Sales Pricing Data 1

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.

010_01

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.

010_02

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:

010_05

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:

010_06

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:

010_07

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:

010_03

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:

010_04

Advertisements

5 thoughts on “SAP Sales Pricing Data 1

  1. Great information on SAP sales tables, Tom. Thanks for all of the detailed information. I haven’t had a chance to look at our sales data yet. What types of analytics are you running against sales data?

    Like

    1. Hey Chris,

      On a continuous basis, we are running some analytics that identify when new freight pricing conditions are created. This should happen rarely and it provides a tool the business can use to detect inappropriate changes to freight pricing. We also detect list pricing conditions with a validity exceeding 1 year; our processes dictate that list prices should be updated every year.

      More interestingly, we recently used this data to support a pricing audit of one of our businesses. All of our list prices are supposed to be approved, so we were able to bump up SAP data against the approved list and identify incorrect list prices. We were also able validate that standard discounts were entered correctly into the system. The wealth of data allowed us to not only identify exceptions, but also to validate that the business was actually doing a pretty good job of managing pricing.

      I will go in a bit more detail about this in the next post.

      Like

  2. Hi Tom,

    This post has wealth of information, thanks much for sharing. I like the way you explained how tables interact in backend for sales pricing. My only question is, if I want to identify such interaction of tables in other areas, such as sales cut off, where can I get this information for standard SAP configuration?

    Thanks again.

    Like

    1. Hi Sujay,

      I am glad you found the information helpful.

      I am not sure I can give you great recommendations for finding information about other areas. Most of my research is done using a combination of Googling, experimenting with the related T-Codes, exploring the data using either SE16N or ACL, and reaching out to IT for more advanced or company-specific questions. If you are looking for sales cutoff, some relevant tables might be the tables for billing documents (VBRK and VBRP), shipments (VTTK and VTTP), deliveries (LIKP and LIPS), and sales document flow (VBFA). A common configuration is for invoices and shipments to be tied to a delivery document, so you could do cutoff testing by linking the billing document to the shipment via the delivery doc and then comparing the relevant dates. But this depends a bit on how your specific instance of SAP is configured.

      Like

  3. I’ve used ST05 to provide a trace. Definitely not user-friendly when you’re reading the results, but sometimes it gives me a starting point. If the trace indicates that the data is stored in a structure, I have to go to IT to identify the base tables.

    TCode: ST05

    Description: Trace: Find tables and fields that are hit during a particular transaction

    Details:

    SAP updates data into multiple tables and also fetches data from multiple tables in a particular screen of a transaction.

    Run the Trace to find the list of tables hit and the corresponding fields.

    The TCode to check the trace is ST05

    Procedure for TRACE ANALYSIS:

    1) Go to ST05
    2) Activate Trace
    3) In another screen run the transaction for which you want to find the fields from tables.
    4) Deactivate Trace in ST05
    5) Display the Trace in ST05. Here you will see all the database hits.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s