Writing your own SAP-to-CPQ rule parser might feel like a smart shortcut - until it isn’t.
It starts off fine: a few if-statements, some basic precondition translations, maybe a CSV dump from SAP. But before long, your “quick script” turns into a maintenance nightmare. SAP’s constraint logic wasn’t made for easy parsing, and Tacton CPQ’s constraint solver works very differently. If you're serious about migrating rules from SAP VC/AVC to Tacton CPQ, you need a real strategy - and real tooling. In this post, we break down how to convert constraints properly and avoid the traps that come from doing it by hand.
One of the first mistakes we see is teams building their own translators. It’s tempting. The rules seem simple at first, and writing a parser sounds like a fun challenge. But SAP preconditions are rarely clean. You’ll quickly run into nesting, alternative expressions, legacy structures, and syntax variations. Add to that SELECTED() logic and outdated rules still active in the system, and you’re stuck maintaining something fragile and bespoke.
Instead, use a full parser generator - something like Antlr, Bison or Yacc. These tools let you create a formal grammar for SAP rules and translate them into abstract syntax trees (ASTs). From there, you can traverse the tree and systematically generate the equivalent Tacton constraints. It’s a more complex setup, but it pays off in the long run: it’s reusable, scalable, and testable.
Let’s use a truck example. Suppose the SAP precondition for Sleeper Cab A is:
SELECTED(CHASSIS) AND CHASSIS EQ XL
You might be tempted to write this in CPQ as:
sleeper_cab = A -> chassis = XL
That works technically - but not optimally. In Tacton CPQ, this kind of logic is better handled through class structure. Instead of using a constraint, define chassis as a feature of the sleeper cab class. This moves the logic to the right place: into the class structure where the solver can evaluate it earlier and more efficiently.
Why does this matter? Because constraints that fail late in the configuration process can cause performance problems and poor user experience. The CPQ solver is powerful, but it needs clean structure. Dumping dozens or hundreds of translated constraints into the solver slows it down and makes debugging hard.
Another common pattern is the SAP variant table. In SAP, these are used to define valid combinations of characteristics. In Tacton, the closest match is the combination class (also called a scenario class). These can be set up to filter options automatically. Add a few "equals" constraints to tie the feature values together, and the solver will take care of excluding invalid combinations.
For example, instead of a long list of preconditions for each cab-chassis match, you could build a combination class that says:
Add a constraint like cab.chassis = chassis and you’ve already improved maintainability and performance.
A final point: don’t assume SELECTED() is needed in CPQ. In SAP, SELECTED() prevents invalid options from appearing too soon in the UI. But Tacton CPQ always assigns values during configuration - even before the user clicks anything. That means the SELECTED() condition is always logically true. Including it may not break anything, but it’s unnecessary and could confuse anyone maintaining the model.
This post isn’t a full parser tutorial, but the key idea is this: Tacton CPQ has its own way of doing things. If you try to mimic SAP logic line-for-line, you’ll end up fighting the system. Structure your models for CPQ from the start - use features, combination classes, and let the solver do its job.
In the next post, we’ll look deeper at how to handle SAP variant tables and how they map to combination classes in Tacton - along with a few tricks to reduce constraint clutter even more.
Considering automating your SAP model conversion?
Book a session with Magnus or Patrik and get expert input before you invest in the wrong tools. https://www.cpq.se/meetcpqse
Read more about Tacton modelling here:
https://www.cpq.se/the-cpq-blog/tacton-studio-modeling