Written by Minami — Paddy & Water Inc. / Technology & Platform

A Detailed Guide to Technical Settings, Dependencies, AVC, and Integration Design

June 2026

Introduction: Why VC Is Needed and the Overall Architecture

Efficiently managing “products whose specifications differ for each customer” is one of the most challenging themes in ERP design for manufacturing companies. SAP Variant Configuration (VC) provides an answer to this challenge: a mechanism that “dynamically generates the BOM, routing, and price from a single configurable material (KMAT) and product model (characteristics, classes, dependencies), according to the customer’s selections at the time of order entry.”

To correctly design and implement VC, it is necessary to understand the relationships among the seven objects — “characteristics (CT04), classes (CL02), configurable material (KMAT), super BOM, super routing, dependencies (CU01–CU04), and configuration profile (CU41)” — as well as the detailed technical settings of each object. This article thoroughly explains these, including setup procedures, syntax, and constraints.

Overall Object Relationship Diagram of VC

• KMAT material (MM01): The product template for VC. Has a configuration class (type 300).

• Characteristic (CT04): A master defining specification axes (COLOR, ENGINE_TYPE, VOLTAGE, etc.).

• Class (CL02, type 300): A container that bundles characteristics. Assigned to the KMAT.

• Configuration profile (CU41): A setting record on the KMAT that controls how VC behaves.

• Super BOM (CS01, usage 1 or 5): A BOM covering the parts for all variants. Selection conditions are attached to each line item.

• Super routing (CA01): A routing covering the operations for all variants. Selection conditions are attached to each operation.

• Dependencies (CU01–CU04): Logic describing business rules between characteristic values.

• Variant conditions: Pricing rules that connect VC with pricing (the SD condition technique).

1. Detailed Settings for Characteristics — CT04

Basic Structure of a Characteristic

A characteristic is the “axis of choice” in VC. It is created and managed in CT04. Characteristics are also shared with other SAP modules such as DMS and Classification, but there are settings specific to VC.

Data Types and Technical Parameters

Character Type (CHAR)

The character type is used for categorical values such as “exterior color, material, product grade.”

• Field length: Maximum 30 characters. This affects the display width on the VC configuration screen.

• Case sensitivity: Enabling the “Uppercase Only” flag automatically converts input values to uppercase. Because comparison expressions in dependencies are case-sensitive, the setting of this flag affects how dependencies behave.

• Allowed value list (Allowed Values): The selectable values are defined on the “Values” tab of CT04. Both a value code (Value) and a description (Description) are set for each language. In VC it is generally recommended to define all values as fixed values and disable “Additional Values.”

Numeric Type (NUM)

The numeric type is used for quantitative values such as “voltage, output, weight, size.”

• Number of digits / decimal places: Defines the number of digits in the integer and decimal portions. Example: a voltage characteristic with “5 integer digits, 0 decimal digits.”

• Unit of measurement: Numeric characteristics can be given a unit (kW, V, kg, mm, etc.). For characteristic values with units, numeric comparisons in dependencies require logic that accounts for unit conversion.

• Interval values: For numeric types, instead of fixed values, an allowed range can be defined using “minimum value, maximum value, increment.” Example: voltage 100–240V, increment 10V. With this increment setting, 100V, 110V, 120V … 240V become the selectable values.

Date Type (DATE) and Time Type (TIME)

Use in VC is limited, but these are used when a temporal specification axis, such as “effective start date” or “planned production start date,” is needed. Date comparisons in dependencies use dedicated functions such as DATE_TO_DAYS.

VC-Specific Characteristic Setting Tabs

Controlling “Additional Values”

• “Additional Values”: When turned ON, free-text entry outside the fixed value list becomes possible. In VC design this is normally turned OFF to restrict choices to fixed values. Turn it ON only for characteristics that require free-text entry, such as customer-specific engraving strings.

The “Chars” Tab (Additional Characteristic Attributes)

• “Entry Required”: When this flag is ON, a value entry for this characteristic is considered mandatory when determining whether configuration is complete. It is linked to VC’s “Complete Configuration” check.

