Configurator problems
Configurator faults have a small number of causes and a large number of symptoms. Work from the symptom the buyer reported, not from the rule you suspect.
Symptom to cause
| Symptom | Most likely cause | Where to look |
|---|---|---|
| "No valid configuration" from the start | Two rules contradict each other, or a required group has no reachable option | Your rule table |
| The buyer gets stuck partway, with every remaining option greyed out | A rule chain narrows to nothing from a legal state | The last option they chose |
| An option disappears with no explanation | A visibility rule fires without a reason text | The only-if rules |
| The price is right in the configurator and wrong on the order | Two price build-ups: one in the storefront, one at cart | The order line's unit_price |
| The price is wrong for one customer only | The contract discount applies to a different layer than expected | Check which price a buyer sees |
| The price jumps oddly at a specific value | A quantity surcharge rounding at the wrong step | The per-unit rule |
| An option is chosen that the buyer did not choose | An implies rule doing what it was written to do, invisibly | The auto-set rules |
| Production received the wrong specification | The payload did not reach the ERP, or an option was silently dropped | Monitor your syncs |
| The order document says only the model name | position_text not filled on the line | The order line |
No valid configuration
The most common and most damaging fault: the buyer cannot get to a price.
Reproduce it from a clean state. Open the configurator with defaults and change nothing. If it is already invalid, the defaults themselves violate a rule — which happens whenever a rule is added and the defaults are not re-tested. That is the first thing to check on every rule change.
Then bisect. Reproduce the buyer's path, one choice at a time, and note the choice at which the remaining options collapse. Nine times out of ten the fault is the rule attached to that choice.
Look for the loop. Rule 1 says A requires B. Rule 7 says B excludes A. Choosing A now demands B and forbids it. The configurator has entered a state it cannot leave, and there is no message that helps the buyer. Loops are almost always created by two people adding rules months apart, which is why the Why column in your rule table matters more than it sounds.
Wrong price
Work through the four layers in order, and stop at the first one that disagrees:
- Base price. Look it up directly in the price list. If the base is wrong, nothing downstream can be right.
- Option deltas. Add them by hand for the reported configuration. A missing delta shows up as a price that is too low — and low wrong prices are discovered by your margin report, months later, not by the customer.
- Quantity surcharges. Check the boundaries: the minimum value, the maximum, and one step either side of any threshold. Rounding faults hide there.
- Customer conditions. Confirm which layer the contract discount applies to. Base-only and total both look plausible and give different answers.
If the configurator and the order disagree for the same configuration, the fault
is not in the rules. Two build-ups exist and one of them is stale. The order
line's stored unit_price is the authoritative record of what the buyer agreed
to — investigate why the other number differs, and do not "fix" it by copying.
A price component is missing
A configuration prices as if an option were free.
- The option has no delta at all. Most likely: it was added to the group after the price table was filled. Check every option in the group has a value, including zero where zero is correct — an explicit zero and an empty field are different states, and only one of them survives review.
- The delta exists in one currency. A configuration priced in CHF falls back to no surcharge because only the EUR row was maintained.
- The delta is time-limited and expired. See Time-limited prices.
Rules that fire invisibly
An implies rule adds the bayonet adapter automatically. The buyer never chose
it, sees it on the invoice, and calls it an unrequested item.
The rule is correct; the presentation is not. Auto-set options must be visible in the configurator as chosen, with a reason — "included with the bayonet connection". If it appears on the order line and not in the configurator, somebody will get a credit note.
Before you change a rule
Rule changes are the highest-risk edit in this area, because they are cheap to make and expensive to get wrong.
- Write down which configurations the change is supposed to affect, before you make it.
- Re-test the defaults. Every time.
- Re-test your twenty real configurations, from the last twenty configured orders.
- Have the change reviewed by whoever owns the product, not by whoever administers the shop.
When it is not the configurator
Two faults look like configurator problems and are not:
- The ERP rejects the order. The configuration is valid; the mapping to your ERP's characteristics is incomplete. See Field mapping.
- The buyer cannot see the product at all. That is visibility, not configuration — see A product is not visible.
Next
- Build a configurator — the rule table these checks assume.
- Configure and order — what the order line should contain.