SAP Configurable Material Test Matrix Worksheet for Variant Configuration
Variant configuration changes have a nasty habit of breaking something far from the rule you edited. A test matrix gives you a repeatable set of configurations with expected results, so each dependency change can be proven. This worksheet records expected and actual BOM items and price and shows the differences.
| Test ID | Configuration tested | Expected BOM items | Actual BOM items | Expected price | Actual price | Item difference | Price difference | Result | Tested on | |
|---|---|---|---|---|---|---|---|---|---|---|
0 | $0 | |||||||||
0 | $0 | |||||||||
0 | $0 | |||||||||
-1 | -$550 | |||||||||
0 | $0 |
Run each configuration in configuration simulation (CU50) first, then in a sales order and a production order to confirm pricing and BOM explosion. Record negative tests too: a configuration that must be blocked is as important as one that must succeed.
Replay configurations automatically
Share how many models you maintain and we will describe an approach to repeatable configuration tests.
Optional. The tool and every export work without this. No spam.
How to use the worksheet
Create one row per configuration worth testing. Describe it in words that a business user understands, state how many BOM items and what price you expect, then run it and enter the actual values. The difference columns calculate themselves and the result column records pass or fail. Include invalid combinations, defaults-only runs and boundary values, and keep the sheet as your regression pack. After every change to dependencies, characteristics or BOMs, run the full list again.
- Cover every value of every driving characteristic at least once
- Include combinations that must be blocked
- Record the date and the tester for evidence
Where to test in SAP
Configuration simulation, started with CU50, lets you configure a material without creating a sales document, view the resulting values and check which dependencies fired. Next, test a sales order in VA01 to confirm pricing conditions that depend on characteristics, and a production or planned order to check BOM explosion and routing selection. Availability and planning behaviour, such as MRP for configured components, can be checked by running planning on the test orders. Each stage can reveal faults the earlier stage hides.
- CU50: values, dependencies, simulated BOM
- VA01: pricing and configuration in a sales order
- Production order: variant BOM and operations
Reading the results
A nonzero item difference means a selection condition is wrong: either an item is missing or an extra one appears. A price difference with no item difference points to variant condition records or pricing procedures rather than the BOM. Net totals close to zero can hide errors that cancel out, so read the individual rows. Count the fails by characteristic to find the area of the model that needs rework, and retest the whole matrix after a fix, not just the failed row.
Common mistakes
Teams usually test the happy path only, then discover blocked combinations were never blocked. Others test in simulation and skip the sales order, missing pricing faults. Expected results are often taken from the system output instead of from an independent source such as the product specification, which defeats the test. Keep the expected values derived from engineering and pricing documents, and record who confirmed them.
Frequently Asked Questions
Which transaction simulates a configuration?
CU50 is the configuration simulation transaction. It lets you select values, see which dependencies fire, and check the BOM explosion without creating a sales order. Use it as your first test stage.
How many test cases are enough?
There is no fixed number. Start by covering each value of each driving characteristic and each dependency in both its true and false state, then add boundary and invalid combinations. A model with many options needs a risk-based set rather than every combination.
Should I test pricing in the matrix?
Yes if pricing depends on characteristics. Record the expected price from your price list or pricing procedure, and compare it with the sales order result. A price gap without a BOM gap usually points to condition records.
Can I automate these tests?
Parts can be scripted, for example by using BAPIs to configure and read results or by using test automation tools. Whether it is worthwhile depends on how often the model changes. Many teams automate the stable core and test new rules manually.
If your regression packs run manually after every release, we can discuss generating and replaying configurations from your SAP data. The matrix itself does not need it.
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.
SAPSAP Object Dependency Syntax Template
Generate starter syntax for the four classic SAP dependency types from your own characteristic names and values.
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.
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.