What Is Planned For The 2608 Release Of SAP Varian...

The 2608 release of SAP Variant Configuration and Pricing is planned to be deployed to BTP customer tenants on July 22, 2026:

Administration UI and Administration service:

Release	Test/Non-Productive & Productive Upgrades
2608	July 22, 2026

Variant Configuration service & Pricing service:

Release	Test/Non-productive Upgrade	Productive Upgrade
2608	July 22, 2026	August 12, 2026

This blog covers the following planned innovations:

Configuration and Pricing Services – New Data Center: Azure US West (Washington) (cf-us20)
Configuration and Pricing Services – Extension Concept – Cache Database Queries in Local Extensions
Configuration and Pricing Services – OpenAPI Specification Upgrade
Pricing service – Extension Concept – Custom Formula Execution During Group Condition Processing
Pricing service – Expose Scale Base Information and Group Condition Indicator
Pricing service – ReadOnly Changed Document Items
Variant Configuration service – New AVC-Aligned Mode (Beta)
Variant Configuration service – Additional Filter Attribute for Field Knowledge-base Schema
Variant Configuration service – Class Node Specialization Improvement
Administration and Data Replication – Modern Administration User Interface

It also includes a call to act regarding the following changes:

Configuration and Pricing Services – Extension Concept – Cache Database Queries in Local Extensions
Configuration and Pricing Services – OpenAPI Specification Upgrade

Please check the updated Roadmap and Release Notes after the release date to see which of these features were delivered as planned.

Disclaimer

The information in this presentation is confidential and proprietary to SAP and may not be disclosed without the permission of SAP.
Except for your obligation to protect confidential information, this presentation is not subject to your license agreement or any other service or subscription agreement with SAP. SAP has no obligation to pursue any course of business outlined in this presentation or any related document, or to develop or release any functionality mentioned therein.
This presentation, or any related document and SAP's strategy and possible future developments, products and or platforms directions and functionality are all subject to change and may be changed by SAP at any time for any reason without notice. The information in this presentation is not a commitment, promise or legal obligation to deliver any material, code or functionality. This presentation is provided without a warranty of any kind.

SAP Variant Configuration and Pricing continues to expand its global availability with the introduction of a new Azure data center in US West (Washington) (cf-us20).

This new option allows customers with new contracts to deploy their tenants in an additional Microsoft Azure region, complementing the existing global footprint across AWS and Azure regions.

Key aspects to consider:

All tenants of a customer must run in the same data center.
Mixing infrastructure providers is not supported.
Existing tenants cannot be moved across regions or providers.

This ensures operational consistency while offering increased flexibility for new implementations.

Local extensions can read data from custom database tables via sap.db().execute(). In scenarios where the same extension is called repeatedly — for example across multiple pricing items in a single document — or where several different extensions query the same table, the same SQL statement used to be executed against the database each time, even when the underlying data had not changed. This caused unnecessary database load and added latency to pricing and configuration requests.

With this release, the results of sap.db().execute() calls are automatically cached at the SQL-statement level. The cache deduplicates identical queries within a single request as well as across requests, so the database is only queried once for a given SQL statement and parameter combination within the cache's eviction period of 60 minutes.

Note: With that, cached results may remain outdated for up to 60 minutes after changes occur in the underlying database table.

Action: Check your local extension implementations for database accesses and create a support ticket on component LOD-CPS if you require the caching to be disabled for your tenants.

Example use case:

Consider an extension that looks up a discount rate from a custom table ZDISCOUNT_RATES based on the customer's country. A sales order contains 20 items for different products — so each item carries a different product material number in its pricing attributes. Because the extension input differs per item, the requirement formula is executed for each item and not retrieved from the extension result cache. But as the SQL query which is executed by requirement formula 900 only depends on the country — which is the same for all items in the document — the SQL query is only executed for the first item and retrieved from the SQL query cache for all subsequent items.

function REQ_900(pricingInput) {
    var json = JSON.parse(pricingInput);
    var response;
    if (json.action === 'COLLECT_ATTRIBUTES') {
        response = req_900_collect_attributes();
    }
    if (json.action === 'PROCESS_FORMULA') {
        response = req_900_process_formula(json);
    }
    return JSON.stringify(response);
}

function req_900_process_formula(json) {
    var db = sap.db();
    var country = getAttributeValue(json.documentInput.itemInput.attributes, "KOMK-LAND1");
    // Query depends only on country — SQL query cache hit for all items after the first.
    var select = db.select()
        .columns("DISCOUNT_PCT")
        .from("ZDISCOUNT_RATES")
        .where(db.eq("COUNTRY", db.string(country)))
        .build();
    var dbResult = db.execute(select);
    var discountApplies = dbResult.getRowCount() > 0;
    return { result: discountApplies };
}

The SQL query cache is active by default and requires no changes to existing extension code. If real-time data accuracy is required — for example if an extension queries data that changes frequently — the cache deactivation can be requested from SAP via ticket on component LOD-CPS.

More information will be published with the July release in the Extension Guide (Pre‑Production).

As part of our upcoming release, we will upgrade our OpenAPI specification from version 3.0.1 to 3.1.0.

