Debugging SAP Variant Configuration Dependencies: A Practical Guide

Variant Configuration dependencies are the most complex part of any VC model. When something goes wrong, a component is selected incorrectly, a price comes out wrong, or a valid combination is rejected, you need to debug the dependency logic.

This guide covers the practical techniques for debugging VC dependencies in both LO-VC and AVC, based on official SAP documentation and real project experience.

Note: In S/4HANA, PMEVC (transaction code) provides a Fiori-based alternative to CU50 for configuration simulation and trace. PMEVC works in both LO-VC and AVC engine modes. The same trace data is available with a more modern UI, live updates, and built-in filtering. This guide focuses on CU50 because it is universally available across ECC and S/4HANA, but if you are on S/4HANA, try PMEVC first.

SAP Community : AVC Trace Guide by Florian Soe (SAP)

The Most Important Tool: CU50 Configuration Trace

CU50 is the configuration simulation transaction in SAP. It lets you configure a material step by step, and it can record a trace of every dependency that executes.

How to Activate the Trace

There are two ways to activate the VC trace, depending on how you work:

Option 1: CUTRC (recommended for LO-VC)

Use transaction /nCUTRC to open the trace in its own independent window. This is more convenient than the embedded approach because:

The trace window stays open separately from your configuration session
Settings are easier to configure and adjust on the fly
You can keep it running across multiple CU50/VA01 sessions

Open CUTRC, configure your trace level and areas, activate it, then switch to CU50 or VA01 to configure. The trace captures everything automatically.

Option 2: Embedded via CU50 (quick access)

Open CU50 (/nCU50)
Enter the configurable material and any required characteristics
Go to Extras → Trace → Activate
Configure your material by selecting characteristic values
Go to Extras → Trace → Display

In S/4HANA: PMEVC Simulation (works in LO-VC mode too)

In PMEVC, open the Simulation function. PMEVC is a Fiori transaction available in S/4HANA regardless of whether you run the LO-VC or AVC engine. This approach is different from CU50 : you configure and trace in the same view, side by side. The trace content updates live as you select values, making it easier to understand which dependency is triggered by each action. The output is also more detailed and structured than the classic CU50 trace.

The trace shows you every dependency that fired, in what order, and with what result.

What the Trace Tells You

A typical CU50 trace entry (with More Detailed level) looks like this:

Line    Message    Message    Message
Index   Class      Type       Number    Message Text                           Dependency Trace
1                                         Trace de/activated 10.10.2022 at 03:01
2       28         I          405       $SELF____: 00000001 000000000013685525 000000001000000001
3       28         I          405       $PARENT_: 00000001 000000000013685525 000000001000000001
4       28         I          405       $ROOT___: 00000001 000000000013685525 000000001000000001
5       28         I          405
6       28                    599       Procedure        PRO_PRICE_CALC executed    X
7       28                    599       < $SELF  .TOTAL_PRICE           15000.00    X
8       28                    599
9       28                    599       Procedure        PRO_DOOR_ADJUST executed   X
10      28                    599       > $ROOT  .DOOR_TYPE                GLASS    X
11      28                    599       < $SELF  .TOTAL_PRICE           17000.00    X
12      28                    599
13      28                    599       Procedure        PRO_MAT_OPTION executed    X
14      28                    599       > $ROOT  .DOOR_TYPE                GLASS    X
15      28                    599       $ROOT  .MAT_FINISH               RAL7035    X
16      28                    599       $ROOT  .DOOR_HEIGHT                 2000    X

Each line is labeled with a message type:

599 = Dependency execution : Shows procedures being called and characteristic values being read/written
405 = Instance header : Identifies the current configurable instance ($SELF, $PARENT, $ROOT)
> prefix : A characteristic is being read (used as input)
< prefix : A characteristic is being written (assigned a value)
No prefix : Intermediate calculation or internal value

Common Dependency Errors and How to Find Them

1. Characteristic Value Not Available

Symptoms: A configuration runs without explicit errors, but certain characteristic values show "NR" (Not Relevant) instead of the expected assigned value. Downstream procedures or constraints fail because they can't read the expected values.

Example trace:

Line    Message    Message    Message
Index   Class      Type       Number    Message Text                                    Dependency Trace
1       CU         I          444       Characteristic Z_FINISH_COLOR  - value NR
2       CU         I          444       Characteristic Z_PANEL_TYPE    - value NR
3       CU         I          444       Characteristic Z_DOOR_HEIGHT   - value NR
4       C1         S          821       Inconsistent characteristic value assignment
5       CU         I          444       Characteristic Z_PANEL_TYPE    - value NR
6       C1         S          821       Inconsistent characteristic value assignment

