You are debugging a Variant Configuration model. A characteristic value shows up wrong. A dependency won't fire. A configuration profile behaves differently than expected.
Knowing which table stores what can cut diagnosis time from hours to minutes.
This guide maps the key tables behind VC, how they connect, and the queries that consultants use in real projects.
Source: SAP Note 558853 | help.sap.com Variant Configuration
The Table Map
VC data lives across six logical layers. Each layer has its own set of tables, and knowing which layer a problem belongs to is half the diagnosis.
| Layer | Key Tables | What It Stores |
|---|---|---|
| Material Master | MARA, MARC, MAKT | Material header data, plant data, descriptions |
| Characteristic Master | CABN, CAWN, CABNT, CAWNT | Characteristic definitions, allowed values, texts |
| Classification | KLAH, KSML, KSSK, AUSP, INOB | Class hierarchy, char-to-class assignments, object-to-class links, char values |
| Config Profile | CUCO, CUOB, CUEX, CUKB, CUKN | Profile header, dependency assignments, compiled source code, administrative data |
| BOM | MAST, STPO, KDST | Material-to-BOM links, BOM item data, configurable BOM links |
| Config Storage | IBIB, IBIN, IBST, IBSYMBOL, IBSTREF, IBINVALUES | Stored configuration instances (sales orders, etc.) |
1. Material Master Layer
These are the starting point. Every configurable material has entries here.
| Table | Description | Key Fields |
|---|---|---|
| MARA | General material data | MATNR |
| MARC | Plant-level material data | MATNR, WERKS |
| MAKT | Material descriptions | MATNR, SPRAS |
A material becomes configurable when the material type is set to KMAT and a configuration profile is assigned. Check MARA-MTART and the CUCO table for the profile link.
2. Characteristic Master Layer
Characteristics are defined in CT04. The data lands in these tables:
| Table | Description | Key Fields |
|---|---|---|
| CABN | Characteristic master | ATINN (internal char number), ATNAM (char name) |
| CABNT | Characteristic descriptions | ATINN, SPRAS |
| CAWN | Characteristic values | ATINN, ATWRT (value), ATWTB (value text) |
| CAWNT | Value descriptions | ATINN, ATWRT, SPRAS |
CABN holds the characteristic header — one row per characteristic. Key fields:
- ATINN — Internal characteristic number (the join key everywhere)
- ATNAM — Characteristic name (Z_DOOR_COLOR, etc.)
- ATFOR — Data type (CHAR, NUM, CURR, DATE)
- ANZST — Number of values allowed (1 = single, 0 = multiple)
- ATKLA — Class type (mainly 300 for VC)
- ATINT — Interval values allowed flag
SELECT ATINN, ATNAM, ATFOR, ANZST, ATKLA, ATINT
FROM CABN
WHERE ATNAM LIKE 'Z\_%' ESCAPE '\'
INTO TABLE @DATA(lt_cabn).
CAWN holds the characteristic values. One row per allowed value per characteristic.
SELECT CABN~ATNAM, CAWN~ATWRT, CAWN~ATWTB
FROM CAWN
INNER JOIN CABN ON CAWN~ATINN = CABN~ATINN
WHERE CABN~ATNAM = 'Z_DOOR_COLOR'
INTO TABLE @DATA(lt_cawn).
- ATWRT — Internal value (what the system stores)
- ATWTB — External description (what the user sees)
Common debugging pattern: When a characteristic shows no values in the F4 help, check CAWN for that ATINN. If CAWN is empty, check if the values are maintained through a variant table instead.
3. Classification Layer
This is where characteristics get assigned to classes, and objects get assigned to classes with their values.
| Table | Description | Key Fields |
|---|---|---|
| KLAH | Class header | CLINT (internal class number), CLASSNAME |
| KSML | Characteristics of a class | CLINT, ATINN |
| KSSK | Object-to-class assignment | OBTAB (object table), OBJEK (object key), CLINT |
| AUSP | Characteristic values for objects | OBTAB, OBJEK, ATINN, ATWRT |
| INOB | Internal-to-external number link | CUOBJ (internal obj number), OBJNUM (external) |
KLAH holds class headers. Each VC class has one row here.
SELECT CLINT, KLART, CLASS, ANZDZ
FROM KLAH
WHERE KLART = 300 AND CLASS LIKE 'Z\_%' ESCAPE '\'
INTO TABLE @DATA(lt_klah).
- CLINT — Internal class number (join key)
- KLART — Class type (300 = VC class)
- CLASS — Class name
KSML links classes to their characteristics. The sort order (ADOBI) controls the configuration screen layout.
SELECT KLAH~CLASS, CABN~ATNAM, KSML~ADOBI
FROM KSML
INNER JOIN KLAH ON KSML~CLINT = KLAH~CLINT
INNER JOIN CABN ON KSML~ATINN = CABN~ATINN
WHERE KLAH~CLASS = 'Z_ELEVATOR_MODEL'
ORDER BY KSML~ADOBI
INTO TABLE @DATA(lt_ksml).
- ADOBI — Sort order (position in the class)
KSSK assigns objects (materials) to classes. This is how a material becomes configurable.
SELECT KLAH~CLASS, KSSK~OBJEK, KSSK~MAFID
FROM KSSK
INNER JOIN KLAH ON KSSK~CLINT = KLAH~CLINT
WHERE KSSK~OBJEK = 'MATERIAL_NUMBER' AND KSSK~MAFID = 'O'
INTO TABLE @DATA(lt_kssk).
KSSK is the junction table. It connects materials (in MARA) to classes (in KLAH). Each row says "this material belongs to this class."
- OBJEK — Object ID (material number)
- MAFID — Object type ('O' = material, 'E' = class)
AUSP is the table you will query most often during debugging. It stores the current characteristic values for every configured object.
SELECT CABN~ATNAM, AUSP~ATWRT, AUSP~OBJEK, AUSP~MAFID
FROM AUSP
INNER JOIN CABN ON AUSP~ATINN = CABN~ATINN
WHERE AUSP~OBJEK = 'MATERIAL_NUMBER' AND AUSP~MAFID = 'O'
INTO TABLE @DATA(lt_ausp).
Common debugging pattern: If a material shows wrong characteristic values in a sales order but correct values in CU50, compare AUSP entries across different OBJEK values — the sales order creates its own instance.
- OBTAB — Table name of the classified object ('MARA' for materials)
- MAFID — 'O' for objects, 'E' for classes
4. Configuration Profile Layer
The configuration profile ties everything together. It is created in CU41 and stores which class, which BOM, which routing, and which dependencies apply to a configurable material.
| Table | Description | Key Fields |
|---|---|---|
| CUCO | Master data for config profiles | KNNAM (profile name), OBJKY (material key) |
| CUOB | Dependency assignments to objects | CUOBJ (dependency instance), OBJKEY |
| CUEX | Compiled dependency source code | CUOBJ, DEP_ID, SOURCE (the compiled syntax) |
| CUKB | Administrative data for dependencies | DEP_OBJ (dependency key), AENDB (validity date) |
| CUKN | Dependencies for config database | CUOBJ, DEP_ID, SOURCE |
| CUXREF | Cross-reference for dependencies | OBJKEY, DEP_OBJ, CREATED_BY |
CUCO holds the configuration profile header. Each configurable material has one or more profiles here.
SELECT CUCO~*
FROM CUCO
WHERE OBJID = 'MATERIAL_NUMBER'
INTO TABLE @DATA(lt_cuco).
- OBJID — Object ID (material number or class)
- OBJART — Object type (material/class)
CUOB is the junction between dependencies and configuration objects. Every time you assign a dependency (procedure, constraint, precondition) to a configuration profile or material, a row goes into CUOB.
CUKB links configuration profiles to their object dependencies. This is where you check if a dependency is actually assigned to a profile.
SELECT CUKB~*
FROM CUKB
WHERE CUCO_ID = '<profile internal ID>'
INTO TABLE @DATA(lt_cukb).
CUEX stores the actual dependency source code — what the system executes.
SELECT CUEX~*
FROM CUEX
WHERE KNNAM = 'Z_PRICE_CALC'
INTO TABLE @DATA(lt_cuex).
- KNNAM — Dependency name
- KNTXT — The source code
- KNNUM — Line number within the dependency
Common debugging pattern: When a dependency "doesn't work," first check CUKB to confirm it's assigned to the configuration profile. Then check CUEX for the actual source code — the source in CUEX is what the system executes, which may differ from what you see in CU50's dependency editor if there are transport issues.
5. BOM Layer
The BOM for configurable materials uses class items (item category K) instead of standard material items.
| Table | Description | Key Fields |
|---|---|---|
| MAST | Material-to-BOM assignment | MATNR, STLAN (BOM usage), STLNR (BOM number) |
| STPO | BOM item data | STLNR, STLKN (item node), POSTP (item category) |
| KDST | Condition records for BOMs | STLNR, STLKN, DATUV |
Class items (STPO-POSTP = K) point to a class instead of a material. The actual component is resolved at configuration time based on characteristic values and selection conditions.
6. Configuration Storage Layer
When a sales order is configured and saved, the configuration instance is stored.
| Table | Description | Key Fields |
|---|---|---|
| IBIB | Instance header (one per configured object per order) | CUOBJ, OBJNUM |
| INOB | Links instance to material/class | CUOBJ, OBJNUM |
| IBIN | Characteristic value pairs for the instance | INSTANCE (CUOBJ), IN_RECNO |
| IBST | Instance structure / status | CUOBJ, PARENT_CUOBJ |
| IBINVALUES | Instance values (extended, for float values) | CUOBJ, ATINN, ATFLV |
| IBSYMBOL | Symbolic values (for variant matching) | CUOBJ, SYMBOL_ID |
| IBINOBS | Obsolete instance values | CUOBJ, ATINN |
Navigation: VBAP to Characteristic Values
A common task is reading the configuration values from a sales order item directly from the database. The table chain is:
-- Find all configurations for a sales order
SELECT IBIB~INSTANCEID, IBIB~OBJID, INOB~OBJEK
FROM IBIB
INNER JOIN INOB ON IBIB~INSTANCEID = INOB~IB_INSTANCE
WHERE IBIB~OBJID LIKE '%<sales_document>%'
INTO TABLE @DATA(lt_ibib).
-- Get the characteristic values for a specific instance
SELECT CABN~ATNAM, IBIN~ATWRT, IBIN~ATFLV
FROM IBIN
INNER JOIN CABN ON IBIN~ATINN = CABN~ATINN
WHERE IBIN~INSTANCEID = '<instance_id>'
INTO TABLE @DATA(lt_ibin).
ATWRT is the character representation of the value, while ATFLV is the floating-point representation. For NUM-type characteristics, use ATFLV.
The chain also works for any document with a CUOBJ field: delivery items (LIPS-CUOBJ), billing items (VBRP-CUOBJ), and others.
How the Tables Connect
CABN (characteristic) ← ATINN → CAWN (values)
↑ ATINN
KSML (class-char link) → KLAH (class)
↑ CLINT
KSSK (object-class link) → KLAH (class)
↑ CLINT / OBJEK
CUCO (config profile) → CUKB (profile-dependency link) → CUEX (dependency code)
IBIB (instance header) → IBIN (instance values) → CABN (characteristic)
↑ INSTANCEID
INOB (instance-object link) → IBIB
The most common query path for debugging:
- Start with the material → KSSK → find its class
- Class → KSML → find its characteristics
- Profile → CUKB → find assigned dependencies
- When something's wrong in a sales order: IBIB → IBIN → check saved values
If a configuration works in CU50 but fails in a sales order (VA01/VA02), the problem is often in how the instance is stored. Use SAAB transaction with checkpoint group VC_DB_INTERFACE to trace database-level storage. Source: SAP KBA 3284731
What Most Consultants Get Wrong
AUSP vs IBIN. AUSP stores current/active values. IBIN stores saved configuration snapshots. They serve different purposes:
| Query | Use AUSP | Use IBIN |
|---|---|---|
| What values does this material have right now? | ✅ | ❌ |
| What was configured in sales order 12345? | ❌ | ✅ |
| Why did the BOM explode differently in two orders? | ❌ | ✅ (compare saved instances) |
| Is this characteristic assigned to the material's class? | ❌ (check KSML/KSSK) | ❌ |
CUEX is the source of truth for dependency code. The dependency editor shows you what is in CUEX. If you have transported dependencies between systems, always verify CUEX against the source system — transports can fail silently for individual lines.
When to Use These Queries
| Scenario | Table to Query |
|---|---|
| Characteristic missing from F4 | CAWN for that ATINN |
| Material not configurable | KSSK for class assignment |
| Wrong values in a saved order | IBIN for that instance |
| Dependency not firing | CUKB for profile assignment + CUEX for code |
| Configuration inconsistent but values look right | IBST for instance status |
| Transport of VC objects failed silently | CUEX after transport |
Variant Tables (CUVTAB)
Variant tables are SAP's lookup-table mechanism for VC. They store valid combinations of characteristic values as rows in a table. Procedures reference variant tables using the TABLE keyword followed by the table name. Source: SAP Note 3573935
Interface Design Tables
The configuration editor layout definitions (used in CU50's interface settings):
| Table | Description |
|---|---|
| CECUFM | Screen format definitions |
| CECUSD | Screen basic data |
| CECUSDT | Screen description texts |
| CECUSF | Screen border definitions |
| CECUSFT | Screen border descriptions |
Summary
| Table | Layer | Most Common Use |
|---|---|---|
| CABN | Characteristic | Find a char by name |
| CAWN | Characteristic | List allowed values for a char |
| AUSP | Classification | Check what value a material has for a char |
| KSSK | Classification | Find which class a material belongs to |
| KLAH | Classification | Find class by name |
| CUCO | Config Profile | Find which profile a material uses |
| CUOB | Config Profile | Find dependencies assigned to a profile |
| CUEX | Config Profile | View compiled dependency source code |
| STPO | BOM | List BOM items for configurable materials |
| IBIN | Config Storage | View stored instance values from sales orders |
The key takeaway: the VC data model is straightforward once you see the join paths. CABN connects to everything. AUSP is for live debugging. IBIN is for order forensics. Know which table to query and you cut debugging time by more than half.
Source: SAP Note 558853 - Tables with DB statistics relevance for Variant Configuration | SAP Blog — Table Navigation for Sales Document VC | help.sap.com - Variant Configuration (LO-VC)