• “No Display”: Turn this flag ON for characteristics that should not be displayed on the configuration screen (internal characteristics that are set automatically by dependency actions).

• “Not Ready for Input”: Turn this ON for characteristics that are automatically set by an action. This enforces that users cannot change them manually.

• “Reference Characteristic”: A setting that references a specific field of the material master, sales order, or production order as a characteristic. Example: define a reference characteristic that references the weight in the material master (MARA-NTGEW), and use it to set selection conditions in dependencies based on weight.

Multilingual Settings for Characteristics

The “Description” of a characteristic and the “text of the fixed values” can be set in multiple languages. Use the language switch button in CT04 to enter descriptions individually for Japanese, English, and so on. Because the display language of the configuration screen depends on the login user’s language setting, it is essential to set text for every language that will be used. If this is omitted, users of a particular language will see garbled text or blanks.

2. Detailed Settings for Classes — CL02

Characteristics of Class Type 300 (Configuration Class)

The class type used in VC is class type “300 (Configuration Class).” Class type 300 has attributes specific to VC that differ from other class types (such as 001: general, 002: material, etc.).

• Creating a class: Launch CL02 → enter the class name → select class type “300” → enter a description on the basic data tab → add characteristics on the “Chars” tab.

• Order of assigning characteristics to a class: The order in which characteristics are added on the “Chars” tab directly affects the display order on the configuration screen. Design the order so it is easy for users to select from (placing higher-importance characteristics near the top).

• Making a characteristic mandatory (Required): A specific characteristic within a class can be set to “Required.” This setting is linked to the “Entry Required” flag in CT04.

Class Hierarchy and Class Nodes

An advanced VC feature is the “class node.” Instead of placing a material in a super BOM line item, a “class” is placed there, and at configuration time a material is dynamically selected from among the materials belonging to that class.

• Use case for class nodes: For example, rather than directly placing a gearbox material in the “gearbox” line item, the class “GEARBOX_CLASS” is placed as a class node. From among the materials belonging to GEARBOX_CLASS (5-speed MT, 6-speed MT, 8-speed AT, etc.), the material corresponding to the characteristic values is automatically selected.

• Configuring a class node: In the BOM line item in CS01, select “Class Node: D” as the item category and enter the class number (the class created in CL02). A class node can be given selection conditions just like an ordinary line item.

• Constraint on class nodes: A material selected from a class node must be a material that is “assigned” to that class. Assigning materials to classes in CL20N is required. Since this increases the management burden for materials and classes, it is recommended to limit the use of class nodes to cases where they are truly necessary.

3. Configuring the Configurable Material (KMAT) — MM01/MM02

Characteristics of Material Type KMAT

A configurable material is created with material type “KMAT.” There are important settings that differ from a normal finished product (FERT).

Key Views and Settings

Basic Data 2 View

• “Configurable Material” flag: Turning on this checkbox declares that the material is subject to VC. Without this flag, a configuration profile (CU41) cannot be created.

MRP 2 View

• “Configuration Management”: Select “Variant Configuration.” This enables the configuration screen in production orders and sales orders.

Sales: General/Plant Data View

• “Variable-Size Item”: A flag used when the size of a dimension-specified item (cut steel material, wire, etc.) is specified via a VC characteristic. Not needed for normal VC use cases.

Classification View

• Assigning the configuration class: On the Classification view, a class type 300 class is assigned to the material. This assignment causes the characteristics of that class to be displayed on the configuration screen. It is possible to assign multiple class type 300 classes to a single KMAT, but since this makes control via the profile more complex, a design that consolidates into a single class is recommended.

Details of the Configuration Profile (CU41)

The configuration profile is a setting record that controls the VC behavior of a KMAT. It is managed via CU41 (create), CU42 (change), and CU43 (display). Multiple profiles can be created for a single KMAT, and it is also possible to switch profiles depending on the purpose (quotation, sales order, production order).

Key Profile Settings

• “BOM Application”: Specifies the usage of the super BOM to be used at configuration time (e.g., usage 1 = engineering BOM, usage 5 = sales BOM). When different BOM usages are used for sales-order configuration and manufacturing configuration, create a corresponding profile for each.

