The 2308 release of
SAP Variant Configuration and Pricing is planned to be deployed to BTP customer tenants on August 2.
In this blog, we are covering the following planned innovations:
- Pricing service – Return condition rate in document currency
- Pricing service – Return condition table id
- Pricing service – Pass Condition Origin and Scale Base Type to custom routines
- Pricing service – API to read sub-procedure determination formula
- Pricing service – Hide sub-procedures from procedures list
- Variant Configuration service – Do not allow changes to read-only characteristics
- Administration – Support for DB2 trigger-based replication
- Administration – Improvements to UIs to display replicated pricing data
- Administration – Improvements on dropping and recreating the remote source connection
- Administration – Built-In Support
- Administration – Change from service keys to service bindings
- Extension Concept – Local Extensions for Configuration and Pricing
Call to act regarding the following potentially incompatible changes:
- Variant Configuration service – Do not allow changes to read-only characteristics
- Pricing service – Hide sub-procedures from procedures list
- Administration – Change from service keys to service bindings
The information in this document is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. This document is provided without a warranty of any kind:
Legal Disclaimer
The information in this presentation is confidential and proprietary to SAP and may not be disclosed without the permission of SAP.
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 document or any related presentation, or to develop or release any functionality mentioned therein. This document, or any related presentation, and SAP’s strategy and possible future developments, products, and 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 document is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. This document is provided without a warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, or noninfringement. This document is for informational purposes and may not be incorporated into a contract. SAP assumes no responsibility for errors or omissions in this document, except if such damages were caused by SAP’s willful misconduct or gross negligence.
All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are cautioned not to place undue reliance on these forward-looking statements, which speak only as of their dates, and they should not be relied upon in making purchasing decisions.
For all recent and planned innovations, potential data protection and privacy features include simplified deletion of personal data, reporting of personal data to an identified data subject, restricted access to personal data, masking of personal data, read access logging to special categories of personal data, change logging of personal data, and consent management mechanisms.
Pricing service – Return condition rate in document currency
In pricing we distinguish three currencies:
- the condition record currency in which a price was maintained in the condition table,
- the local currency of the country where the pricing is done, and
- the document currency, which is the end customer’s target currency.
During pricing, prices are converted first from condition record currency to local currency and then from local currency to document currency. If no local currency is provided, it is assumed that it is the same as the document currency.
Let's say a company maintains all prices in USD and a sales office that is located in Germany sells something to a customer in China. Then, the price in condition record currency USD is first converted to local currency EUR and from that to document currency CNY.
Pricing service returns prices in document currency.
In the pricing results, in the returned list of conditions, the condition value is also returned in document currency, but the condition rate is returned in condition record currency.
That means, an application that wants to use the condition rate, instead of the condition value, might have to convert it first to document currency before using it.
To avoid that, the new structure
conditionRateConverted will be added to the
conditions response of stateless pricing and
rateConverted will be added to the
conditions response of document pricing to return the condition rate not only with the currency it was maintained with in the condition records, but it will also return it converted into the document currency.

Pricing service – Return condition table id
While
GET /conditions APIs of document pricing return the information of the condition table the condition record was read from, that information is missing for
POST /statelesspricing API. This gap will be eliminated: stateless pricing API will also return the condition table id for document- and item conditions.
GET /api/v1/pricing/documents/{documentId}/conditions/{conditionId}
GET /api/v1/pricing/documents/{documentId}/items/{itemId}/conditions/{conditionId}

POST /api/v1/statelesspricing

Please note:
/conditions endpoints only return a table number like 900, while
/statelesspricing and
/customizing/accesssequences return a full table name, like A900.
Pricing service – Pass Condition Origin and Scale Base Type to custom routines
The condition
origin reveals whether a pricing condition was added at the document level or at the item level. This information can now be requested by a custom routine implementation from the pricing engine through a projection. With that, the implementation can behave differently depending on the origin.

The origin value will be empty for sub-totals.
The
scale basis indicator determines how the system interprets a pricing scale in a condition. For example, the scale can be based on quantity, weight, or volume.

