SD Pricing Part 2: Condition Tables and Access Sequences — How SAP Finds a Price

📌 KEY POINTS
✅ A condition table defines a key combination (e.g. sales org + channel + customer + material) built from the pricing field catalog.
✅ An access sequence lists condition tables in search order — from most specific (customer/material) to most general (material).
✅ The "exclusive" indicator stops the search when a record is found; without it, the system continues and may find more records.
✅ Access requirements (routines) can skip an access when conditions are not met (e.g. only for export).
⚠️ Too many accesses or badly ordered tables slow pricing and make results hard to explain.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 1 showed the chain. Now the price-finding mechanics.

━━━━━━━━━━━━━━━━━━━━
▶ 1. CONDITION TABLES

• Created in V/03 from fields of the field catalog (KOMG).
• Custom tables numbered 501–999; standard examples A004/A304 (material), A005/A305 (customer/material).
• Fields in the key must exist in the pricing communication structures (KOMK header, KOMP item).

━━━━━━━━━━━━━━━━━━━━
▶ 2. FIELD CATALOG

• Adding new fields (e.g. customer group 5) requires extension of KOMK/KOMP and filling them in user exits/BAdIs.
• Plan fields carefully — every table and access depends on them.

━━━━━━━━━━━━━━━━━━━━
▶ 3. ACCESS SEQUENCES

• V/07: access number, table, requirement, exclusive flag.
• Field mapping from document fields to table fields (e.g. ship-to vs sold-to as customer).

━━━━━━━━━━━━━━━━━━━━
▶ 4. SEARCH ORDER

• Specific → general: customer/material, price list/material, material.
• Exclusive: stop at first found; typical for prices.
• Non-exclusive: collect several records (e.g. multiple discount levels).

━━━━━━━━━━━━━━━━━━━━
▶ 5. PERFORMANCE AND DESIGN

• Fewer, well-designed tables beat many narrow ones.
• Use the pre-step/access requirements sparingly.
• Each table needs business ownership of its records.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

1. Identify the business price levels (customer-specific, list price, base price).
2. Map each level to a condition table.
3. Build the access sequence specific → general, exclusive for prices.
4. Assign the access sequence to the condition type (Part 3).
5. Test with records at each level and check the analysis.

✅ CHECKPOINT: pricing analysis shows the search stopping at the most specific record found.

A client had an access sequence with 14 accesses for its main price, many added over years for special cases. Pricing a 300-line order took several seconds per item and nobody could explain which record would win. The team analysed record usage: 9 tables had fewer than 20 active records. They consolidated into 4 tables, moved special cases into a separate discount condition type, and documented the price hierarchy. Pricing time dropped sharply and the price hierarchy became explainable to sales.

• Ordering accesses from general to specific.
• Forgetting the exclusive flag on price accesses.
• Adding tables for every special case.
• Adding fields to tables without filling them in the communication structures.
• Mapping the wrong partner (sold-to vs ship-to) into table fields.

• Design price hierarchies with business before building tables.
• Keep access sequences short and ordered specific → general.
• Use exclusive for prices, non-exclusive only deliberately.
• Review table usage periodically.
• Document field mapping per access.

Questions: "What is an access sequence?", "What does the exclusive indicator do?", "How do you add a new field to pricing?"
Strong answer: condition tables as key combinations from the field catalog; access sequence searches tables in order specific → general; exclusive stops after first hit; access requirements skip accesses; new fields need field catalog and KOMK/KOMP extension plus filling in exits/BAdIs.