• “Configuration Type”: Choose either “User Interface Configuration” or “Background Configuration.” UI configuration is a mode in which the person in charge manually enters values on the configuration screen. Background configuration is a mode (automatic configuration) in which values are set automatically using only dependency actions and reference characteristics.

• “Class”: Explicitly specifies the configuration class used by the profile. It must match the class assigned on the Classification view.

• “SCE Usage”: A flag that enables the “Solution and Constraint Engine” when using a constraint net. Turn this OFF when constraint nets are not used, to avoid the performance overhead.

• “Variant Matching”: A setting for whether, when an existing “variant” (an individual material under the KMAT) exists whose configuration values exactly match, that variant is automatically selected. When “Find Variants” is ON, matching variants are automatically identified.

4. Super BOM: Technical Details of Selection Conditions and Quantity Formulas

Design Philosophy of the Super BOM

A super BOM is “a single BOM that enumerates all the parts that could potentially be used in any variant.” A “selection condition” is attached to each line item, and that line item becomes valid only for a specific combination of characteristic values.

As a design principle for super BOMs, “parts always used in every variant” and “parts used only in specific variants” are mixed together. The former have no selection condition (always valid unconditionally), while the latter are given selection conditions.

Setting Selection Conditions on BOM Line Items

Select a BOM line item in CS01/CS02 and enter the selection condition from the “Extra → Conditions” menu or the “Conditions” line-item tab. Selection conditions are written using dependency syntax.

Basic Syntax of a Selection Condition

$self.COLOR = ‘RED’

The above is a selection condition meaning “enable this line item if the value of the COLOR characteristic is RED.” $self is a reference term pointing to the material itself that is the subject of configuration.

Compound Conditions (AND / OR)

$self.COLOR = ‘RED’ AND $self.GRADE = ‘PREMIUM’

$self.COLOR = ‘RED’ OR $self.COLOR = ‘WHITE’

Use parentheses to make the precedence explicit when combining AND and OR.

($self.COLOR = ‘RED’ OR $self.COLOR = ‘WHITE’) AND $self.GRADE = ‘PREMIUM’

Numeric Comparison Operators

$self.ENGINE_OUTPUT > 200

$self.ENGINE_OUTPUT >= 150 AND $self.ENGINE_OUTPUT <= 250

For comparisons with numeric characteristics, the operators “>, <, >=, <=, =, <> (not equal)” can be used.

The IN Operator (Specifying Multiple Values at Once)

$self.COLOR IN (‘RED’, ‘WHITE’, ‘SILVER’)

Using IN allows an OR condition over multiple values to be written concisely.

Quantity Formulas

The quantity of a BOM line item can be specified not as a fixed value but via a calculation formula based on characteristic values. Enter the formula in the “Quantity Formula” field to the right of the quantity field.

Basic Syntax of a Quantity Formula

$self.NUM_FLOORS * 4

Example: a quantity formula for a building structure where “number of floors (NUM_FLOORS) × 4” bolts are needed.

ROUND($self.WEIGHT / 10, 0)

Example: a quantity obtained by dividing the weight (WEIGHT) by 10 and rounding.

Conditional Quantity (IF Expression)

IF $self.OPTION = ‘HEAVY’ THEN 8 ELSE 4

A conditional expression that returns quantity 8 if OPTION is HEAVY, and 4 otherwise.

Combining BOM Line Item Validity Periods with VC

A “validity period (Valid From / Valid To)” can be set on a super BOM line item. By combining a selection condition with a validity period, precise control such as “valid only for orders placed on or after October 1, 2026, and only when COLOR = RED” is possible. Activation via change numbers, in conjunction with ECM (Engineering Change Management), can also be configured.

5. Super Routing: Setting Operation Selection Conditions

Structure of the Super Routing

A super routing is created for a KMAT material in CA01. Like a normal routing, it enumerates operations, but it differs in that a selection condition is attached to each operation.

Attaching Selection Conditions to Operations

Open the routing in CA01/CA02, select an operation, and enter the selection condition from “Extras → Conditions.” The syntax is identical to that of BOM line item selection conditions.

