As your VC model grows, dependency naming becomes critical. A model with 50 dependencies is manageable. A model with 500 dependencies without naming conventions becomes impossible to maintain. The dependency name is the only identifier : make it tell you what the dependency does.
This guide covers naming conventions based on real production models.
Why Naming Conventions Matter
- Dependency names are the only identifier in CU50 traces : a good name means you know what failed without opening the dependency
- CUOB assignments show dependency names : a bad name means tracing which dependencies are assigned where is manual
- Support teams need to understand dependencies without the original modeler present
Recommended Naming Pattern
<TYPE>_<CATEGORY>_<SUB_CATEGORY>_<PURPOSE>
Type Prefixes
| Type | Prefix | Example |
|---|---|---|
| Procedure | PRO_ | PRO_CABIN_PANEL_CALC |
| Selection Condition | SEL_ | SEL_S400E_SHIM |
| Constraint | CONS_ | CONS_ELEV_SPB_ETO |
| Constraint Net | NET_ | NET_ELEVATOR_SPB |
| Precondition | PRE_ | PRE_ETO_REMARK |
| Quantity | QTY_ | QTY_TRAVEL_CABLE_ELV |
Category Codes
The category identifies which product family or component the dependency applies to:
| Category | Example |
|---|---|
| Product line | META, STD, PREM |
| Component group | CABIN, PANEL, SHIM |
| System | ELEV, ESCA |
| Module | SG, GR, 5A |
Sub-category
Further narrows the scope. For a procedure on a panel component:
PRO_5A_PANEL_CALC
Purpose
What the dependency does:
PRO_CABIN_WALL_PRICE → calculates cabin wall pricing
SEL_S400E_SHIM → selects the shim for model S400E
CONS_ELEV_SPB_ETO → validates SPB ETO constraints
Procedure Best Practices
Assign to the Configuration Profile
Procedures on the config profile run in a defined order. Procedures scattered across characteristics lose ordering guarantees.
Use the profile procedure list for all production logic.
Use Global Dependencies
| Local | Global | |
|---|---|---|
| Naming | System-assigned number (0001, 0002...) | User-defined name |
| Reusability | Tied to one object | Can be assigned to many objects |
| Best practice | Avoid | Use for everything |
Local dependencies are impossible to manage at scale.
Always Comment Your Code
($self.COLOR = 'Red') if $self.TYPE = 'Premium',
/* Premium models force red as standard color */
Use Parentheses for Group Conditions
($SELF.COLOR = 'Red', $SELF.SIZE = 'Medium') IF $SELF.TYPE = 'Standard',
Selection Condition Best Practices
Class-Level vs. Item-Level
Class-level selection conditions are easier to maintain (one change affects all items of that class). Use item-level only when individual BOM items need unique logic.
Keep Conditions Simple
Complex selection conditions with multiple AND/OR conditions slow down BOM explosion. If a condition gets complex, consider moving the logic to a procedure that sets an intermediate characteristic, then use a simple selection condition on that char.
Precondition Best Practices
Use constraints instead of preconditions when possible. Preconditions are attached to individual characteristic values. Finding all of them means checking every value of every characteristic. Constraints live in one place : the config profile dependency net.
General Rules
- Every dependency needs a comment explaining why it exists, not only what it does
- Use
?=for defaults,=for forced values : understand the difference - Do not use Actions (CU05) : obsolete. Use procedures with
=for the same effect. - Use dependency groups (SAP_PRICING) to separate pricing logic from configuration logic
- Regular CU50 regression testing: after any change, verify existing configurations still work
Sources: Based on real SAP VC project experience and SAP Help: Object Dependencies