The 2502 release of SAP Variant Configuration and Pricing is planned to be deployed to BTP customer tenants on January 22, 2025:
Administration UI and Administration service:
Release | Test/Non-Productive & Productive Upgrades |
2502 | January 22, 2025 |
Variant Configuration service & Pricing service:
Release | Test/Non-productive Upgrade | Productive Upgrade |
2502 | January 22, 2025 | February 5, 2025 |
This blog covers the following planned innovations:
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, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. This presentation is for informational purposes and may not be incorporated into a contract. SAP assumes no responsibility for errors or omissions in this presentation, except if such damages were caused by SAP’s intentional 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.
There is a new staged deployment strategy for the Variant Configuration service and the Pricing service starting with the 2502 release. In the past, new software releases used to be deployed to all customer tenants at the same time. We will continue to do that for our administration UI and our Administration service, but for the configuration and pricing services we will first deploy the 2502 release only to all non-productive tenants (including the partner tenants) on January 22 2025, and two weeks later, on February 5, we will also deploy it to the productive tenants.
Action: It is recommended to familiarize with the Release Schedule and Dates on our product page. Please review the changes in the Pre-Production version of the documentation that will be published on January 22, and use the given two weeks to test the new release in your non-productive tenants and process the actions of the recommended or required changes that are announced here and in the release notes.
SAP Variant Configuration and Pricing will support EU Access tenants after the February release. A special entitlement will be required for EU Access. This will only be available if the SAP customer has signed a contract that specifically includes EU Access.
Data processed by SAP is subject to restrictions in line with standard Cloud service contracts in SAP’s General Terms and Conditions (GTC). The objective of EU Access is to keep SAP's processing of customer personal data within the EEA and Switzerland only.
For such contracts, where the BTP global account is marked with EU Access, the actual EU Access compliance status of subaccounts will be displayed during the creation of subaccounts.
If you require a subaccount with EU Access, make sure to select a provider and region where EU Access is available. For SAP Variant Configuration and Pricing, this will have to be AWS Europe (Frankfurt) EU Access, cf-eu11.
All SAP Variant Configuration and Pricing tenants of a customer must be subscribed in one region and operated by the same infrastructure provider. AWS Europe (Frankfurt) cf-eu10 is a different region than AWS Europe (Frankfurt) EU Access cf-eu11! It is not supported to run different tenants of the same customer in those different regions. The region also defines the infrastructure provider. It is not supported either to run the different tenants on different infrastructure providers like Amazon Web Services or Azure. It is not possible to switch the region or the provider for existing tenants. It is not possible to move subaccounts and tenants across regions.
Created-by and changed-by fields in the administration UI and in the response of some endpoints of the Administration service will remain empty when used on AWS Europe (Frankfurt) EU Access, cf-eu11, while in other regions they will continue to have user ids or email addresses.
The Data Transfer Factsheet and the List of sub processors will be updated after the February release.
To obtain an OAuth token to call an endpoint of a cloud service, the client id and the client secret must be provided which can be found in the service's service key or service binding. Instead of the client secret, an X.509 certificate can now be used.
Action: Using X.509 certificates is considered more secure than using client secrets. It is recommended to use the new approach. Using external or self-managed certificates also enables simplified certificate rotation.
More information will be published in the Security Guide (Pre-Production) and the Administration Guide (Pre-Production) with the February release.
When creating a new pricing document with the endpoint POST /documents, the owner or the source of the document can be specified. The source application, the source type; for example, quote, and the source id; for example, the quote’s transaction number, can be passed and are stored with the pricing document.
The source information can be used as a filter criteria in the APIs to manage stored pricing documents.
With the February release, the enhanced endpoint PATCH /documents will allow overwriting the source of a document in addition to the document currency and exchange rate details:
Overwrite the Source
No partial updates are possible, it is required to provide all the source information: application, type, and id.
More information will be published in the API Definition and in the Development Guide (Pre-Production) with the February release.
We will enhance endpoint POST /statelesspricing with the new response fields calculationStatus and messages that are already known from document pricing.
The new fields will indicate whether the price calculation was completed successfully, with warnings, or with errors. The status is determined based on the severity of the generated messages, which are detailed in the messages field. These messages will be available at both the document level and at the item level and can include warnings or error information:
Pricing Status
More information will be published in the API Definition and in the Development Guide (Pre-Production) with the February release.
We will enhance endpoint POST /statelesspricing and GET /documents with the new response structure validity for the returned item conditions.
The new structure will expose the start and end dates of the used condition records:
Item Condition's Validity
This allows the calling applications to display how long a certain price or discount can still be guaranteed.
More information will be published in the API Definition with the February release.
Only condition tables and condition records with application ‘V’ (Sales) are considered by the Pricing service.
For cases in which condition records with application 'V' are stored in condition tables that belong to application 'M' (Purchasing), customers must ensure that the necessary tables are correctly handled in the replication. If an access sequence uses relevant condition tables (A-tables) belonging to application 'M' (as identified in the table T681), customers need to reload the table T681 and the corresponding A-tables.
The Pricing service will then also consider the condition records with application 'V' in such condition tables with application 'M'.
More information will be published in the Development Guide (Pre-Production) with the February release.
Newly supported standard requirement formula 58 will return true if the accounting indicator (pricing attribute KOMP-BEMOT) is not initial.
Newly supported standard requirement formula 67 will always return true in the context of the Pricing service. Background: If the "exclusive" indicator is set in the access sequence, it ensures that once a condition record is found for any of the relevant contracts (for multi-value attributes), no further steps in the access sequence are processed. However, by using this requirement formula in the access sequence, the condition access can continue to the next step, while filtering out contracts for which condition records have already been found. This behavior is enabled by setting the flag “continue_for_mva” to “true” in the back end but this is the default behavior in pricing, hence the standard requirement formula always returns true.
More information will be published in Supported Standard Pricing Exits (Pre-Production) with the February release.
Not all standard pricing routines that are available in the back end are also available in Pricing service. See also Supported Standard Pricing Exits.
If needed, customers can request the implementation of a missing routine, but SAP might reject this, because the routine is not considered as relevant for the use cases that the Pricing service addresses.
In such a case, SAP can allow and enable the customer to use the Pricing service’s extension concept to implement the standard pricing routine on a project-basis. It will also be possible to overwrite already supported standard routines like this. If needed, please create a customer ticket on component LOD-CPS-PRC.
More information will be published in the Extension Guide (Pre-Production) with the February release.
For certain back-end releases it is possible to maintain a description on the condition record level:
Condition Record Description
That description is displayed in the pricing results instead of the condition type description, but only for non-variant conditions.
The Pricing service will support the same mechanism. This feature will only be activated on request through a customer ticket on component LOD-CPS-PRC.
Table KONPT will be added to the list of replicated tables for the Pricing service.
More information will be published in the API Definition and the Development Guide (Pre-Production) with the February release.
When the VARCOND key field in an access was flagged as Initial Value Allowed and a condition record with an empty variant condition key was maintained, the Pricing service used to return different results from the pricing in SAP S/4HANA. This issue has been corrected.
A VARCOND key field in an access can be flagged as Initial Value Allowed:
Initial Value Allowed
A condition record for such a variant condition is maintained without a condition key:
Condition Record
Nevertheless, when the Pricing service is called with 3 variant condition keys, it is expected that the condition record is determined and applied 3 times.
And if the condition keys were provided with different pricing factors, then the correct pricing factor must be applied for each of the 3 price elements.
Example pricing call with 3 variant condition keys:
"variantConditions": [
{
"factor": 1,
"key": "CHEESE"
},
{
"factor": 3,
"key": "2ndPATY"
},
{
"factor": 2,
"key": "BACON"
},
]
Behavior before the fix:
Condition Type | Counter | Condition Rate | Condition Base | Condition Value | Variant Key | Variant Factor |
PR00 | 1 | 7 EUR | 1 | 7 EUR |
|
|
VAIN | 1 | 0,30 EUR | 1 | 0,30 EUR |
| 1 |
Behavior after the fix:
Condition Type | Counter | Condition Rate | Condition Base | Condition Value | Variant Key | Variant Factor |
PR00 | 1 | 7 EUR | 1 | 7 EUR |
|
|
VAIN | 1 | 0,30 EUR | 1 | 0,30 EUR | CHEESE | 1 |
VAIN | 2 | 0,30 EUR | 3 | 0,90 EUR | 2ndPATY | 3 |
VAIN | 3 | 0,30 EUR | 2 | 0,60 EUR | BACON | 2 |
In scenarios where a percentage condition (e.g., KA00) spans multiple counters within the same step range in the pricing procedure, the condition base was not dynamically adjusted to account for the cumulative effect of prior conditions. Instead, all counters for the condition type used the original base amount.
For example: When the From and To fields for the condition type KA00 in the pricing procedure specify the same step (e.g., From: 10, To: 20), and KA00 is applied as a percentage condition, all counters used the same condition base (100 EUR in this case), leading to identical condition values (-5 EUR) regardless of previous adjustments.
With the fix, the system will adjust the condition base step by step when calculating values for percentage conditions like KA00. Each counter now reflects the impact of the previous ones, ensuring accurate calculations within the specified step range.
Behavior before the fix:
Condition Type | Counter | Condition Rate | Condition Base | Condition Value |
PR00 | 1 | 100 EUR | 1 | 100 EUR |
KA00 | 1 | -5% | 100 EUR | -5 EUR |
KA00 | 2 | -5% | 100 EUR | -5 EUR |
KA00 | 3 | -5% | 100 EUR | -5 EUR |
Behavior after the fix:
Condition Type | Counter | Condition Rate | Condition Base | Condition Value |
PR00 | 1 | 100 EUR | 1 | 100 EUR |
KA00 | 1 | -5% | 100 EUR | -5 EUR |
KA00 | 2 | -5% | 95 EUR | -4.75 EUR |
KA00 | 3 | -5% | 90.25 EUR | -4.51 EUR |
When a characteristic value could not be set, because a select on a variant table resulted in more than one row, an exception used to be raised and the configuration service endpoint responded with an error. This behavior will be changed by no longer raising an exception but signaling a conflict in the configuration results in the same way as LO-VC does it.
We will enhance endpoint GET /knowledgebases/{kbId}/variantTables/{variantTableId} with a new IN operator for the $filter parameter that will allow more advanced table selects in the form of $filter=<characteristic name> IN (<list of characteristic values>).
Examples:
Operator: IN
More information will be published in the API Definition and in the Development Guide (Pre-Production) with the February release.
New endpoint GET /configurations/{configurationId}/items/{itemId}/characteristics to read the details of one or more characteristics of an item:
Request
Response
Action: If the UI of the consuming application allows it, it is recommended to always read the configuration results during interactive configurations without the possible values of characteristics. This can be achieved by using the $select parameter omitting the parameter value possibleValue when creating or reading a configuration. When the user clicks on a UI element like a dropdown list box, that requires to render the possible values on the UI, only then the possible values should be read for that characteristic using the new endpoint. This will improve performance especially when AVC Forwarding is enabled.
More information will be published in the API Definition and in the Development Guide (Pre-Production) with the February release.
The alert for a too high number of deltas is now also sent to SAP Cloud Application Lifecycle Monitoring – Integration Monitoring.
More information will be published in the Administration Guide (Pre-Production) with the February release.
With that, you have a good overview of what innovations are planned for the February release. Please check the updated roadmap and release notes after the release date to see which of these features were delivered as planned.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
4 | |
2 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 |