• Example: The selection condition for operation “0020: Surface Treatment (PAINT)” → $self.SURFACE = ‘COATED’. This operation is included in the production order only when a painting process is selected.

• Example: The selection condition for operation “0030: Turbo Assembly (TURBO_ASSY)” → $self.TURBO = ‘YES’. This is executed only when the turbo option is selected.

Combining with Reference Operations

By using a “Reference Operation Set” within a super routing, operations common to multiple products (quality inspection, packaging, cleaning, etc.) can be managed centrally. Reference operations are linked to the super routing, and selection conditions are attached to the reference operations themselves. Changes to a reference operation are immediately reflected in every super routing that references it.

6. Dependencies: A Complete Technical Reference

Types of Dependency Objects and Transactions

Dependencies are managed via the transactions CU01 through CU04.

• CU01: Create/change a precondition

• CU02: Create/change a selection condition (although these are more often entered directly from a BOM/routing line item)

• CU03: Create/change an action/procedure

• CU04: Create/change a constraint net

Dependencies are managed via KU01, etc. (list of dependencies) and CU05 (assignment of dependencies to characteristics). There are two ways to define a dependency: embed it directly in an object (a BOM line item or a characteristic’s fixed value), or create it as an independent object (CU01–CU04) and reference it. Highly reusable dependencies should be defined as independent objects.

Dependency Syntax: A Complete Reference

Variables and Reference Terms

• $self: A reference to the material itself that is the subject of configuration. Characteristics are referenced as in $self.COLOR.

• $parent: A reference to the parent assembly. Used when referencing the parent material’s characteristic values from the VC of a subassembly material.

• $root: A reference to the topmost material in the product hierarchy. Used when referencing the topmost characteristics in a deep hierarchical VC structure.

• TABLES: A declaration used when referencing a characteristic’s “table” form (a table condition defining combinations of multiple characteristic values in tabular form).

Basic Operators

= <> (not equal)

> >= < <=

AND OR NOT

IN (‘A’, ‘B’, ‘C’)

Numeric Functions

• ABS(x): Absolute value.

• ROUND(x, n): Rounds to n decimal places.

• TRUNC(x, n): Truncates to n decimal places.

• SQRT(x): Square root.

• LOG(x): Natural logarithm.

String Functions

• SUBSTR(str, start, length): Extracts a substring.

• LENGTH(str): Returns the length of a string.

• CONTAINS(str, ‘pattern’): Checks for a pattern match (wildcard “*” can be used).

Special Variables

• $INOB.MENGE: A reference to the BOM line item quantity (used within quantity formulas).

• $INOB.MEINH: A reference to the BOM line item unit of measure.

Details of Preconditions

A precondition defines “the condition under which a characteristic’s fixed value is displayed on the selection screen.” If the precondition is not met, that fixed value is not shown in the dropdown on the configuration screen.

How to Assign a Precondition

Open the characteristic in CT04, select the fixed value on the “Values” tab → enter the dependency from “Extras → Object Dependencies → Preconditions.”

Example: Controlling Turbo Options Based on Engine Output

/* Precondition for the TURBO characteristic value “YES” */

$self.ENGINE_OUTPUT > 150

“TURBO = YES” is shown on the selection screen only when ENGINE_OUTPUT exceeds 150 kW. In a state where an engine of 150 kW or less is selected, “YES” is hidden and only “NO (or blank)” is selectable.

Details of Actions (Action / Procedure)

An action is processing that “automatically sets another characteristic value when a certain characteristic value is selected.” It is defined either as an independent object in CU03, or embedded directly in a characteristic’s fixed value in CT04.

Action Syntax (IF-THEN-ELSE)

IF $self.COLOR = ‘WHITE’

THEN

$self.INTERIOR = ‘GREY’

END_IF

IF $self.GRADE = ‘PREMIUM’

THEN

$self.WARRANTY = ‘5Y’

$self.SUPPORT = ‘GOLD’

END_IF

A single action can set multiple characteristic values. Write multiple assignment statements in the THEN clause.

ELSEIF Syntax

IF $self.ENGINE_OUTPUT > 300