This information can now be requested by a custom routine implementation from the pricing engine through a projection on field
scaleBaseType. With that, the implementation gets aware of differences between the condition’s calculation type and scale base type, and it can behave accordingly.
More details will be added to the
Extension Guide.
Pricing service – API to read sub-procedure determination formula
Since the May release, Pricing service supports modular pricing procedures with main pricing procedures and sub-procedures as introduced in SAP S/4HANA. See also
here.
Endpoint
POST /api/v1/pricingprocedure/{pricingProcedureId} can be used to kind of simulate the sub-procedure determination depending on different provided pricing attributes.
New endpoint
GET /api/v1/customizing/subProcedureDeterminationFormulas will be introduced in August to give read access to the settings that are used to determine sub-procedures.
GET /api/v1/customizing/subProcedureDeterminationFormulas/{subProcedureDeterminationFormulaId}

Example response for decision table CPS_TEST, where sub-procedure is determined based on departure country, destination country, and tax condition determination country:
{
"subProcedureDeterminationFormulaParameters": [
{
"id": "PRICINGSUBPROCEDURE",
"priority": 0,
"isResult": true
},
{
"id": "DEPARTURECOUNTRY",
"priority": 1,
"isResult": false
},
{
"id": "DESTINATIONCOUNTRY",
"priority": 2,
"isResult": false
},
{
"id": "TAXCONDITIONDETNCTRYREG",
"priority": 3,
"isResult": false
}
],
"subProcedureDeterminationFormulaRows": [
[
{
"id": "PRICINGSUBPROCEDURE",
"value": "ZDSCEU"
},
{
"id": "DEPARTURECOUNTRY",
"value": "DE",
"operator": "EQ"
},
{
"id": "DESTINATIONCOUNTRY",
"value": "IT",
"operator": "EQ"
},
{
"id": "TAXCONDITIONDETNCTRYREG",
"value": "IN",
"operator": "EQ"
}
],
[
{
"id": "PRICINGSUBPROCEDURE",
"value": "ZDSCE4"
},
{
"id": "DEPARTURECOUNTRY",
"value": "DE",
"operator": "EQ"
},
{
"id": "DESTINATIONCOUNTRY",
"value": "IN",
"operator": "EQ"
},
{
"id": "TAXCONDITIONDETNCTRYREG",
"value": "FR",
"operator": "EQ"
}
],
[
{
"id": "PRICINGSUBPROCEDURE",
"value": "ZDSCEU"
},
{
"id": "DEPARTURECOUNTRY",
"value": "BD",
"operator": "EQ"
},
{
"id": "DESTINATIONCOUNTRY",
"value": "",
"operator": ""
},
{
"id": "TAXCONDITIONDETNCTRYREG",
"value": "AT",
"operator": "EQ"
}
],
[
{
"id": "PRICINGSUBPROCEDURE",
"value": "ZDSCE3"
},
{
"id": "DEPARTURECOUNTRY",
"value": "DE",
"operator": "EQ"
},
{
"id": "DESTINATIONCOUNTRY",
"value": "IT",
"operator": "EQ"
},
{
"id": "TAXCONDITIONDETNCTRYREG",
"value": "",
"operator": ""
}
],
[
{
"id": "PRICINGSUBPROCEDURE",
"value": "ZDSCE2"
},
{
"id": "DEPARTURECOUNTRY",
"value": "",
"operator": ""
},
{
"id": "DESTINATIONCOUNTRY",
"value": "FR",
"operator": "EQ"
},
{
"id": "TAXCONDITIONDETNCTRYREG",
"value": "AU",
"operator": "EQ"
}
],
[
{
"id": "PRICINGSUBPROCEDURE",
"value": "ZDSCE1"
},
{
"id": "DEPARTURECOUNTRY",
"value": "IN",
"operator": "EQ"
},
{
"id": "DESTINATIONCOUNTRY",
"value": "DE",
"operator": "EQ"
},
{
"id": "TAXCONDITIONDETNCTRYREG",
"value": "IT",
"operator": "EQ"
}
]
]
}
Pricing service – Hide sub-procedures from the procedures list
Endpoint
GET /api/v1/customizing/procedures used to return sub-procedures that cannot be used in any business transaction. As this might lead to confusion and to errors when trying to use such procedures, sub-procedures will not be returned any longer.
Action: Please ensure that you do not have an implementation that relies on sub-procedures being returned by this API.
Variant Configuration service – Do not allow changes to read-only characteristics
Endpoints for changing a characteristic value reject the call if the characteristic is marked as read-only. This read-only check is missing when AVC forwarding is enabled. This issue will be corrected.
Action: If you have enabled AVC forwarding, ensure that you do not try to PATCH characteristics that are marked read-only. Otherwise, those PATCH requests will fail.
Administration – Support for DB2 trigger-based replication
With SAP HANA smart data integration (SDI) 2.7 and higher, a trigger-based delta replication was introduced for IBM DB2 databases. This will also be supported for SAP Variant Configuration and Pricing.
The new trigger-based replication has several advantages over the previous LogReader-based approach:
- Higher stability
The DB transaction logs are typically configured to be archived after some hours. In case of high load this often was too short for the SDI Data Provisioning Agent to catch up.
- Higher performance
With the trigger-based replication only changed records need to be processed by the SAP SDI Data Provisioning Agent. This offers a better performance as scanning the transaction logs of all the changes done in the source DB.
Action: SAP strongly recommends switching to the new trigger-based replication.
Administration – Improvements to UIs to display replicated pricing data
Pricing replication – Show status of replicated condition tables
A new detail screen will be added to the UI Pricing – Replication, which shows the detailed status of the replicated condition tables.
The new UI includes information about:
- Delta Replication status
- Table not replicated – The table is not replicated yet
- Replicating changes in real-time – Delta replication is established