For most customers, this change is expected to have minimal impact on existing integrations. Your current API calls and workflows will continue to function as they do today.

This update focuses on improving how our API is described, by aligning with the latest industry standard (OpenAPI 3.1.0, which is based on JSON Schema Draft 2020-12). It does not introduce changes to API endpoints or behavior.

However, if you use tools that automatically process our API specification, such as code generators, you may need to ensure they support OpenAPI 3.1.0.

Action: Check whether your code generators support OpenAPI 3.1.0 and upgrade if needed

New API specifications will be published with the August release on SAP Business Accelerator Hub for Variant Configuration service, Pricing service, and Administration service.

Custom pricing logic becomes significantly more powerful with support for formula execution during group condition processing.

Previously limited to item-level processing, value formulas (VAL) and scale base formulas (SCL) can now also be executed during group-level evaluation.

A new field groupProcessing is introduced:

true: formula is executed during group condition processing
omitted: formula is executed at item level

groupProcessing flag in extension payload

This enhancement allows:

More flexible pricing logic
Clear separation between item and group-level processing
Better alignment with complex pricing scenarios

Activation is controlled on a per-tenant basis via SAP support.

More information will be published with the August release in the API Definition, Development Guide, and Extension Guide (Pre-Production).

To improve transparency of pricing results, two new response fields are introduced:

scaleBase: provides the calculated scale base value and unit
isGroupCondition: indicates whether a condition is a group condition

new fields in pricing response structure

These enhancements enable:

Improved UI visualization of pricing results
Better traceability and debugging
More accurate integration with downstream systems

More information will be published with the August release in the API Definition and Development Guide (Pre‑Production).

A new filtering capability enables retrieving only items affected by the most recent operation in a pricing document.

new items-changed filter

Example: GET /pricing/documents/{documentId}?$filter=items-changed eq true

The response returns:

Only items that were impacted directly or indirectly
A flat list independent of hierarchy

This provides:

Better performance through reduced payload
Simplified integration for change-based workflows
Improved efficiency for incremental updates

More information will be published with the August release in the API Definition and Development Guide (Pre‑Production).

A new AVC‑aligned engine mode is introduced for beta testing in non‑productive environments. This innovation is a major step forward in enabling the native processing of Advanced Variant Configuration (AVC) models directly within the Variant Configuration service.

What’s new?

With this release, customers can execute AVC-based product models without relying on AVC Forwarding, by leveraging:

A new knowledge-base schema
A dedicated AVC-aligned processing mode in the service

new schema 5 and new flag for AVC-Aligned Mode to use the new mode for this KB even with AVC Forwarding enabled

A key innovation is the introduction of service-side constraint compilation:

Constraints written with supported syntax are now parsed and compiled directly within the service using an integrated compiler
This enables AVC‑like constraint evaluation without dependency on backend execution
Classical dependencies such as procedures, preconditions, and selection conditions continue to be compiled in the back end and are delivered as part of the knowledge base

In addition, the following behavior is now aligned with SAP S/4HANA for advanced variant configuration (AVC):

All characteristics are treated as restrictable, independent of modeling flags
Full alignment with AVC inference logic and domain restriction behavior
Introduction of set-based semantics for multivalue characteristics, ensuring more consistent and predictable evaluation results
AVC syntax round() is supported in constraints

Business value

This innovation has significant benefits in both architecture and runtime behavior:

Reduced architectural complexity

Eliminates the need for AVC Forwarding and cross-engine communication
Enables direct execution within the Variant Configuration service

Improved performance and scalability

Faster configuration processing through service-side compilation
Optimized constraint evaluation and execution
Reduced dependency on back-end systems

Lower resource consumption

Reduced load on SAP S/4HANA by avoiding forwarding-related processing
More efficient use of system resources

Improved functional alignment

Consistent behavior across constraint evaluation, inference logic, and characteristic restriction
More predictable and transparent configuration results

Seamless adoption

No changes required to existing product models or user workflows
Unsupported syntax is handled gracefully with warnings instead of runtime errors

Availability note

This innovation is released with restricted availability as part of an initial beta program:

Available only for selected pilot customers that are using AVC in S/4HANA on-premise or private cloud, model in a VC-compliant way, and use the Variant Configuration service with such an AVC model without AVC Forwarding
Controlled enablement via tenant settings and knowledge-base configuration

More information will be published with the August release in a new document on the solution’s product page (Pre-Production).

The Knowledgebases API is extended with a new filter attribute kbSchema, allowing more precise filtering of runtime versions.

Additional improvements:

Correct handling of avcAlignedConfiguration
Consistent schema responses across knowledge-base generations

This enables better control and selection of knowledge bases in complex scenarios.

Example call:

new kbSchema filter

More information will be published with the August release in the API Definition and Development Guide (Pre‑Production).

An important correction has been implemented for class node specialization in scenarios involving characteristics referencing MARA-MATNR.

The class node specialization depends on the assigned values at product level. For characteristics with reference to MARA-MATNR there often seemed to be no local value assignment. Then, the “default” value assignment used to be set, which is too soft for class node specialization. This has been corrected by: