SAP VC to Tacton CPQ – turn tables into powerful combination classes

If you’re copying SAP variant tables into CPQ as constraints, you’re doing too much work.

SAP’s variant tables are designed to manage valid combinations of characteristics. They work well in ERP, but if you treat them like line-by-line rule generators when moving to Tacton CPQ, you miss a huge opportunity. Tacton offers a more elegant solution: combination classes. In this post, we’ll show how to transform variant tables into powerful, maintainable CPQ logic that’s faster and easier to work with.

First, let’s clarify the difference.

In SAP VC/AVC, variant tables are used to define what combinations of feature values are allowed. For example, which engines are valid for a certain truck chassis, or what frame sizes work with specific lifting mechanisms. Each line in a variant table is a valid combination, and additional logic (preconditions, constraints) often ties them into the full model.

In Tacton CPQ, combination classes (also called scenario classes) serve a similar purpose - but with more flexibility. They don’t just list valid options. They can directly drive availability, logic filtering, and user guidance - all without extra constraints. That means less code and more clarity.

Let’s look at an example:

Imagine you have this variant table in SAP:

Traditionally, you might convert this into a list of constraints in CPQ:

(chassis = XL -> engine = E1 OR engine = E2)

(chassis = XXL -> engine = E2 OR engine = E3)

But this quickly gets messy - especially with more features.

Instead, create a combination class in CPQ that contains the valid combinations as rows. Then use a single constraint like:

combination_class.chassis = chassis

AND combination_class.engine = engine

This does all the heavy lifting. You’ve now encoded the valid combinations structurally, not through logic - making it easier to maintain and faster to evaluate.

It gets even better when you link features via “equals” constraints. For example, if the engine is determined by another user selection (say, regional compliance), you can add a constraint like:

engine = combination_class.engine

and let the solver figure out the rest.

One important tip: avoid duplicating constraints that are already implicit in the combination class. Many SAP models include preconditions like:

SELECTED(CHASSIS) AND CHASSIS EQ XL

attached to component E1, for instance. In CPQ, once you structure your model using combination classes and class features, you usually don’t need such conditions. The solver will only allow valid selections in the first place.

This approach also helps with model transparency. When your rules are buried inside hundreds of constraints, no one wants to debug them. But when your logic is stored as readable rows in a combination class, it’s easier to update, validate, and explain to your stakeholders.

At cpq.se, we often help manufacturers with this shift in thinking. Variant tables shouldn’t be ported over rule-by-rule - they should be translated structurally, using the full capabilities of Tacton CPQ. The result is a cleaner model, fewer errors, and a better sales experience.

In the next part of the series, we’ll look at another common mistake: leaving the modelling team out of the conversion project until it’s too late.

Need help planning your SAP-to-CPQ data conversion?
Magnus or Patrik can walk you through best practices in a short virtual session. Book now: https://www.cpq.se/meetcpqse

More insights on smart modelling here:
https://www.cpq.se/the-cpq-blog/tacton-studio-modeling