THEN

$self.COOLING = ‘WATER_RACE’

ELSEIF $self.ENGINE_OUTPUT > 150

THEN

$self.COOLING = ‘WATER_STD’

ELSE

$self.COOLING = ‘AIR’

END_IF

How to Assign an Action

An action is linked by selecting a fixed value on the “Values” tab of CT04 → “Extras → Object Dependencies → Actions.” This carries the meaning “the action to execute when this value is selected.” Alternatively, by linking an action to the characteristic itself, processing can be defined to “execute whenever a value is entered into this characteristic (regardless of which value).”

Detailed Design of Constraint Nets

Architecture of the Constraint Net

A constraint net is a set of declarative rules processed by the SCE (Solution and Constraint Engine). Unlike ordinary dependencies (IF-THEN type), it supports “bidirectional inference.” Once the relationship between a pair of characteristics is described a single time, whichever characteristic is determined first, the other is automatically inferred.

Syntax of a Constraint

Each individual constraint within a constraint net is written using the following syntax.

CONSTRAINT constraint_name

CONDITION

<precondition expression (the condition under which this constraint applies)>

RESTRICTIONS

<restriction expression (equality, inequality, set condition)>

Example Constraint Net: Consistency Between Engine Output and Fuel Type

CONSTRAINT ENGINE_FUEL_COMPAT

CONDITION

$self.ENGINE_OUTPUT IS NOT INITIAL

AND $self.FUEL_TYPE IS NOT INITIAL

RESTRICTIONS

( $self.FUEL_TYPE = ‘DIESEL’

AND $self.ENGINE_OUTPUT >= 100 )

OR

( $self.FUEL_TYPE = ‘GASOLINE’

AND $self.ENGINE_OUTPUT IN [80, 100, 120, 150, 200] )

This constraint net enforces bidirectionally the rule that “if diesel, output must be 100 kW or more; if gasoline, output must be only 80/100/120/150/200 kW.” Whether FUEL_TYPE is selected first or ENGINE_OUTPUT is selected first, the SCE verifies the consistency of both.

Table Conditions in a Constraint Net

This feature greatly improves readability by defining complex combination rules as a “table (Characteristics Table)” rather than writing them in code.

CONSTRAINT VALID_COMBINATIONS

RESTRICTIONS

TABLE (

$self.VOLTAGE, $self.FREQ, $self.REGION

100, 50, ‘JAPAN’

100, 60, ‘US’

220, 50, ‘EUROPE’

240, 50, ‘UK’

)

This table condition defines the valid combinations of “voltage, frequency, and region” in a list. The SCE automatically treats any combination not present in this table as invalid.

Activating the Constraint Net (Enabling SCE in CU41)

For a constraint net to function, “SCE Usage” must be turned ON in the configuration profile (CU41). When SCE is enabled, all constraint nets are evaluated continuously throughout the configuration session. Because a large number of complex constraint nets affects response performance, it is important to design so as to minimize the number and complexity of constraint nets.

7. Simulating and Verifying Configuration

CU50: Configuration Simulator

CU50 is a tool for testing the settings of a VC model. It allows you to verify configuration behavior without creating an actual sales order or production order.

CU50 Operating Procedure

• Launch: Run CU50 → enter the material number (KMAT) and configuration profile → “Execute.”

• Entering characteristic values: The configuration screen is displayed. Enter/select a value for each characteristic. Check the behavior of dependencies (preconditions, actions) in real time.

• Checking the BOM explosion: Use “Extras → Edit BOM” to check the BOM line items resulting from configuration (only the valid line items). Only the line items from the super BOM that match the selection conditions are shown.

• Checking the routing: Use “Extras → Edit Routing” to check the routing resulting from configuration (only the valid operations).

• Checking the price: Use “Pricing” to check the calculation result of the configuration price (the price differential from variant conditions).

Completeness Check

The “Completeness Check” determines whether a configuration is complete (whether values have been entered for all mandatory characteristics).

• All characteristics for which the “Entry Required” flag in CT04 has been turned ON must be filled in.

