5.1 Condition Technique Architecture: Field Catalogs, Tables, and Access Sequences

Condition Technique Architecture: Field Catalogs, Tables, and Access Sequences

In SAP S/4HANA Sales and Distribution, pricing is not a hardcoded calculation or a static lookup table. Instead, it is governed by the Condition Technique—one of the most sophisticated, flexible, and powerful architectural frameworks within the entire SAP enterprise core.

While the Condition Technique is primarily recognized as the calculation engine for customer prices, discounts, surcharges, and taxes in SD, SAP applies this exact same architectural paradigm across multiple functional areas:

• Sales Pricing (SD-MD-PR / SD-BF-PR)
• Purchasing Pricing (MM-PUR)
• Output Determination in the classic NAST framework (SAP S/4HANA Output Management uses BRFplus decision tables instead, section 9.6)
• Revenue Account Determination (SD-BF-ACT)
• Material Determination (SD-MD-MM)
• Listing and Exclusion (SD-MD-LE)
• Text Determination (SD-BF-TP)

Mastering the structural components, execution logic, and configuration mechanics of the Condition Technique is essential for any SAP S/4HANA sales professional.

---

The Four Fundamental Building Blocks

The Condition Technique operates through four interdependent conceptual layers that bridge transactional runtime data with persisted pricing master data:

+-------------------------------------------------------------------------+
|                           1. Field Catalog                              |
|        (Communication Structures: KOMK Header & KOMP Line Item)         |
+-------------------------------------------------------------------------+
                                     │
                                     ▼
+-------------------------------------------------------------------------+
|                          2. Condition Tables                            |
|     (Key Combinations: e.g., Table 005 Customer/Material, Table 004)    |
+-------------------------------------------------------------------------+
                                     │
                                     ▼
+-------------------------------------------------------------------------+
|                         3. Access Sequences                             |
|      (Search Strategies: Ordered Tables from Most to Least Specific)     |
+-------------------------------------------------------------------------+
                                     │
                                     ▼
+-------------------------------------------------------------------------+
|                          4. Condition Types                             |
|       (Pricing Elements: PR00 Base Price, K004 Material Discount)       |
+-------------------------------------------------------------------------+

---

1. The Field Catalog and Communication Structures (KOMK & KOMP)

At runtime, when a sales order is created or changed (transaction VA01 / VA02 or the SAP Fiori app Create Sales Orders), the pricing engine needs access to document attributes—such as the Sold-to Party, Ship-to Party, Sales Organization, Distribution Channel, Incoterms, Material Number, Plant, and Item Category.

However, the pricing engine does not read directly from sales document database tables like VBAK (Sales Document Header) or VBAP (Sales Document Item). Instead, SAP decouples the pricing engine from transactional tables using Communication Structures:

• KOMK: Pricing Communication Header. Populated with header-level attributes such as VKORG (Sales Org), VTWEG (Dist Channel), SPART (Division), KUNNR (Sold-to Party), INCO1 (Incoterms 1), and PRSDT (Pricing Date).
• KOMP: Pricing Communication Item. Populated with item-level attributes such as MATNR (Material Number), WERKS (Plant), PRCTR (Profit Center), PSTYV (Item Category), VRKME (Sales Unit), and KWMENG (Order Quantity).

The collection of all fields available in KOMK and KOMP constitutes the Field Catalog.

Adding Custom Fields to the Field Catalog

When an enterprise needs a pricing key that is not in the standard catalog of allowed fields, SAP provides a release-neutral procedure, documented in Customizing under Sales and Distribution → System Modifications → Create New Fields Using Condition Technique:

1. Append Structure: Add the field to the header or item pricing communication structure through the customer includes KOMKAZ (header) or KOMPAZ (item).
2. Field Catalog Registration: Add the new field to the list of allowed fields for condition tables (Customizing activity Conditions: Allowed Fields, table T681F).
3. Populate the Field at Runtime: Fill the field in the pricing user exits USEREXIT_PRICING_PREPARE_TKOMK (header) and USEREXIT_PRICING_PREPARE_TKOMP (item). For sales documents these routines are in include MV45AFZZ; for billing documents they are in RV60AFZZ.
4. Use the Field: Create a condition table that contains it (V/03) and include that table in an access sequence.

---

2. Condition Tables: Defining Key Combinations

A Condition Table defines the combination of business fields that form the primary key for a pricing master record. For example, an organization may offer special base prices to a specific customer for a specific material, or broad base prices applicable to any customer purchasing that material.

• Table Number Ranges:
  • 001 to 500: Reserved strictly for standard SAP delivery (e.g., Table 004 = Material, Table 005 = Customer/Material, Table 305 = Customer/Material with release status).
  • 501 to 999: Reserved for customer-specific condition tables created by functional consultants.
• Customizing Transactions:
  • V/03: Create Condition Table
  • V/04: Change Condition Table
  • V/05: Display Condition Table

Physical Database Generation (Axxx)

When a condition table is activated in transaction V/03, the ABAP Data Dictionary automatically generates a physical database table named A + Table Number:

• Condition Table 004 $\rightarrow$ Physical database table A004
• Condition Table 005 $\rightarrow$ Physical database table A005
• Condition Table 501 $\rightarrow$ Physical database table A501

The physical table contains:

1. The chosen key fields (e.g., KUNNR, MATNR, VKORG, VTWEG).
2. The validity dates: DATAB (Valid-From Date) and DATBI (Valid-To Date).
3. The Condition Record Number (KNUMH): A 10-digit unique internal key.

The KNUMH key links the condition table entry directly to the condition data tables:

• KONH: Condition Header (validity, text, scale definition).
• KONP: Condition Item (stores the actual pricing rate KBETR, currency KONWA, condition pricing unit KPEIN, and unit of measure KMEIN).

