Why AVC: performance, Fiori simulation and the end of classic VC

Variant configuration lets one material number stand for a whole product family. The customer picks values for characteristics such as voltage, output and pulley type, and rules called object dependencies decide which combinations are allowed, which components and operations the order needs, and which surcharges apply. Since SAP R/3, the engine behind this has been classic variant configuration, usually called LO-VC. In SAP S/4HANA, SAP added a second engine: Advanced Variant Configuration (AVC). This course is about moving models from the first engine to the second and proving that nothing changed that should not have.

A short reminder of the moving parts, which sap-pp-301 introduced: a configurable material (material type KMAT in the standard), a variant class (class type 300) holding the characteristics, a configuration profile that controls where and how the material is configured, a super BOM and super routing holding every possible component and operation, and dependencies that tie it all together. Both engines use the same master data: the same characteristics, classes, configuration profiles and dependency objects. What differs is how the dependencies are evaluated, which syntax they may use, and which user interface the user sees.

What AVC changes

Three reasons push customers toward AVC. First, strategy: SAP keeps LO-VC available in SAP S/4HANA on-premise and Private Edition in maintenance mode, which means no new functions or new process integrations; new variant configuration innovation goes into AVC, and SAP S/4HANA Cloud Public Edition offers only AVC. Second, user experience: the Fiori configuration UI shows the user which values remain possible after each choice, and the simulation environment shows the configuration, the BOM explosion and a dependency trace in one place. Third, performance and maintainability: a solver-based engine handles large constraint networks better, and new syntax elements remove workarounds that classic models needed.

Coexistence: the processing mode

Classic and advanced models can live in the same system. The switch is the processing mode in the configuration profile: Classic is the default for every existing model, and Advanced makes the high-level configuration of that material run in AVC. Dependency objects (dependency nets, constraints, preconditions, selection conditions and procedures) also carry a processing mode. Low-level dependencies on BOM items and routing operations keep running in classic mode: SAP Learning notes that BOM explosion considers only classic dependency knowledge. This coexistence is what makes a model-by-model transformation possible.

Contoso's starting point

Contoso's ECC system (EP1) contains a small LO-VC portfolio at plant 1720 Chicago: the configurable aftermarket alternator family CMC-ALT-900 and 13 related configurable materials (illustrative course data). The brownfield conversion carried these models across unchanged, because LO-VC works in SAP S/4HANA. A year after go-live, two things force a decision. Engineering wants to model the heavy-duty 24 V alternator CMC-ALT-240 as a configurable product for Detroit, and the team does not want to build a new model on an engine in maintenance mode. And the Chicago models have a growing list of workarounds that AVC syntax would remove. The plant manager asks: transform now, or later?

What goes wrong in testing

• Testing the UI instead of the rules. Testers new to the Fiori configuration UI log layout complaints as defects and miss changed domains. Separate UI feedback from rule results in the defect log.
• Assuming "same master data" means "same result". Shared characteristics and dependencies are exactly why people skip comparison; evaluation still differs.
• Forgetting low-level dependencies. Teams test the header configuration in AVC and forget that BOM and routing selection still run classic logic, which must be tested in the same cycle.