CRM and CX Blogs by SAP
Stay up-to-date on the latest developments and product news about intelligent customer experience and CRM technologies through blog posts from SAP experts.
cancel
Showing results for 
Search instead for 
Did you mean: 
Michael_W
Product and Topic Expert
Product and Topic Expert

The 2405 release of SAP Variant Configuration and Pricing is planned to be deployed to BTP customer tenants on May 2, 2024.

This blog covers the following planned innovations:

  • Onboarding Using SAP BTP Boosters
  • Guided Answers for the Pricing Service and the Variant Configuration Service
  • Pricing Service – Return Condition Scales in Document Pricing
  • Pricing Service – Support Data Determination Access Type C – KOMPAZD
  • Pricing Service – Enable SAP CPQ to Work With Alternative Units of Measure
  • Extension Concept – Restricted Syntax in Local Extensions
  • Extension Concept – Provide More Data to Requirement Implementations
  • Extension Concept – Pass Scales to Extension Implementations
  • Extension Concept – New APIs to Test Local Extensions (Beta)
  • AdministrationDeprecation of The Table KONH
  • Administration – Delta Replication Monitoring
  • AdministrationElastic Scaling of HANA Memory
  • AdministrationDownload of Local Extensions and Uploaded Knowledge Bases

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

  • Extension Concept – Restricted Syntax in Local Extensions
  • AdministrationDeprecation of The Table KONH

Please check the updated roadmap and release notes after the release date to see which of these features was delivered as planned.

Please note that we have changed the following release dates to avoid deployments at the end of a month:

  • Release 2408: old date was July 31; new planned release date is July 24, 2024
  • Release 2411: old date was October 30; new planned release date is October 23, 2024

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.

 

Onboarding Using SAP BTP Boosters

A new system simulation is available that demonstrates how to use BTP Boosters to create a new tenant for configuration and pricing services: SAP Variant Configuration and Pricing - Onboarding (ondemand.com)

The simulation will also be added to the Administration Guide with the May release.

 

Guided Answers for the Pricing Service and the Variant Configuration Service

A first version of a public troubleshooting guide was published to help our service consumers to quickly find the information they need.

See: Troubleshooting SAP Variant Configuration and Pricing (LOD-CPS) - Guided Answers

Your feedback is highly appreciated to improve the troubleshooting guides in the future. To do so, please use the commenting feature on the right-hand side of the screen when you open the Guided Answers tool. 

 

Pricing Service – Return Condition Scales in Document Pricing

With the last release, scales for item conditions used to be returned only by endpoint GET /api/v1/pricing/documents/{documentId}. For more information see here.

With the new release, the following endpoints will be enhanced to return the scale information, too:

  • POST /api/v1/pricing/documents/{documentId}/items/{itemId}/conditions
  • PATCH /api/v1/pricing/documents/{documentId}/items/{itemId}/conditions/{conditionId}
  • GET /api/v1/pricing/documents/{documentId}/items/{itemId}/conditions/{conditionId}
  • POST /api/v1/pricing/documents/{documentId}/itemsConditions
  • POST /api/v1/pricing/documents/{documentId}/itemsConditionsList

More information will be published in the API Definition with the May release.

 

Pricing Service – Support Data Determination Access Type C – KOMPAZD

Data determination at condition access level was previously not supported by the Pricing service. This also meant that the Pricing service did not consider condition record fields with access type C 'Data Field from Condition Table'.

This gap will be closed: As a first step, the Pricing service will support the determination of a condition record data field that is listed in the communication structure KOMPAZD. If such data was found in an access, it can be used for the condition determination in a subsequent access. See also Data Determination in the Access | SAP Help Portal.

 

Pricing Service – Enable SAP CPQ to Work with Alternative Units of Measure

As of today, with Pricing service integrated in SAP CPQ release 2402, only units of measure can be used in condition records that correspond to the quote item’s sales unit of measure.

If you were to use different units of measure in condition records than used for the sales item quantity, then

  1. CPQ would have to provide the conversion factors from one unit to the other when calling the Pricing service.
  2. CPQ would have to convert the returned condition rate, which it uses for time-dependent quantity-based condition types, from condition record unit to sales quantity unit.

It is planned to close this gap:

  1. With SAP CPQ 2405 release, it is planned that CPQ can send the conversion factors for different units of measure to the Pricing service.
  2. With our 2405 release, Pricing service will do the unit conversion of returned condition rates for CPQ through a new field called rateNormalized for item conditions in the response of the endpoint GET /api/v1/pricing/documents/{documentId} and a new field conditionRateNormalized for item conditions in the response of the endpoint POST /api/v1/statelesspricing.