• If a configuration is “Incomplete” on a sales order (VA01) or an MTO production order, downstream processes (schedule confirmation, shipping) may be blocked in some cases. Designing the completeness-check logic requires confirming consistency with the business process.

Debugging Dependencies

This section shows how to debug dependencies that are not behaving as expected.

• The “Log” display in CU50: You can check the execution log of the dependencies, preconditions, and actions evaluated during configuration execution. This lets you trace which dependency was evaluated and which value was set automatically.

• CU99 (dependency consistency check): A transaction that batch-checks the entire VC model for dependency syntax errors and reference errors (such as references to non-existent characteristics). Run it periodically to maintain model integrity.

• CU70 (dependency list display): Lists all dependencies assigned to a specific characteristic, class, or material. Used to check for missing or duplicate dependency assignments.

8. Integration of VC and SD (Order Processing)

The Sales Order Configuration (VA01) Flow

When a KMAT material is entered in a sales order (VA01), the configuration screen opens automatically. The person in charge selects characteristic values, and once configuration is complete, the following processing runs automatically.

• Generating the configured BOM: A “configured BOM,” containing only the line items from the super BOM that match the selection conditions, is stored in the sales order item.

• Calculating the configuration price: Option price differentials based on variant conditions (the SD condition technique) are automatically added to the order price.

• Saving configuration characteristic values: All selected characteristic values are stored in the configuration table (CUOV) of the sales order item.

Setting Up Variant Pricing

VC pricing is based on the SD condition technique. The setup procedure is shown below.

Step 1: Defining the Variant Condition Type (V/VC)

IMG → Sales and Distribution → Basic Functions → Pricing → Pricing Control → Maintain Condition Types. Use the standard condition type “VA00 (variant price surcharge),” or create a custom condition type.

Step 2: Setting Up the Condition Table

The condition table for a variant condition has a key composed of the combination of “configurable material number + characteristic + characteristic value.” Create the condition table in IMG → Sales and Distribution → Variant Configuration → Pricing → Variant Pricing. Adding VC characteristics as key fields in the condition table requires setting up “characteristic reference fields.”

Step 3: Creating Condition Records (VK11/VK12)

Create the variant condition record in VK11. Enter the “KMAT material number, characteristic name, characteristic value, and price differential (surcharge or discount).”

• Example: KMAT = ENGINE_V8, characteristic COLOR = RED → price differential +50,000 JPY

• Example: KMAT = ENGINE_V8, characteristic TURBO = YES → price differential +350,000 JPY

Configuration and ATP (Delivery Date Confirmation)

After a KMAT is configured on a sales order, an ATP (Available to Promise) check is executed according to whether it is MTO (make-to-order) or MTS (make-to-stock).

• For MTO (Make-to-Order): Rather than an ATP quantity, a scheduled confirmation date is calculated based on the manufacturing lead time (the accumulated operation times of the routing). The operation times of the configured routing directly affect the lead-time calculation.

• For MTS (planned production): Component stock and planned receipts for the configured BOM are planned via MRP. Inventory is not managed at the KMAT level (a KMAT does not carry stock); inventory is managed at the level of the exploded component parts.

9. Integration of VC and PP (Manufacturing)

Configuration in the Production Order

In MTO production, the configuration is carried over from the sales order item to the production order. The configuration values (characteristic values) from the sales order are copied into the production order’s configuration (CUOV), and are used to evaluate the selection conditions of the super BOM and super routing during BOM explosion and routing retrieval for the production order.

VC Behavior During BOM Explosion (CO01/CO41)

When a production order (CO01) is created, or when a planned order (MD16/CO41) is converted, the super BOM is exploded. At this time, “matching of the configuration values against the selection conditions” is performed, and only the valid line items are pulled into the production order components (AFKO/AFPO/RESB).

• Resolving alternative materials: When alternative material groups are set up in the super BOM, alternative materials are resolved according to priority. Automatic selection of alternative materials that takes into account stock levels and MRP procurement status has been improved by functional enhancements from S/4HANA 2020 onward.

VC Behavior During Routing Retrieval