How to find it: Look for Message Type 444 (characteristic value not available : NR means the characteristic has no valid value 'NR' at this point in the configuration). When a value is assigned but not available, it triggers Message 821 (inconsistent assignment).

Common causes:

The characteristic value is assigned via a dependency without checking the value available first

Fix: Check the characteristic's value domain in CT04.

2. Procedure Execution Order Dependency

Symptoms: The same configuration sometimes works, sometimes doesn't. The result depends on which order the user selects values.

Example:

* Procedure 1
$SELF.TOTAL_PRICE = $SELF.BASE_PRICE,
* Procedure 2
$SELF.TOTAL_PRICE = $SELF.TOTAL_PRICE + 500 if $SELF.FEATURE_X = 'Yes',
$SELF.TOTAL_PRICE = $SELF.TOTAL_PRICE * 1.1 if $SELF.FEATURE_X = 'Yes'.

If the user selects FEATURE_X = 'Yes' before the base price is calculated (Procedure 1 hasn't run yet), TOTAL_PRICE gets multiplied by 1.1 after Procedure 2 fires again on the next field change. The result depends on timing.

How to find it: The CU50 trace shows the execution order. If you see the same procedure running multiple times with different results, this is your problem.

Fix: Use the not $SELF.TOTAL_PRICE specified guard to prevent re-execution:

$SELF.TOTAL_PRICE ?= $SELF.BASE_PRICE if not ($SELF.TOTAL_PRICE specified),

3. Selection Conditions That Never Fire

Symptoms: A component is always included in the BOM or never included, regardless of configuration choices.

Example: A glass door panel should only appear when DOOR_TYPE = 'Glass'. But it appears in every BOM explosion.

How to find it: In CU50, run BOM → Display after configuring. Check which components were selected or excluded. The trace doesn't directly show selection condition results in all cases.

Verification path:

In CU50, configure the material with DOOR_TYPE = 'Steel'
Run BOM explosion
Check if the glass door panel appears (it shouldn't)
View the selection condition on the glass door BOM item (CS02) and check its logic

Common causes:

Selection condition uses $SELF prefix when the condition runs at the parent level (should use $PARENT)

4. Precondition That Blocks Valid Choices

Symptoms: A characteristic value is red (invalid) in the configuration screen for no apparent reason.

How to find it: In CU50, hover over the red value or use Extras → Incompleteness List. This shows which preconditions are failing.

Fix: Look at the precondition logic. Common issues:

The precondition references another characteristic that hasn't been set yet
The precondition uses AND when it should use OR
The precondition is assigned to the wrong value

LO-VC vs AVC: Debugging Differences

Both LO-VC and AVC support the configuration trace, but there are important differences:

Aspect	LO-VC	AVC (PMEVC)
	UI	SAP GUI — CU50 / CUTRC (standalone). Also PMEVC (Fiori) in S/4HANA
Trace activation	CU50: Extras → Trace → Activate. CUTRC: dedicated transaction, independent window	PMEVC Simulation mode: configure and trace side by side, live updates
Trace output	Sequential dependency execution log	Constraint-based evaluation log, more structured
Procedure order	Preserves execution order	Constraint solver may reorder
Error messages	Generally clear	More detailed (includes constraint violations)
Temporary chars	Supported in procedure	Not supported — must be refactored
Trace comparison	Manual	AVC Trace Inspector filters by message type, characteristic, or dependency

Debugging in AVC: Key Differences

Constraint violations appear differently. In AVC, if a constraint can't be satisfied, the solver does not fail silently. It flags the conflict. The trace output shows which constraints are in conflict and which characteristic values would resolve them.

AVC Trace Inspector filters. AVC's trace (available in the PMEVC simulation UI) offers more powerful filtering than CU50: you can filter by Trace Level (high-level vs low-level), Message Type (info, warning, error, inconsistency), Value Assignment By, Characteristic, and Dependency. Use the "Inconsistency Detected" message type filter to jump straight to configuration errors. Source: SAP Community : The Trace by Florian Soe

Trace deactivation. In some SAP releases, the trace may activate automatically in CU50/VA01 even when the configuration log is off. If you see unexpected trace behavior, check KBA 1889920 for deactivation steps. Source: SAP KBA 1889920

Procedures with $SELF.X = $SELF.X + <value> patterns behave differently in AVC. The constraint solver may interpret this as a constraint equation rather than a sequential update. Use intermediate characteristics to break these into clear assignment steps.

Temporary characteristics cause hard errors in AVC. If your LO-VC model uses temporary characteristics, the AVC trace will show them as unresolved. Every characteristic must be:

Created in CT04
Assigned to a class (CL02)

A Systematic Debugging Workflow

Step 1: Reproduce the Problem in CU50

Always start by reproducing the issue in controlled conditions:

Note the exact configuration choices
Capture the expected vs actual result
Check if the issue is consistent or intermittent

Step 2: Activate and Run the Trace

/nCU50
Extras → Trace → Activate

Configure with the problematic combination. Display the trace.

Step 3: Identify the Failing Dependency

Scan the trace for:

Conditions evaluating FALSE when they should be TRUE
Values set to unexpected numbers
Missing assignments (characteristics that should have been set but weren't)
Procedures that didn't fire at all

Step 3b: Use SAAB for VC_DB_INTERFACE Trace (Sales Order Issues)

If the configuration works in CU50 but fails in a sales order (VA01/VA02), the trace may not capture database-level issues. Use SAAB transaction with checkpoint group VC_DB_INTERFACE to trace how the configuration instance is stored and retrieved in sales orders. This is especially useful for debugging "configuration lost after save" scenarios. Source: SAP KBA 3284731

Step 4: Isolate and Test

For the suspected dependency, test it in isolation:

Create a minimal test scenario in CU50 with only the relevant characteristics
Set characteristic values one at a time to see which step triggers the issue
If possible, comment out other dependencies temporarily to isolate the problem

Step 5: Fix and Compare Traces

After fixing: run the same configuration through CU50 and compare the old trace with the new one. They should differ only where you intended the change.

AVC-Specific Debugging Checklist

All characteristics are assigned to a class in the configuration profile
No $TEMP or unassigned characteristics remain in dependencies
Procedure execution order is verified. AVC may reorder.
Constraints don't conflict with each other (check solver output)
Variant tables are converted to AVC-compatible format
External API calls (BAPI, RFC) return the same results as CU50 trace

Summary

Debugging Tool	When to Use	What It Shows
CU50 Trace	First step for any dependency issue	Full execution log with values and conditions
AVC Trace Inspector	AVC-specific issues — filter by message type, characteristic	Constraint violations, solver output, trace level filtering
BOM Display (CU50)	Component selection problems	Which BOM items were selected/excluded
Incompleteness List	Precondition blocking values	Which preconditions are failing
SAAB — VC_DB_INTERFACE	Config works in CU50 but fails in sales order	Database-level configuration storage and retrieval

CU50 Interface Settings

CU50 has configuration options accessed via Settings → Interface:

Option	Description
Screen layout	Control which characteristic groups and values appear
Detail level	How much trace detail to capture (Basic, More Detailed, Full)
Default values	Pre-set configuration values for testing

These settings are stored in the CECU* tables:

Table	Description
CECUFM	Screen format definitions
CECUSD	Screen basic data
CECUSDT	Screen description texts
CECUSF	Screen border definitions
CECUSFT	Screen border descriptions

CU50 vs VC_TABLE_INFO

Tool	Purpose
CU50	Traces dependency execution during configuration. Shows runtime behavior.
VC_TABLE_INFO	Shows database table structure. Identifies which tables store VC data for a given object.

Use CU50 to understand what the system does. Use VC_TABLE_INFO to understand where the system stores it.

Batch Trace for Regression Testing

You can run CU50 in batch mode for regression testing:

Set up a configuration scenario and save it
After changing dependencies, re-run CU50 against the saved configuration
Compare old and new trace output to verify the change didn't break existing scenarios

This is faster than testing through VA01 every time.

Dependency Processing Sequence (LO-VC)

Understanding the order in which dependencies execute is critical for debugging. When a user confirms a characteristic value, LO-VC processes dependencies in this fixed sequence:

Actions — multiple rounds. Actions can set values, and those settings can trigger other Actions. The system loops until no new values can be inferred.
Procedures — exactly once, in three sub-phases: a. Configuration profile procedures (in order of definition) b. Characteristics procedures c. Characteristic value procedures
Actions — re-run if procedures produced new values
Preconditions
Selection conditions (for characteristics visibility)

Constraints process in parallel with steps 1-3. They do not wait for the sequential chain to finish, and they are not re-triggered by implied changes inside the constraint engine.

This means if a constraint sets a value that would normally trigger a Procedure, the Procedure does not re-run because of the constraint's output. The system only re-loops Actions after Procedures.

The CU50 trace confirms this: you see procedures firing in sequence, followed by preconditions and selection conditions, while constraint results appear alongside but independently.

The CU50 trace is your most powerful debugging tool for both LO-VC and AVC. Activate it early, use it often, and always compare traces before and after changes. Most dependency bugs can be found and fixed in under 30 minutes if you follow a systematic trace-first approach.