Then it will be possible to use different units of measure than the sales unit of measure in condition records in the SAP CPQ integration. More information will be published in CPQ documentation when the feature is available.

These new ‘rate normalized’ fields are only intended for the integration of the Pricing service with SAP CPQ and can go through breaking changes based on new CPQ requirements without further notice. Do not use these fields in other integrations!

The purpose of the already existing field “rateConverted” is to return the condition rate in the document currency instead of the condition record currency. The new field “rateNormalized” shall not only consider the document currency but shall also convert the unit of measure used in the condition record to the item’s target sales unit of measure. But “rateNormalized” is not just the converted condition rate, it is more:

The condition value is used as the basis for the calculation of the normalized rate, because the condition value was already calculated based on the document currency and the item’s unit of measure.

For quantity-based conditions: The "rateNormalized" field holds the condition rate information derived from the condition value and is normalized to a per sales quantity unit.

rate normalized = condition value / item quantity

If it's a variant condition, the variant factor is also factored into the "rateNormalized". Moreover, if it's a time-dependent quantity-based condition, the duration factor is incorporated, too.

For fixed amount conditions (calculation type - B): The "rateNormalized" field remains consistent with the condition value.

rate normalized = condition value

For percentage conditions (calculation type - A):

rate normalized = condition value * 100 / condition base 

For variant conditions, the "rateNormalized" considers the variant factor.

In all those cases, changes through (custom) pricing routines, that were applied when calculating the condition value, are also considered when deriving the normalized rate from the condition value.

Example: Consider document currency as USD and sales quantity as 2 PCE (pieces). In the material master, the unit conversion is maintained as 1 PK (pack) = 6 PCE. If a determined condition record is 5 EUR per pack, the response would have the following values:

Example Item Condition Response Values

Meaning/Calculation

"base": 0.333

2PCE * (1PK / 6PCE) = 1/3PK => 0,333 packs

"rate": {"unit": "EUR", "value": 5.00}

5EUR per 1 pack

"rateQuantity": {"unit": "PK", "value": 1}

5EUR per 1 pack 

"value": 1.89

0,33PK * 5EUR/PK * currency conversion factor = 1,89USD (for the 2 pieces)

"rateNormalized": {"unit": "USD", "value": 0.95}

1.89USD / 2 = 0,945 => 0,95USD per piece 

Please note that rounding discrepancies may arise during manual calculations of the condition value using 'rateNormalized.' For instance, while 'rateNormalized' multiplied by 2 should ideally result in 1.9, due to rounding the calculated condition value may slightly differ, as shown in the example where it's 1.89.

Furthermore, it's essential to acknowledge that the value displayed in the 'rateNormalized' field may not always match the value displayed in the 'rate' field in the SAP ERP or SAP S4/HANA system. This disparity arises because the condition rate is not normalized based on document currency and per sales quantity unit in the back-end system. Consequently, discrepancies may occur between these values. We advise keeping this in mind when comparing and interpreting rate-related information between the front-end and back-end systems.

Note: When creating a quotation/order in the back-end via order APIs, the unit and the value belonging to 'rate' field shall be mapped. The field “rateNormalized” must not be used in that case. It is intended only for display purposes in SAP CPQ.

More information will be published in the API Definition and the Development Guide with the May release.

 

Extension Concept – Restricted Syntax in Local Extensions

With the May release, when implementing local extensions, the following syntax will no longer be allowed:

  • Keywords: "async", "await", generator functions ("function*")
  • Functions(*): "eval", "load", "loadWithNewGlobal", "print", "printErr"
  • Objects(*): "console", "Graal", "FinalizationRegistry", "Function", "Promise", "Proxy", "Reflect", "Symbol"

(*)Using them will cause a runtime error.

Action:

  • Do not use such syntax in new code. It will be blocked in a future release during the code upload.
  • Check your current local extension code for the usage of such forbidden syntax and remove it. If it is not possible to remove it, please create a ticket on component LOD-CPS before May 2024 to find a solution with SAP support.

More information will be published in the Extension Guide with the May release.

 

Extension Concept – Provide More Data to Requirement Implementations

Pricing engine used to only pass parameters 'attributes' and 'exclusionIndicator' as input data to an implementation of a pricing requirement.

That is still the default behavior, but through a projection that lists fields of structure ‘itemInput’ in the response of action COLLECT_ATTRIBUTES via ‘extendedInput’>’documentInput’>’itemInput’>’projection’ it will also be possible to request the item 'quantity' and other 'conditions' information as input for a custom requirement formula.