The super routing is retrieved when the production order is created. The selection condition of each operation is matched against the configuration values, and only the valid operations are pulled into the production order operations (AFVC). Operations without a selection condition are always pulled in.

Reconfiguration in the Production Order

Care is required for “reconfiguration” when a specification change occurs after a production order has already been created. Changing the configuration values in CO02 (change production order) re-triggers the BOM explosion and routing retrieval. However, the treatment of “components already issued” or “operations already confirmed” requires case-by-case operational judgment. As a general rule, configuration changes should be avoided as much as possible after manufacturing has begun; if a change is necessary, it is recommended to cancel the production order and create a new one.

10. AVC (Advanced Variant Configuration): Technical Details

Architectural Comparison of AVC and Classic VC

AVC (Advanced Variant Configuration) is the next-generation VC engine provided from S/4HANA 1709 (2017) onward. The data model is shared with classic VC, but the processing engine and UI have been overhauled.

• Difference in engine: Classic VC uses the ABAP-based VC processing engine (LCU*/LVC* function modules). AVC runs on a CDS/HANA-native engine that fully exploits HANA’s in-memory processing. The performance difference is pronounced for large constraint nets and complex product models with many characteristics.

• Difference in UI: Classic VC uses an SAP GUI-based configuration screen. AVC uses the Fiori-based “Product Configuration UI” (app ID: F3483).

• PMEVC: Product model management for AVC is done in the PMEVC (Product Modeling Environment for Variant Configuration) app (Fiori). Characteristics, classes, dependencies, and constraint nets can all be managed through a GUI editor.

Deciding Whether to Migrate to AVC

Below are decision points for whether to migrate an existing classic VC system to AVC.

• Cases where migration is recommended: The constraint net is large (more than 100 constraints); performance problems occur with complex configuration calculations; you want to offer customers and staff a configuration experience using the Fiori UI.

• Cases where migration is unnecessary or can be postponed: Classic VC has no performance problems and operations are running stably; the VC model is relatively simple (fewer than 20 characteristics, fewer than 50 dependencies); the S/4HANA version is earlier than 1709 (not supported for AVC).

• Points to note during migration: Because the data model itself (characteristics, classes, super BOM, etc.) is shared between AVC and classic VC, the migration effort is relatively small. However, since dependency syntax differs in some respects (some Procedure syntax is deprecated in AVC, and constraint net syntax has changed), checking and fixing the AVC compatibility of existing dependencies is required. Perform the compatibility check using the CU99-equivalent tool in AVC.

LKPM and Global Characteristic Change Management

LKPM stands for Lokal Klassifizierung/Produktion Modeling (literal translation), a function for bulk-changing and analyzing characteristic values of configurable products across the entire production volume.

• Use case: Bulk identification and change handling for all sales orders and production orders that have a specific characteristic value (such as an option that is being discontinued). Used when bulk-evaluating and addressing the impact on existing orders after a mass-data VC model change.

11. VC Customizing Settings (SPRO Details)

SCE Parameter Settings

IMG path: “SAP NetWeaver → Application Server → Basis Services → Classification System → Settings”

• SCE timeout: Sets the maximum time (in seconds) for the SCE calculation of a constraint net to complete. If timeouts occur with complex models, this value can be increased, but a balance with response performance is needed. The default value is 30 seconds.

• SCE recursion depth: The upper limit on the number of inference recursions for a constraint net. This is a guard value to prevent infinite loops (circular reference constraints). The default value is 100.

Core Settings for Variant Configuration

IMG path: “Logistics – General → Variant Configuration”

Setting the Configuration Enable Flags

• “Basic Settings”: Sets basic VC parameters (the pricing method, the completeness-check method, and the copy behavior of configurations).

• “Define Configuration Key”: Sets the generation method for the “configuration key” (a hash generated from the combination of characteristics) that determines the uniqueness of a configuration. Sales orders and production orders with matching configuration keys are regarded as the same configuration and can be consolidated into a single production order.

Integrating Variant Price Settings

• IMG path: “Sales and Distribution → Basic Functions → Pricing → Variant Configuration Pricing”

• The most important setting is “Characteristics for Conditions,” which adds a characteristic as a field of the condition table. Without this setting, VC characteristics cannot be used as pricing condition keys.