[ Table A005 (Customer/Material) ]
  Key: VKORG=1000, VTWEG=10, KUNNR=0001000050, MATNR=M-01
  Validity: DATAB=2026-01-01, DATBI=2026-12-31
  Record Pointer: KNUMH = 0000045812
                     │
                     ▼
[ Table KONP (Condition Item) ]
  KNUMH = 0000045812
  Rate (KBETR) = \$85.00
  Condition Currency (KONWA) = USD
  Pricing Unit (KPEIN) = 1
  Unit of Measure (KMEIN) = EA

---

3. Access Sequences: Prioritized Search Strategies

An Access Sequence is a cross-table search strategy that instructs the pricing engine how and where to search for valid condition records. Configured in transaction V/07 (database table T682), an access sequence consists of an ordered sequence of condition tables evaluated in step-by-step succession.

Search Philosophy: Most Specific to Least Specific

Best practice in SAP pricing architecture requires structuring access sequences in a hierarchical funnel, beginning with the most restrictive, highly specific commercial agreement and falling back to broader, generic list prices:

In this hierarchy:

1. Step 10 checks if a custom price agreement exists specifically for this customer and material.
2. Step 20 checks if the customer is assigned to a wholesale or retail Price List.
3. Step 30 falls back to the universal base list price for the material.

The "Exclusive" Indicator

The Exclusive indicator (checkbox in transaction V/07) is the single most critical flow-control switch in an access sequence:

• If Checked [X] (Standard Behavior): When the pricing engine evaluates a step and finds a valid condition record, it immediately stops searching further tables in that access sequence. The rate found is adopted, and steps with higher step numbers are bypassed.
• If Unchecked [ ]: Even if a valid record is found at Step 10, the engine continues with Step 20, Step 30, and so on, so several records of the same condition type can be found for the item. Price conditions are normally exclusive for exactly this reason.

Requirement Routines at the Access Step Level

Each step in an access sequence can be assigned a Requirement (a 2- or 3-digit ABAP routine configured in VOFM). Before the pricing engine queries the database table for a step, it evaluates the requirement routine:

• If the routine returns SY-SUBRC = 0 (True), the database search executes.
• If the routine returns SY-SUBRC <> 0 (False), the entire step is skipped without executing a database SQL query.

For example, an access step targeting Table 006 (Price List) can be gated by a requirement that verifies whether KOMK-PLTYP (Price List Type) is populated. If the customer master has no price list assigned, the system skips Step 20 entirely, avoiding an unnecessary database read and improving document processing performance.

Alternative Source Fields

Within each access, a condition table field can be filled from a different document field, the source field. The official course gives three examples: material or pricing material, document currency or local currency, and sold-to party or ship-to party. The standard access sequence of PR00 has a third access that runs only if requirement 3 is fulfilled (the document currency is not the local currency); it repeats the price list access with the local currency as source field. Restriction-dependent accesses like this avoid unnecessary database reads.

Key Fields and Fast Entry

When you create a condition table, its key fields must appear at the top. For each field you also decide whether it appears in the header or in the item part of the fast entry screen generated for maintaining condition records.

---

4. Condition Types: The Pricing Elements

The Condition Type represents a discrete commercial pricing element in the business transaction. Examples include:

• PR00: Standard Base Price
• K004: Material Discount
• K005: Customer/Material Discount
• K007: Customer Discount
• KF00: Freight Surcharge
• MWST: Output Value-Added Tax
• VPRS: Internal Material Cost

Condition types define calculation behavior (percentage, fixed amount, quantity scale) and point to an assigned Access Sequence. (Condition types are explored in depth in Section 5.2).

---

Condition Record Maintenance (VK11 / VK12 / VK13)

Pricing condition records are commercial master data maintained by business users rather than configuration transported by technical teams:

• VK11: Create Condition Record
• VK12: Change Condition Record
• VK13: Display Condition Record
• VK14: Create with Template (copy an existing record with a new validity period, rate, or other data)
• VK31 / VK32: Mass Maintenance of Condition Records

Key Combination Selection

When initiating transaction VK11 for a condition type (such as PR00), the system displays a pop-up dialog prompting the user to select the Key Combination. Each radio button in this dialog corresponds directly to one of the condition tables assigned in that condition type's access sequence:

+-------------------------------------------------------------+
| Key Combination Pop-up (VK11 - PR00)                        |
+-------------------------------------------------------------+
| ( ) Customer / Material               --> (Table 005)       |
| ( ) Price List / Currency / Material  --> (Table 006)       |
| (•) Material                          --> (Table 004)       |
+-------------------------------------------------------------+

Validity Periods and Pricing Dates

Every condition record possesses explicit validity boundaries:

• Valid-From Date (DATAB)
• Valid-To Date (DATBI) (defaults to 9999-12-31)

During sales document entry, the system evaluates the pricing date of the document item (stored with the business data, VBKD-PRSDT), which is proposed from the creation date or the requested delivery date depending on the sales document type. A condition record is selected only if:

$$\text{DATAB} \le \text{Pricing Date} \le \text{DATBI}$$

This architecture permits commercial managers to forward-date upcoming price adjustments months in advance. On January 1st, new rates become active automatically without system downtime or emergency maintenance.

Deletion Flags vs. Validity Date Expiration

To retire a condition record in VK12, business users have two choices:

1. Shorten the Validity Period: Set DATBI to yesterday's date. This preserves historical pricing auditability for past sales orders while blocking new orders from picking up the rate.
2. Set the Deletion Indicator (LOEVM_KO): Flags the physical record in table KONP for deletion. The record remains visible in VK13 if display options allow, but the pricing engine completely ignores it.

---

Structural Summary of Building Blocks