SAP Object Dependency Syntax Template for Variant Configuration
Most variant configuration rules follow a few patterns, and people search for syntax examples every time they build a new one. This template produces starter code for a precondition, a selection condition, a procedure and a constraint skeleton from your own characteristic and value names. Copy the output into the dependency editor and adjust it.
Fill in
Precondition (value of ZPUMP_VOLTAGE)
* Dependency ZPUMP_PRE_01, created in CU01 as a precondition * Attach to the value 230V of ZPUMP_VOLTAGE so it is only offered when the rule is true not ( ZPUMP_MOTOR_KW = '55' )
Selection condition (for a BOM item or characteristic)
* Dependency ZPUMP_SEL_01, created in CU01 as a selection condition * Forces an answer: the object is only valid when the characteristic has a value ZPUMP_MOTOR_KW specified
Procedure (set a default or value)
* Dependency ZPUMP_PRC_01, created in CU01 as a procedure * Sets ZPUMP_SEAL to MECH when ZPUMP_MOTOR_KW is 55 $self.ZPUMP_SEAL = 'MECH' if ZPUMP_MOTOR_KW = '55'. * Optional default form, which the user may overwrite $set_default $self,ZPUMP_SEAL,'MECH'
Constraint skeleton
* Dependency ZPUMP_CON_01, created in CU01 as a constraint * Constraints belong to a dependency net (CU21) and reference class-based objects OBJECTS: PUMP IS_A (300) ZPUMP_VC CONDITION: PUMP.ZPUMP_MOTOR_KW = '55' INFERENCES: PUMP.ZPUMP_SEAL = 'MECH'
These are starting skeletons for the classic SAP VC dependency editor. Syntax details, such as the period that ends a procedure statement and the exact constraint keywords, must be verified in your release using the dependency editor syntax check in CU01. Test every rule in configuration simulation (CU50) before releasing it.
Review your dependency base
Share a dependency list and we will explain how an audit for conflicts and unused rules could work.
Optional. The tool and every export work without this. No spam.
How to use the template
Enter the driving characteristic and value, the characteristic you want to restrict, and the characteristic a procedure should set. The page substitutes your names into four standard patterns. Copy a block into the dependency editor in CU01, save, and run the syntax check. Then assign the dependency to a value, a characteristic, a BOM item or a configuration profile depending on its type. Always test the result in configuration simulation before it reaches a sales order.
- Change names and values only, keep the structure
- Run the syntax check in the editor every time
- Use a prefix so dependencies are easy to find in CU02
The four dependency types
A precondition controls whether a value or characteristic can be offered at all. A selection condition decides whether a BOM item, operation or characteristic is relevant for a specific configuration. A procedure derives values, for example setting a default or computing a quantity. A constraint is evaluated continuously within a dependency net and can infer values both ways, which makes it powerful but harder to debug. Choose the simplest type that solves the problem; most models should rely mainly on preconditions, selection conditions and procedures.
- Precondition: hide or allow a value
- Selection condition: include or exclude a BOM item
- Procedure: set or derive a value
- Constraint: model relationships inside a network
Reading and testing the result
A precondition like the one generated reads as a prohibition: the value is not offered when the driving characteristic has the stated value. A selection condition using specified becomes true once the user has answered the characteristic. A procedure runs when the model is evaluated, so a default set by $set_default can be overridden, while a direct assignment is stricter. Test each pattern with a value that should pass and a value that should fail, and record both in your test matrix so the behaviour is checked after every upgrade.
Common mistakes
The usual errors are logic that works for one value but not for another, missing parentheses around negated conditions, and procedures that overwrite what a user has already chosen. Dependencies are also left unassigned, so they exist but never fire. Large models accumulate overlapping rules that contradict each other. Keep dependencies small, one purpose each, and document the reason in the long text. Remove obsolete dependencies using change numbers so history stays clean.
Frequently Asked Questions
What is the difference between a precondition and a selection condition?
A precondition decides whether a characteristic or value can be offered. A selection condition decides whether an object such as a BOM item, operation or characteristic is relevant for the configuration. Preconditions affect what users can choose, selection conditions affect what is built.
Where do I create dependencies in SAP?
Dependencies are created and edited in the dependency editor, started from transaction CU01 to create, CU02 to change and CU03 to display. You can also reach the editor from the object, for example from a BOM item or a characteristic value.
Can I use constraints for everything?
You can, but you probably should not. Constraints are evaluated in a dependency net and can be hard to trace when they fail. Use preconditions, selection conditions and procedures for most logic, and keep constraints for relationships that genuinely need two-way inference.
Will this syntax work in Advanced Variant Configuration?
Not unchanged. Advanced Variant Configuration uses its own model and rule definitions, and classic dependencies are migrated or rewritten for it. Treat these examples as classic VC syntax and check current SAP documentation for the target release.
If you are moving a large dependency base to Advanced Variant Configuration, we can help review the rules and plan how to translate them. The template above stands on its own.
Related Tools
SAP Characteristic and Class Design Worksheet
Plan every characteristic, its data type, value list and owning class before you touch CT04. Exports to Excel for review with engineering and sales.
Engineering & PLMSAP Super BOM Design Worksheet
Lay out every component of a 150 percent BOM with its selection condition, quantity and cost, then see how many items are always present versus conditional.
SAPSAP Configurable Material Test Matrix Worksheet
Track each test configuration with expected and actual BOM item counts and price, so every dependency change is proven before release.
ERP Migration & SelectionSAP AVC Migration Checklist
A planning checklist for inventorying classic VC objects, preparing for Advanced Variant Configuration and proving the result before cutover.