• Procedure: Confirm that the target characteristic (CT04) is “already assigned to class type (KLART) 300” → “Assign Characteristic to Condition Table” → register the characteristic name as a field name in the condition table → it then becomes selectable when entering condition records in VK11.

Class Search Settings

IMG path: “Logistics – General → Classification System → Search Settings”

• Settings for the search index when there is a large number of class type 300 objects. In large-scale environments, managing the schedule for rebuilding the index is necessary.

12. Common Configuration Mistakes and Troubleshooting

Dependencies Do Not Work

• Check 1: Is the dependency correctly assigned to the characteristic/fixed value (verify in CU70)? The most common mistake is “creating a dependency but not assigning it.”

• Check 2: Check for dependency syntax errors in CU99. If there is a syntax error, the dependency is treated as invalid.

• Check 3: In the case of a precondition, is the characteristic itself assigned to the configuration class (verify in CL02)?

• Check 4: Is the correct class specified in the configuration profile (CU41)?

A BOM Line Item Is Not Selected / Is Always Selected

• Check 1: Is the syntax of the BOM line item’s selection condition correct (verify in CU99)?

• Check 2: Is the spelling and case of the characteristic name referenced in the selection condition accurate (characteristic names must match exactly)?

• Check 3: Does the BOM usage match the “BOM Application” of the configuration profile? If the usage does not match, the super BOM is not referenced.

• Check 4: Does the plant of the BOM match the production plant of the production order/sales order?

Configuration Price Is Not Calculated

• Check 1: Has the variant condition record been created in VK11?

• Check 2: Is the condition type (such as VA00) incorporated into the pricing procedure for the order type (OVKK/V/08)?

• Check 3: Is the target characteristic mapped in the IMG setting for “Characteristics for Conditions”?

SCE Timeout Error

• Symptom: An “SCE computation timed out” error during configuration.

• Countermeasure 1: Increase the SCE timeout value (IMG setting).

• Countermeasure 2: Review the number and complexity of constraint nets. Remove unnecessary constraints and circular-reference constraints.

• Countermeasure 3: Properly configure the CONDITION clause within constraint nets so that unnecessary constraint evaluations are skipped.

• Countermeasure 4: Use CU50’s “Log” mode to identify and optimize the constraints that are taking a long time to process.

A Material Is Not Selected at a Class Node

• Check 1: Are candidate materials assigned (CL20N) to the class specified at the class node?

• Check 2: Do the characteristic values (classification) of the candidate materials match the selection condition? Material selection at a class node automatically selects “candidate materials whose classification characteristic values match the characteristic values of $parent.”

13. Operational Design for Large-Scale VC Models

Documentation Management for the VC Model

The VC model (characteristics, classes, dependencies, super BOM, super routing) is continuously updated as product design evolves. Documentation management and change management for the model are essential to the stable operation of a large-scale VC implementation.

• Dependency catalog: Manage a list of all dependencies (preconditions, actions, constraint nets) along with their purpose and related characteristics, in Excel, Confluence, or similar tools. Also leave appropriate comments (which can be written with /* */) in the dependency text within the SAP system itself.

• List of test scenarios: Create a “list of VC test scenarios” that records representative combinations of valid configurations along with the expected BOM, routing, and price. Use this for regression testing after VC model changes.

• Change process: VC model changes must always pass through the transport path of “development tenant → quality assurance tenant → production.” Direct entry of dependency or super BOM changes into production is absolutely prohibited. Use Customizing transports (S/4HANA’s transport management) for transports.

Cleaning Up Large Volumes of Configuration Data

In systems that have been running for a long time, configuration data for sales orders and production orders (tables such as CUOV) accumulates.

• Archiving: Archive configuration-related tables using SAP Data Archiving (SARA). VC data is also deleted in conjunction with the archiving of sales orders and production orders.

• Cleaning up orphaned configurations: There are cases where VC data remains even after the corresponding sales order or production order has been deleted. Periodic data quality checks (via a custom ABAP report or an SAP standard cleanup program) are recommended.

End of document