Variant Configuration touches more SAP tables than almost any other function. Characteristics, classes, profiles, dependencies, configuration snapshots, and BOM results — they are spread across dozens of tables. When something goes wrong, knowing which table to query saves hours.
This is a complete reference: every table you will actually query, organized by the layer they belong to.
Sources: SAP Note 558853 — Tables with current database statistics for VC | SAP KBA 3284731 — SAAB checkpoint group VC_DB_INTERFACE | SAP Note 3573935 — Variant Tables
The Layer Map
VC data lives across six logical layers. 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, CABNT, CAWN, CAWNT | Characteristic definitions, allowed values, texts |
| Classification | KLAH, KSML, KSSK, AUSP, INOB | Class hierarchy, char-to-class assignments, object-to-class links |
| Config Profile | CUCO, CUOB, CUKB, CUEX, CUKN | Profile header, dependency assignments, maintained and compiled source code |
| BOM | MAST, STPO, KDST | Material-to-BOM links, BOM item data, configurable BOM links |
| Config Storage | IBIB, IBIN, IBINVALUES, IBSYMBOL, IBST, IBINOWN | Saved configuration instances (sales orders, etc.) — header, instance records, values, status |
1. Material Master Layer
Every configurable material starts 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, ATNAM |
| CABNT | Characteristic descriptions | ATINN, SPRAS |
| CAWN | Characteristic values | ATINN, ATWRT |
| CAWNT | Value descriptions | ATINN, ATWRT, SPRAS |
CABN holds the characteristic header — one row per characteristic.
SELECT ATINN, ATNAM, ATFOR, ANZST, ATKLA, ATINT
FROM CABN
WHERE ATNAM LIKE 'Z\_%' ESCAPE '\';
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 — Characteristic group (check table TCMG). Not the class type — the class type lives on the class header (KLAH-KLART, 300 for VC), not in CABN
- ATINT — Interval values allowed flag
CAWN holds the characteristic values. One row per allowed value per characteristic.
SELECT CABN.ATNAM, CAWN.ATWRT, CAWN.ATWTB
FROM CAWN
JOIN CABN ON CAWN.ATINN = CABN.ATINN
WHERE CABN.ATNAM = 'Z_DOOR_COLOR';
Common debugging pattern: When a characteristic shows no values in F4 help, check CAWN for that ATINN. If CAWN is empty, check if 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.
| Table | Description | Key Fields |
|---|---|---|
| KLAH | Class header | CLINT, CLASS |
| KSML | Characteristics of a class | CLINT, ATINN, ADOBI |
| KSSK | Object-to-class assignment | OBTAB, OBJEK, CLINT |
| AUSP | Characteristic values for objects | OBTAB, OBJEK, ATINN, ATWRT |
| INOB | Internal-to-external number link | CUOBJ, OBJNUM |
KLAH holds class headers. Each VC class has one row.
SELECT CLINT, KLART, CLASS, ANZDZ
FROM KLAH
WHERE KLART = '300' AND CLASS LIKE 'Z\_%' ESCAPE '\';
KSML links classes to their characteristics. The ADOBI field determines sort order in the configuration screen.
SELECT KLAH.CLASS, CABN.ATNAM, KSML.ADOBI
FROM KSML
JOIN KLAH ON KSML.CLINT = KLAH.CLINT
JOIN CABN ON KSML.ATINN = CABN.ATINN
WHERE KLAH.CLASS = 'Z_ELEVATOR_MODEL'
ORDER BY KSML.ADOBI;
KSSK assigns objects (materials) to classes. This is how a material becomes configurable.
SELECT KLAH.CLASS, KSSK.OBJEK, KSSK.MAFID
FROM KSSK
JOIN KLAH ON KSSK.CLINT = KLAH.CLINT
WHERE KSSK.OBJEK = 'MATERIAL_NUMBER' AND KSSK.MAFID = 'O';
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
JOIN CABN ON AUSP.ATINN = CABN.ATINN
WHERE AUSP.OBJEK = 'MATERIAL_NUMBER' AND AUSP.MAFID = 'O';
Common debugging pattern: If a material shows wrong characteristic values in a sales order but correct values in CU50 / PMEVC simulation, compare AUSP entries across different OBJEK values — the sales order creates its own instance.
4. Configuration Profile Layer
The configuration profile ties everything together. It is created in CU41 and stores which class, BOM, routing, and dependencies apply to a configurable material.
| Table | Description | Key Fields |
|---|---|---|
| CUCO | Config profile master | KNNAM, OBJKY |
| CUOB | Dependency assignments to objects | KNNUM, KNOBJ, KNTAB |
| CUEX | Compiled dependency source code (compilation) | KNNUM, KNCNT, KNBLK |
| CUKB | Administrative data for dependencies | KNNAM, KNART, KNGRP |
| CUKN | Dependency storage — maintained source code | KNNUM, KNCNT, KNBLK |
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 also stores the dependency header (metadata: name, type, group, version, status). The maintained source code lives in CUKN (blocks in KNBLK); CUEX holds the compiled copy that the system executes.
SELECT cukn.*
FROM cukn
JOIN cukb ON cukn.knnnum = cukb.knnnum
WHERE cukb.knnam = 'Z_PRICE_CALC';
- KNNAM — Dependency name (in CUKB)
- KNNUM — Internal dependency number
- KNCNT — Block counter within the dependency
- KNBLK — The source code block (up to 2886 chars)
Common debugging pattern: When a dependency "doesn't work," first check CUKB to confirm it's assigned to the configuration profile. Then check CUKN for the maintained source code (KNBLK). CUEX holds the compiled variant of the source — if a dependency behaves differently after a transport, compare CUKN in the target system against the source system, since transports can fail silently for individual lines.
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, STLNR |
| STPO | BOM item data | STLNR, STLKN, POSTP |
| 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. Config Storage Layer
When a sales order is configured and saved, the configuration instance is stored.
| Table | Description | Key Fields |
|---|---|---|
| IBIB | Installed base header — one row per saved configuration | IBASE, OBJNR |
| IBIN | Instance records within the configuration | INSTANCE, IN_RECNO, VALFR, VALTO |
| IBINVALUES | Characteristic values of an instance | IN_RECNO, SYMBOL_ID, ATAUT |
| IBSYMBOL | Characteristic value combinations (symbols) | SYMBOL_ID, ATINN, ATWRT, ATFLV |
| IBST | Instance structure and status | INSTANCE, PARENT, ROOT |
| IBINOWN | Owner of an instance (the referencing document) | INSTANCE, OBJKEY |
When a sales order is saved, the configuration result is stored in the IB tables.
-- Find all configurations for a sales order
SELECT ibin.instance, ibin.in_recno
FROM vbap
JOIN ibin ON ibin.instance = vbap.cuobj
WHERE vbap.vbeln = '0000123456'
AND vbap.matnr = 'BIKE_KMAT';
-- Get the characteristic values for a specific instance
SELECT cabn.atnam, ibsymbol.atinn, ibsymbol.atwrt, ibsymbol.atflv
FROM ibinvalues
JOIN ibin ON ibin.in_recno = ibinvalues.in_recno
JOIN ibsymbol ON ibsymbol.symbol_id = ibinvalues.symbol_id
JOIN cabn ON cabn.atinn = ibsymbol.atinn
WHERE ibin.instance = '<instance_id>';
ATWRT is the character representation of the value, while ATFLV is the floating-point representation (both live on IBSYMBOL). For NUM-type characteristics, use ATFLV.
Navigation: Sales Order to Characteristic Values
A common task is reading configuration values from a sales order item directly from the database. The table chain is:
VBAP.CUOBJ → IBIN.INSTANCE → IBIN.IN_RECNO → IBINVALUES (SYMBOL_ID) → IBSYMBOL (ATINN, ATWRT)
- Start with the sales order item (VBAP). The field CUOBJ holds the configuration object number.
- Use CUOBJ to find the instance in IBIN (field INSTANCE). IBIN returns a record number (IN_RECNO).
- Use IN_RECNO in IBINVALUES to find the symbol (SYMBOL_ID); IBSYMBOL then maps the symbol to the internal characteristic number (ATINN) and its value (ATWRT).
This works for any document with a CUOBJ field: delivery items (LIPS-CUOBJ), billing items (VBRP-CUOBJ), and others.
If a configuration works in CU50 / PMEVC simulation 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.
7. Configuration Results: The IB Chain
There is no CONFIG/CONFDATA/CONF_OUT table set in SAP. Every saved configuration — in a sales order, delivery, or production order — is persisted as an Installed Base (IB) chain. These are the tables behind a stored configuration:
| Table | Purpose | Key Fields |
|---|---|---|
| IBIB | Installed base header — one row per saved configuration | IBASE, OBJNR |
| IBIN | Instance records within the configuration | INSTANCE, IN_RECNO, VALFR, VALTO |
| IBINVALUES | Characteristic values of an instance | IN_RECNO, SYMBOL_ID, ATAUT |
| IBSYMBOL | Characteristic value combinations (symbols) | SYMBOL_ID, ATINN, ATWRT, ATFLV |
IBIB — One row per saved configuration. IBASE is the configuration's instance-base number; OBJNR holds the object number of the configured object (e.g. a sales order item).
IBIN — Instance records: the configured objects inside the configuration. Each instance has a number (INSTANCE) and a unique record number (IN_RECNO), with validity dates (VALFR/VALTO).
IBINVALUES — The characteristic values assigned to an instance. Each row references an instance record (IN_RECNO) and a symbol (SYMBOL_ID); ATAUT records what set the value (user, constraint, procedure, default, ...).
IBSYMBOL — Defines each symbol: which characteristic (ATINN) and which value (ATWRT / ATFLV). Symbols let the same characteristic value be referenced by many instance records without duplication.
Note for S/4HANA: AVC uses the same IB-table persistence as LO-VC (IBIB/IBIN/IBINVALUES/IBSYMBOL). The engine difference is at processing time, not storage time.
ABAP Query Examples
Find all configurations for a sales order:
DATA: lt_vbap TYPE TABLE OF vbap.
SELECT vbeln, posnr, matnr, cuobj
FROM vbap
INTO TABLE lt_vbap
WHERE matnr = 'BIKE_KMAT'
AND vbeln = '0000123456'.
IF sy-subrc = 0.
SELECT instance, in_recno
FROM ibin
INTO TABLE @DATA(lt_instances)
FOR ALL ENTRIES IN @lt_vbap
WHERE instance = @lt_vbap-cuobj.
ENDIF.
Get the characteristic values for a configuration:
SELECT cabn~atnam, ibsymbol~atinn, ibsymbol~atwrt, ibsymbol~atflv
FROM ibinvalues
JOIN ibin ON ibin~in_recno = ibinvalues~in_recno
JOIN ibsymbol ON ibsymbol~symbol_id = ibinvalues~symbol_id
JOIN cabn ON cabn~atinn = ibsymbol~atinn
INTO TABLE @DATA(lt_values)
WHERE ibin~instance = @lv_instance.
Troubleshooting Common Questions
Q: CUOBJ is 0 in VBAP. Why? A: The material is not fully configured, or the configuration profile isn't set correctly. Configuration only creates a CUOBJ when a configuration exists for that item.
Q: Can I query AVC configs the same way as LO-VC? A: Yes. AVC persists configurations in the same IB tables (IBIB/IBIN/IBINVALUES/IBSYMBOL). The engine difference is at processing time, not persistence time.
Q: How do I find configuration for a production order? A: Production order header (AFKO) doesn't have CUOBJ directly. Join via material variant or through the order BOM (STPO).
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.
Common debugging pattern: When a table condition "doesn't fire," first check the variant table contents. Empty tables or mismatched characteristic names are the most common cause.
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 |
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) → CUOB (assignments) → CUKB (dependency header) → CUKN (maintained source) / CUEX (compiled code)
IBIB (instance header) → IBIN (instance records) → IBINVALUES (values) → IBSYMBOL (characteristic values)
↑ INSTANCE
IBINOWN (owning document) → IBIN (INSTANCE)
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 → IBINVALUES/IBSYMBOL → check saved values
- For a saved configuration: IBIN → IBINVALUES → IBSYMBOL → check which characteristic values were stored
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) | ❌ |
CUKN is the source of truth for dependency code. The dependency editor shows you what is in CUKN — the maintained source, stored in KNBLK blocks. CUEX holds the compiled variant of that source. If you have transported dependencies between systems, always verify CUKN 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 + CUKN for source |
| Configuration inconsistent but values look right | IBST for instance status |
| Transport of VC objects failed silently | CUKN after transport |
| What BOM items were selected for a config? | BOM explosion logs / CUKN dependencies — there is no CONF_OUT table |
| Sales order → config values | VBAP-CUOBJ → IBIN → IBINVALUES/IBSYMBOL |
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/IBINVALUES/IBSYMBOL are for saved-configuration forensics. Know which table to query and you cut debugging time by more than half.