Multi-Value to Pricing: Filtering and Transforming VC Characteristics for Condition Records

The Problem

You have two characteristics:

• MB: a multi-value characteristic that receives values during configuration via object dependencies or by user input
• MK: a referencing characteristic linked to MM pricing variant condition field MMCOM-VKOND

The requirement: from the values assigned to MB, extract only those meeting a specific condition, add a prefix and/or suffix to each qualifying value, then assign the transformed values to MK for pricing lookup.

Concrete example:

• MB values after configuration: V00100, V00200, ..., V02000
• Condition: only values found in a whitelist (maintained in a variant table)
• Transformation: prefix = P_, suffix = _S
• Result on MK: P_V00200_S, P_V00700_S, ... (only whitelisted values)

Each value on MK triggers a separate condition record lookup in MM pricing.

Note: check the length of the values on MK, as they must match MMCOM-VKOND length (26 characters typical).

The Constraint Solution

The cleanest approach is a single constraint, not a procedure. It works identically in LO-VC and AVC.

Variant Table as the Filter

First, create a variant table (tbl_scope) that defines which values qualify. For example:

Table: tbl_scope
Input: MB (CHAR 18)

Populate it with the values that should generate pricing condition records (e.g., V00200, V00700, V01500).

This is the whitelist. Maintain it in CU60: no dependency code changes needed when adding/removing values.

Constraint Code

OBJECTS:
COMP IS_A (300) COMP_CLASS WHERE
MK = TXT_PO_PRICING_KEY;
MB = TXT_BOM_ITEM

CONDITION:
COMP.TXT_REF_PLANT = '1010'

RESTRICTIONS:
MK = 'P_'|| MB ||'_S'
IF 
table tbl_scope( inputChar = MB )

How it works:

1. OBJECTS: Declares COMP (class COMP_CLASS) with two aliases:
   • MK → maps to TXT_PO_PRICING_KEY (the referencing char for pricing)
   • MB → maps to TXT_BOM_ITEM (the multi-value source char)
2. CONDITION: Constraint only triggers when the plant characteristic equals '1010'
3. RESTRICTIONS: MK is restricted to 'P_' || MB || '_S' if MB exists in tbl_scope

The Constraint Engine Does the Iteration

This is the key principle: there is no loop construct in constraint syntax. Neither LO-VC nor AVC constraints have loop syntax or explicit iteration keywords. Yet the constraint handles multi-value characteristics correctly without any loop code.

The constraint engine evaluates RESTRICTIONS for each valid combination of characteristics in the OBJECTS clause. When MB is multi-value (say 20 values), the engine:

1. Takes MB value 1, checks tbl_scope: if found, adds 'P_V00100_S' to MK's valid domain
2. Takes MB value 2, checks tbl_scope: if not found, skips
3. Takes MB value 3, checks tbl_scope: and so on for all 20 values

This is not a loop that you write. It is the fundamental behavior of the constraint solver: it enumerates all characteristic value combinations that satisfy the constraints. Multi-value processing is built into the engine, not added as a syntax feature.

Compare with procedures, which execute exactly once and need explicit loops to process multiple values. Constraints already had it from day one, in both engines.

If MB has values V00100 through V02000, but only V00200, V00700, V01500 are in tbl_scope, then MK ends up with three values: 'P_V00200_S', 'P_V00700_S', 'P_V01500_S'. No loop. No index tracking. Just declarative restriction.

Concatenation Note

In SAP VC dependency syntax, || is the string concatenation operator. It works in constraints, procedures, preconditions, and selection conditions:

'Alpha' || 'Beta'  →  'AB'

+ is arithmetic addition, not concatenation. If MB is character type, 'P_' + MB would produce a type mismatch error.

Source: Dependency Syntax: General Rules, LO-VC 4.6C Official Documentation, p.156-163

Why a Constraint Instead of a Procedure

Aspect	Constraint	Procedure
Multi-value processing	Built-in — engine evaluates all value combinations	Needs enumerate each value since there is no loop syntax
Filter logic	Data-driven via variant table — change table, not code	Hardcoded conditions in procedure body
Engine compatibility	Identical in LO-VC and AVC	no loop syntax
Value type	Domain restriction (hard assignment)	Hard assignment (can be overwritten by later proc)
Maintainability	Update variant table in CU60	Edit dependency source in CU02/PMEVC

The constraint shifts the filter logic from code to data. To add or remove a qualifying MB value, you maintain the variant table: no dependency change, no transport if it's a customizing table.

Key Considerations

1. Multi-Value referencing characteristic MK

MK must be defined as multi-value because it needs to carry more than one condition key.

2. Variant Table Design

The filter table (tbl_scope) only needs one input column: the MB characteristic's data type and length. The TABLE call in RESTRICTIONS is an existence check: it returns true if an entry exists where inputChar equals the current MB value.

Procedure IF variant (same existence check):

IF table tbl_scope( inputChar = MB )

Source: Verified by implementation project, 2026-06-03. TABLE in procedure IF confirmed as valid LO-VC syntax.

3. Condition Table Design

The condition table that MK references must:

• Include the MK field in its key
• Be assigned to the correct condition type
• Support multi-value condition records (standard: each distinct MK value triggers a separate pricing access)

4. Execution Order

The MB characteristic (TXT_BOM_ITEM) must already have its values before the constraint evaluates. If MB values come from another procedure, ensure that procedure runs in the same configuration profile, ordered before this constraint's CNET.

In CU41, procedures in the profile execute in definition order. Constraints are evaluated concurrently, so they see whatever values are already assigned.

Summary

Detail	Value
Approach	Single constraint with variant table as whitelist filter
Syntax	OBJECTS...CONDITION...RESTRICTIONS with TABLE existence check
Concatenation	'P_' || BOM || '_S'
Filter mechanism	Variant table existence check in RESTRICTIONS
Key prerequisite	MK must be multi-value; variant table must exist
Engine	Works identically in LO-VC and AVC
Maintenance	Add/remove qualifying values via CU60 table maintenance

This pattern appears in pricing-heavy VC models where multiple condition records need to be generated from an intermediate multi-value characteristic. The constraint approach keeps the logic declarative, data-driven, and engine-compatible.