For a requirement formula, it is only possible to retrieve a subset of the ‘conditions’ fields for the already determined pricing conditions: 'stepNumber', 'counter', 'conditionType', 'conditionRate', 'conditionUnit', and ‘scale’.

More information will be published in the API Definition and the Extension Guide with the May release.

 

Extension Concept – Pass Scales to Extension Implementations

Information about the maintained scales for a found condition record can also be requested by custom pricing routines and can be passed as input to custom routine implementations. With that, a custom routine will also be able to use the other scale levels as the basis for their calculations.

More information will be published in the Extension Guide with the May release.

 

Extensions Concept – New APIs to Test Local Extensions (Beta)

[UPDATE] Delivery of this feature will be postponed. It will not be part of 2405 release.

Currently, local extension implementations can only be tested by calling the Pricing service or Variant Configuration service and checking the expected pricing or configuration results.

We will introduce new endpoints that allow testing the active custom routines directly:

Test APIsTest APIs

GET /functions: Returns the list of active uploaded pricing routines or variant functions.
Example response with a list of active variant functions:

{  "count": 2,  
"value": [
{ "id": "VF_VARCONDS" }, { "id": "VF_DRYER_LEAD_TIME" } ] }

POST /functions/{functionId}: Allows to process an active uploaded pricing routine or variant function.
Example input to test a variant function POST /functions/VF_DRYER_LEAD_TIME:

 

 

{
  "type": "vfun",
  "vfunInput": {
    "fnArgs": [
      {
        "id": "CPS_GARNISH_INV",
        "type": "String",
        "values": [
          "F"
        ]
      },
      {
        "id": "CPS_SIZE",
        "type": "String",
        "values": [
          "L"
        ]
      },
      {
        "id": "CPS_FRY_SAUCE",
        "type": "String",
        "values": []
      }
    ],
    "id": "VF_DRYER_LEAD_TIME",
    "kbHeaderInfo": {
      "bomApplication": "SD01",
      "build": 9,
      "changeDate": "2018-10-04",
      "id": 80,
      "key": {
        "kbName": "CPS_BURGER",
        "kbVersion": "0.1",
        "logsys": "RR4CLNT910"
      },
      "plant": "1000",
      "structureHash": "CF897878C9EBDFBB379EC107602BB490",
      "type": "string",
      "validFromDate": "2018-05-02"
    }
  }
}

 

 

Example response of a successful execution of the variant function:

 

 

{
  "type": "vfun",
  "vfunOutput": {
    "result": true,
    "fnArgs": [
      {
        "id": "CPS_DRYER_LEADTIME",
        "values": [
          "0.3860294117647059"
        ]
      }
    ]
  }
}

 

 

Please note that those endpoints are only released for beta testing. They must not be used in production, can still be changed incompatible, and can also be removed again.

Please leave us a comment below if you tested those new endpoints and let us know if they add value to your extension implementation and test processes.

More information will be published in the API Definition and the Extension Guide with the May release.

 

Administration – Deprecation of The Table KONH

The Pricing service does not need the conditions header table KONH. The table will not be loaded anymore with the May release. The table will be removed with the August release 2408.

Action:

  • Please check whether you are using the table in any local extension implementation. If yes, it must be added to the replication as a custom table.

See also the Administration Guide.

 

Administration – Delta Replication Monitoring

A new screen will be added showing first details about pending delta replications for SAP HANA smart data integration-based replications. Depending on the replication type, the pending deltas on your source system are shown per table.

Monitoring Delta ReplicationMonitoring Delta Replication

More information will be published in the Administration Guide with the May release.

 

Administration – Elastic Scaling of HANA Memory

With the May release, the size of the SAP HANA database that is used by configuration and pricing services is automatically increased when large data loads are started from the back-end. The automatic increase supports tables with up to approximately 100 million rows of data.

Action: Please create a support case on component LOD-CPS-AUS if you plan to load tables that are larger.

 

Administration – Download of Local Extensions and Uploaded Knowledge Bases

Zip archives that were manually uploaded before for local extensions and knowledge bases can now be downloaded again on the corresponding screens:

Download Uploaded Local Extensions ArchiveDownload Uploaded Local Extensions Archive

Download Manually Uploaded Knowledge BaseDownload Manually Uploaded Knowledge Base

 

With that, you have a good overview of what innovations are planned for the May release. Please check the updated roadmap and release notes after the release date to see which of these features was delivered as planned. We are look forward to your feedback on the new features.