SAE & SAP® – Data transfer and KMAT‑integration with the SAE variant platform
We explain in clear terms how SAE retrieves SAP data—in particular, configurable variant objects (KMATs)—from SAP S/4HANA and makes it usable in the SAE variant platform (SAE Developer) and in SAE CPQ.
Purpose & Benefits
The SAE DNA
SAE was developed based on the fundamental assumption that variant management and CPQ systems can only be successful in the long term if they are natively compatible with SAP data structures and support bidirectional exchange. Think of SAE as an interpreter who speaks SAP as their “native language.” This applies not only to terms (characteristic, class, condition type), but also to meaning and behavior: rules, fallbacks, validities, and approvals are not “recreated,” but understood in their logic and made usable in SAE.Translated with DeepL.com (free version)
IMPORTANT – Solution performance:
To ensure flawless functionality, SAE experts have developed their own variant solver engine in addition to the database structures – in short: the SAE variant engine.
This engine evaluates SAP KMATs and their relationship knowledge (LO-VC/AVC) outside of SAP extremely quickly and in full compliance with regulations.
Conventional, generic solvers or standard algorithms are not suitable for this purpose.
The VC algorithms used by SAP to process rule objects are highly specific and have nothing in common with standardized solver logic. This is the crucial difference in the CPQ market:
It is not the same thing to simply load SAP variants and rule objects into a platform in order to laboriously recreate or adapt them there – or to execute them directly in an engine developed for this purpose that completely reproduces SAP behavior.
Numerous projects that previously failed without an SAP-specific solver were subsequently successfully implemented with the SAE variant engine.
This clearly confirms that project success is not achievable without powerful, SAP-compliant solver technology.
These projects often end up with us – and we lead them to success with the SAE Variant Engine.
Your practical benefits: Teams do not need to relearn or maintain data twice.
Changes in SAP remain the source of truth, and SAE ensures that they are transferred to sales quickly, correctly, and transparently.
Architecture overview
Overview of the components
SAP S/4 HANA (including AVC/LO-VC)
Source for KMAT models, pricing logic, master data, parts lists, and work plans
SAE variant management platform
Consists of the main modules SAE Developer and SAE CPQ.
SAE‑Interface‑Cockpit (SAE‑IC)
Integration module for extraction, mapping, validation, and delta synchronization embedded in SAP.
SAP Business Technology Platform (BTP)
Secure and scalable integration layer for data exchange, orchestration, and services.
SAE
Developer
Central variant modeling and management application (versioning, release management, organizational contexts).
SAE CPQ
Configure Price Quote
Quotation/order configuration, price determination, document generation, and transfer to downstream systems.
The data flows (simplified representation)
Extraction in SAP (SAE‑IC)
Selection of relevant objects and rules; technical preparation for download to the SAE variant management platform, the SAE Developer module.
Transport via SAP BTP
Secure, scalable transfer to the SAE variant management platform.
Release to SAE CPQ
Sales staff can concentrate on consulting and building customer relationships.
Feedback to SAP (via SAE-IC & SAP BTP)
Transfer of the complete, SAP-compliant configuration to SD documents – regardless of whether they are quotations or sales orders. In addition, condition types are transferred according to the calculation schema. Optionally, additional sales, production, and/or project structures can be created/updated (e.g., multi-level customer order bills of material, work plans for production, network plans, and WBS elements, right through to project processing).
KMAT data from SAP, with LO-VC/AVC
A sales representative configures a machine.
The feature selection restricts the options via rules, quantities in the BOM/work plan are automatically adjusted, and prices are determined according to access sequences. Everything is based on data that was previously retrieved from SAP via SAE-IC and versioned in Developer.
After approval, CPQ generates the quote; upon acceptance, the configuration, including condition types, is written back to the SD document.
No KMAT in SAP, no LO-VC/AVC
All objects for variant configuration are now set up in SAE Developer. After the variant model has been released for the respective sales channels and countries, the sales representative configures a machine in the same way as in example scenario 1, selecting the relevant characteristics and calculating the price.
In addition to sales bill of materials explosion, a technical bill of materials and work process explosion (MBOM, BOM) now takes place. All these “technical data objects” are transferred to the SAP system via SAE-IC and SAP-BTP as soon as a sales order is to be created from the quotation. The SAE-IC generates customer order BOMs and customer order work plans, project structures, etc. in SAP with all the necessary technical assemblies.
This allows the planning department to access this data (BOMs, work plans, etc.) without prior manual data maintenance in industrial engineering or AV and automatically generate production orders (FAUF), purchase requisitions (BANF), etc.
Data objects & coverage
Variant model (KMAT) and relationship knowledge
- Characteristics, characteristic values, classes (e.g., class type 300)
- Rules: preconditions, selection conditions, procedures, constraints, including associated tables
- Material master data (including relevant views)
Bill of materials & work plans
- Bill of materials (super BOM, configurable BOMs) including relationship knowledge (selection conditions, procedures) - e.g., rule-based quantity control.
- Work plans with configurable operations and rules (selection/modification of specifications such as machine or setup times)
Sales-related price & condition objects (SD)
- Calculation schema(ta) and condition technique
- Condition types, access sequences, key/price tables
- Hierarchical accesses (“fallback cascades”) – Example
1. Search in ATAB_V_M1 with (VKOrg=1000, Material=XYZ)
2. If not found → ATAB_M1 (Material=XYZ) → Controlled via the access sequence in SD Customizing.
Integration mechanisms
SAE‑Interface‑Cockpit (SAE‑IC) in SAP
- Selection & filter: Controllable by plant, sales organization, change status, validity, etc.
- Mapping & Transformation: Namespaces, Units, Domains.
- Validation: Consistency checks before export (e.g., referential integrity, mandatory values).
- Delta logic: Incremental updating, change documents, version comparison.
- Monitoring: logs, error handling, restarts.
- Data upload (SAE → SAP): In addition to extraction (SAP → SAE), SAE‑IC enables controlled and monitored data transfer to SAP, e.g., to automatically create/update complete SD documents with items (see “Data upload in SAP” for details on SD, production, and projects).
The SAE Interface Cockpit (SAE-IC) is a standalone software within SAP and does not require any modifications to the SAP standard. This means that the CleanCore approach is fully preserved – upgrades, patches, and maintenance procedures remain low-risk and compatible.
SAP BTP as an integration hub
- Secure transmission (AuthN/AuthZ, encryption), scaling, and orchestration.
- Services for events (eventing), queues, API management, logging.
- Extensibility: Embedding of customer-specific microservices/adapters.
Data uploading SAP (modules SD, PP, PS, etc.)
- SD documents: Transfer of fully configured KMAT items with document type quotation or sales order SD) – regardless of document type.
- Condition technique: Transfer of condition types to the SD costing sheet in the document.
- Manufacturing & Logistics: Creation/updating of multi-level customer order bills of materials and customer order work plans – eliminating the need for LO-VC/AVC in SAP (see example scenario 2 above).
- Project System (PS): Creation/updating of network plans, network structures, and WBS elements within the SD order structure for project processing.
- Technical path: Return via SAE‑IC and SAP BTP, consistent with the data flows described in 3.2.
Pricing logic in SAE-CPQ
Pricing logic
- Calculation schema as orchestrator of condition types.
- Access sequences define multi-level, hierarchical “lookup paths” to price tables.
- Condition types represent price elements (base price, surcharges/discounts, freight charges, taxes, etc.).
- SAE illustration: Reproduction of lookup cascades in SAE pricing, SAE CPQ module
1. CPQ transfers Material=XYZ, Sales Organization=1000, Customer Segment=IND.
2. SAE Pricing checks access sequence ZV01:
a) ATAB_V_M1 (Sales Organization+Material) → no match found.
b) ATAB_M1 (material) → hit: base price €12,450.
3. Surcharges/discounts (e.g., volume discount) are pulled as additional condition types with their own access chains.
Multi-leveling & instantiation
Mehrstufigkeit & Instantiierung
- Multi-level variant objects (configurable assemblies in hierarchical structures, including sales parts lists) are transferred in their entirety.
- Instantiation in SAE Developer with corresponding relationship knowledge for each configurable object (KMat) and hierarchy level ($Self, $Parent, $Root).
A plant KMAT consists of a main assembly (e.g., base frame) and subassemblies (drive, control, safety). Depending on the “operating environment” characteristic (indoor/outdoor, zone), the control system draws on other components; the safety level adds sensors; the drive selects the motor/gear ratio and in turn influences quantities in the bill of materials. SAE takes these interactions completely from SAP and displays them in real time in the configuration.
Release & Country Management
(SAE Developer → CPQ)
(1) SALES always works with the currently approved complete variant model (structure, rules, prices, documents).
(2) Customer-specific enhancements based on SAP variant data can be added in a targeted manner using the SAE Developer – e.g., additional restrictions via rules for specific countries or sales organizations (VKOrg). The basic functionality of the original SAP rules remains unchanged.
Always the latest releases for distribution
- Release objects: complete variant model including KMAT structure, relationship knowledge, pricing logic, texts/documents.
- Versioning: Clear statuses (e.g., R2025.10) are distributed to the CPQ module via the SAE Developer. This allows different configuration statuses to be performed in quotations.
- Approvals for rules, prices, parts lists, work plans, etc.
Extensions without changing the core rules
- High flexibility: Additive rules can be added in SAE Developer (e.g., selection restrictions, quantity limits, texts, additional prices - these are transferred to SAP as manual conditions).
- Unchangeability of the core: The SAP-based core ruleset remains semantically unchanged; extensions have an effect on top of it (no overwriting of the basic logic).
- Country A: Option Stainless Steel X not permitted for regulatory reasons → additive rule via SAE Developer.
- VKOrg 2000: additional regional surcharge; country-specific texts in documents.
- Customs/compliance: Restrictions on certain components or minimum requirements (e.g., IP protection class) depending on the region.
Governance, Quality & Safety
- Roles & Rights: Only authorized users may add localized rules in SAE Developer.
Clarity instead of complexity
Get started with SAE variant management today and take control of your variant diversity, product portfolio, and market.
Note: This article is intended to provide you with a concise overview. The content has been carefully compiled, but may be subject to change. Please consider the information provided as non-binding; for specific decisions, we recommend consulting your SAE contact.