Lesson 4 of 6
The transformation sequence and the congruence check
10 min
Listen to this lesson
SAP provides tools in SAP S/4HANA on-premise and Private Edition to transform LO-VC models into AVC models inside the same system. The approach is copy, not convert: the tools create new AVC versions of the dependency objects next to the classic ones, check them, assign them to the right parents, compare the results of the two engines, and only then release the AVC model. Until release, sales keeps using the classic model.
The tools
| Tool | Transaction | Purpose |
|---|---|---|
| Transition workspaces | VCH_L2A_WORKSPACES | Group the models to be transformed together into a work area, start the transition, open the work area in the workbench |
| Transition workbench | VCH_L2A_WORKBENCH | Check LO-VC objects, copy them to AVC objects, check AVC objects, assign them, start the comparison, release |
| Comparison | VCH_L2A_COMPARISON | Compare LO-VC and AVC results for a document such as a sales order item |
| Transfer of material variants | VCHMOVMVAR | Switch material variants of a transformed model to the AVC model |
| Modeling environment | PMEVC | Review the model, its AVC objects after release, and test (simulate) it |
SAP's transformation tools as described by SAP Learning and practitioner sources. Older tools such as VCHMOVCOMP and VCHMOVCOPY are obsolete and replaced by the workbench. Button names and options vary by release; verify in your system.
The sequence step by step
- 1. Define the work areaIn VCH_L2A_WORKSPACES, create a work area (for example WA-CHI-STD) and add the configurable materials that must move together
- 2. Start the transitionThe relevant objects (profiles, dependency nets, constraints, procedures, preconditions, selection conditions) move into the workbench
- 3. Check LO-VC objectsThe workbench reports constructs that AVC does not support or treats differently; fix them in LO-VC first, or plan to fix them in AVC
- 4. CopyNew AVC objects are created, with an AVC suffix by default; the classic objects stay untouched
- 5. Check AVC objects and assignConfirm that every object has an AVC counterpart and assign the new objects to their parents
- 6. CompareRun the comparison for test documents: the same input values through both engines, results side by side
- 7. ReleaseSet the model to Advanced; from now on new configurations use AVC
- 8. Move material variantsRun VCHMOVMVAR so the variants point to the AVC model
Most of the transformation buttons offer a simulation mode that reports problems without changing anything. Use it every time first. In CMD, Contoso ran each step in simulation, saved the log as evidence, fixed what it found, and only then ran the step for real.
| Object | Transformed? | Note |
|---|---|---|
| Configuration profile | Yes | Processing mode set to Advanced at release |
| Constraint nets and constraints | Yes | Copied as AVC objects |
| Procedures, preconditions, selection conditions | Yes | Copied; semantics may differ (lesson 2) |
| Materials, classes, characteristics | No | Shared master data, used by both engines |
| Variant tables | Not as a child object | Problems surface in the logs; may need data fixes, a new table or Mixed mode |
| Interface designs | No | Create characteristic groups manually in AVC |
What the tools transform. Source: practitioner description of SAP's transformation tools; confirm for your release.
The congruence check
The comparison is where the course title's congruence comes from. The idea is simple: feed the same characteristic values to both engines and compare the outcomes, value by value. Congruent means the AVC model produces the same valuation, the same consistency status and the same derived values as the LO-VC model. In the workbench, the comparison runs for documents, typically sales order items or simulation cases, and shows the differences.
Two cautions. First, the comparison covers the configuration result. It does not by itself prove the BOM explosion, routing selection, pricing, costing or MRP results; those are the subject of lesson 5. Second, a difference is not automatically a defect. AVC intersects domains more strictly than LO-VC in some cases, so AVC may legitimately refuse a combination that LO-VC accepted. Each difference needs a decision by someone who knows the product.
What would you do?
The comparison for WA-CHI-HD shows 40 differences, all in one characteristic, fan type. Kenji says the AVC result looks "more sensible" and proposes to release. What should happen?
What goes wrong in testing
| Pitfall | Consequence | Prevention |
|---|---|---|
| Comparing only new test cases | Real order patterns are never compared | Include recorded sales order items from the last year |
| Skipping simulation mode | A failed copy leaves half-created objects to clean up | Simulate every step, keep the log, then run |
| Accepting differences in bulk | "AVC is better" becomes the reason for 40 changes nobody traced | Trace each difference to a dependency and a decision |
| Re-running comparison after a fix only for the failed case | A fix to a shared object breaks another case | Re-run the full comparison set for the work area |
Typical comparison mistakes.
- Transformation copies dependency objects to AVC versions; classic objects remain until release.
- Use VCH_L2A_WORKSPACES for work areas and VCH_L2A_WORKBENCH for check, copy, assign, compare and release.
- Run each step in simulation mode first and keep the logs.
- The comparison proves configuration results only; every difference needs a cause and a decision.
Check your understanding · not graded
Lesson check
1. Which transaction groups models into work areas and starts the transition?
2. What happens to the classic dependency objects when the workbench copies them?
3. What does the comparison step prove on its own?
4. Which objects are NOT transformed by the tools?