- Generation status
This status is derived from the source system. The table cannot be replicated if the status is smaller than 5. In that case, please check the activation logs in your source system.
Static filter for pricing condition record display
The UI to display the pricing condition table records will be extended to statically include the selected condition type as filter.
Validity date filter for pricing condition record display
A validity date filter will be added to the UI to display the pricing condition table records. When using the filter, only records valid at the selected date will be displayed.

Administration - Improvements on dropping and recreating the remote source connection
The UIs
Connect to SAP Cloud and
Advanced Actions will be linked together to guide the user on how to drop or recreate the remote source connection:

Connect to SAP Cloud

Advanced Actions
Administration – Built-In Support
A new headset icon will be added to the administration UI which will start the so-called
Built-In Support dialog. There, you can find links to relevant help documents as well as an option to create a support ticket.

Start Built-In Support
Administration – Change from service keys to service bindings
In our current onboarding documentation, we ask customers to create a new subaccount per tenant, enable Cloud Foundry for that subaccount, and create service instances and service keys to get the service URL and credentials.
In the same way, subaccounts are created via our BTP Boosters.
It is not required to enable Cloud Foundry to use our services, e.g. in SAP CPQ or SAP Commerce Cloud.
Therefore, we will change our documentation and the BTP Boosters in a way that Cloud Foundry will not be enabled anymore. With that, no space must be created anymore within the subaccount and service keys cannot be created anymore for configuration and pricing service instances. Instead of service keys, service bindings must be created to get the service URLs and credentials.
But no need for customers to change the current setup with Cloud Foundry enabled and using service keys. To use Alert Notification service, Cloud Foundry must still be enabled.
Extension Concept - Local Extensions for Configuration and Pricing
For the current extension concept (loose coupling via remote extensions) see
SAP Variant Configuration and Pricing – Extension Concept.
If heavily used, those remote extension calls can lead to long runtimes because of network latency. Therefore, we have decided to invest into our own framework to run customer code in our cloud services on SAP BTP. We will embark on this journey with a first release in August.
In that first release, it will be possible to upload JavaScript code for custom variant functions and custom pricing routines via our administration UI and let Variant Configuration service and Pricing service execute it locally.
The implementation must be compliant with the ECMAScript 2021 specification and may not have external dependencies. No HTTP- or DB calls possible from within that code.
If no uploaded code can be found for a variant function, but a web service URL was maintained for the extension implementation, then the configuration engine will do a remote call to the web service URL.
If no uploaded code can be found for a custom pricing routine, but a web service URL was maintained for the extension implementation, then the pricing engine will do a remote call to the web service URL.
More details will be published in
Extension Guide.
With that, you have a good overview about what innovations are planned for the August release. Please check updated
roadmap and
release notes after the release date to see which of those features could be delivered as planned.