CRM and CX Blog Posts 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
2,266

The 2411 release of SAP Variant Configuration and Pricing is planned to be deployed to BTP customer tenants on October 23, 2024.

 

This blog covers the following planned innovations:

  • Pricing service – Price Agreements
  • Pricing service – Manage Stored Documents
  • Pricing service – Graduated Interval Scales Factor
  • Pricing service – Proper Returning of Used Currency Exchange Rates
  • Variant Configuration Service – Change the Source of a Configuration
  • Extension Concept – Pass the Variant Factors to Extension Implementations
  • Extensions Concept – Enhanced Blocking of JavaScript Functions During Upload
  • AdministrationAlerts in Case of High Number of Deltas
  • Administration – Rate Limits for Calls to the Administration Service
  • Administration – Improved Variant Table Load for Knowledge Bases
  • Administration – New Fields for the Display of Condition Records

 

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

  • Administration – Rate Limits for Calls to the Administration Service
  • Extensions Concept – Enhanced Blocking of JavaScript Functions During Upload

 

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.

 

Pricing service – Price Agreements

SAP CPQ plans to support a process called tier pricing, in which the sales agent negotiates certain price scales with the end customer during the quotation process. The sales agent creates a quote and adds items. The price is determined as defined by the pricing procedure using the Pricing service. The sales agent can then negotiate and overwrite scales per price condition per item, which usually means that a lower price per amount is applied for higher item quantities. Those thresholds, where for a certain higher item quantity a lower price is applied, are called tiers. The scales/tiers maintained in SAP CPQ for a quote item will overrule the prices and scales maintained for the product in SAP S/4HANA.

For that, we will introduce new Pricing service endpoints to create, change, read, and delete so-called price agreements. When the calling application passes a price agreement for an item with the negotiated scales for a certain condition type, the Pricing service will use that data to determine the price instead of using what was maintained in the condition record.

2411 Agreements.jpg

The following call creates a new price agreement for the item {itemId} of the pricing document {documentId}:

POST /api/v1/pricing/documents/{documentId}/items/{itemId}/priceAgreements

 

 

 

{
  "priceAgreements": [
    {
      "calculationType": "C",
      "conditionTypeId": "PR00",
      "rate": {
        "unit": "EUR",
        "value": "4.99"
      },
      "rateQuantity": {
        "unit": "PCE",
        "value": 1
      },
      "scale": {
        "levels": [
          {
            "scaleRate": {
              "unit": "EUR",
              "value": "4.99"
            },
            "scaleValue": "1.000"
          },
          {
            "scaleRate": {
              "unit": "EUR",
              "value": "3.99"
            },
            "scaleValue": "10.000"
          },
          {
            "scaleRate": {
              "unit": "EUR",
              "value": "2.99"
            },
            "scaleValue": "20.000"
          }
        ],
        "scaleType": "A",
        "scaleUnit": "PCE"
      },
      "validity": {
        "endDate": "2018-12-31",
        "startDate": "2018-01-01"
      }
    }
  ]
}

 

 

 

The example above overwrites the price condition PR00. It establishes three tiers:

Tier 1: From item quantity 1 to 9 pieces: 4,99€ per 1 piece (PCE)
Tier 2: From item quantity 10 to 19 pieces: 3,99€ per 1 piece (PCE)
Tier 3: For item quantity 20 and above: 2,99€ per 1 piece (PCE)

For a successful price agreement creation, the endpoint returns a price agreement id.

You can only have one price agreement per condition type per item.

You can use the price agreement id with the GET, PATCH, and DELETE endpoints to read, overwrite, or delete it again.

We will not only support this with document pricing but will also enhance the stateless pricing API analogously to allow passing such price agreements at the item level.

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

The planned process in SAP CPQ will end with the acceptance of the quote, which will write the negotiated scales into a new condition table in SAP S/4HANA before the contract in SAP S/4HANA is created. With that, it is ensured that those negotiated prices will be applied to the item in the context of this contract.

 

Pricing Service – Manage Stored Documents

When creating a new pricing document with the endpoint POST /documents, it will be possible to specify the owner or the source of the document. The source application, the source type; for example, quote, and the source id; for example, the quote’s transaction number, can be passed and stored with the pricing document.

Example call:

POST /documents

 

 

 

{
  "documentCurrencyUnit": "EUR",
  "exchangeRateDate": "2024-09-17",
  "exchangeRateType": "M",
  "localCurrencyUnit": "USD",
  "pricingProcedureId": "ZPRC03",
  "source": {
    "application": "cpq",
    "type": "quote"
    "id": "49709821",
  }
}

 

 

 

The source of a pricing document can be specified in the same way when creating a new document as a copy through endpoint POST /documents/{documentId}/copy.

Action:

  • It is recommended to specify the source of the pricing document, so that it can later be used to identify the owner of the document and to judge if it can be deleted again.

The new endpoint GET /documents will be introduced to return a list of stored pricing documents. The API will offer different filter capabilities, for example, filtering based on the source of the document.

A stored pricing document can be read with endpoint GET /documents/{documentId}.

A stored document can be deleted with endpoint DELETE /documents/{documentId}.

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

 

Pricing service – Graduated Interval Scales Factor

When doing Pricing with Graduated Scales, a factor per scale level is calculated and applied to calculate the condition value from the condition rate. This factor used to overwrite the value of the duration factor in the response field conditions-durationFactor. This loss of information will be corrected by returning the factor separately in the response field conditions-graduatedScaleFactor.

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

 

Pricing service – Proper Returning of Used Currency Exchange Rates

Condition rates are either converted directly from the condition record currency to the document currency; or they are converted through triangular conversion; first, from the condition record currency to the local currency and then to the document currency. The condition value is always returned in the document currency.

With a request parameter for stateless pricing and document pricing, it is possible to get the used currency conversion rates returned. This allows the calling application to do its own calculations in the same way.

In the currency conversion response: items->currencyConversions->localCurrencyToDocumentCurrency, the returned exchange rate used to be for converting document currency to the local currency instead of the local currency to the document currency. This issue will be corrected. 

 

Variant Configuration Service – Change the Source of a Configuration

When creating a new configuration with the endpoint POST /configurations, the owner or the source of the configuration can be specified. The source application, the source type; for example, quote item, and the source id; for example, the item number 10, can be passed and are stored with the configuration.

The source information can be used as filter criteria in the APIs to manage stored configurations.

With the November release, the enhanced endpoint PATCH /configurations will allow overwriting the source of a configuration in addition to the context:

2411 CFG Patch Source highlighted.jpg

No partial updates are possible, it is required to provide all the source information: application, type, and id.

Use case: In SAP Commerce Cloud, a user first chooses a product from the product catalog and starts the configuration. Then, the configuration is added to the cart. Finally, the cart is converted into an order. During that process the owner of the configuration changes from the product to the cart item, and finally, to the order item.

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

 

Extension Concept – Pass the Variant Factors to Extension Implementations

Variant condition keys are passed to pricing extension implementations using the corresponding pricing attribute, but the variant factors returned by the Variant Configuration service with each key are currently missing.

Remote and local pricing extension interfaces will be enhanced with the optional item input structure variantKeyFactors, allowing the pricing engine to pass the list of all variant keys with the pricing factors when calling a custom pricing routine:

2411 Variant Factors highlighted.jpg

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

 

Extensions Concept – Enhanced Blocking of JavaScript Functions During Upload

Direct access to the .constructor property used to be possible and would allow evaluating arbitrary strings in local extensions. The upload of such JavaScript code will be blocked. 

Action: Remove such JavaScript statements before uploading the code or replace them by appropriate function calls.

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

 

AdministrationAlerts in Case of High Number of Deltas

When there is a very high number of deltas that is being replicated, you might want to get notified to check if it would be faster to do a full reload as the performance of the reload is much better compared to that of the delta replication.

The Alert Notification service and SAP Cloud ALM will be used to send notifications about such big numbers of pending deltas.

It will be possible to overwrite the threshold of pending deltas that will trigger the alert:

2411 Delta Replication.PNG

 

2411 Delta Replication ANS.PNG

Only applicable for replications based on SAP HANA smart data integration. 

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

 

Administration – Rate Limits for Calls to the Administration Service

A rate limit of 5 concurrent API calls per tenant and per server instance will be introduced. The Administration service will run with at least two server instances per region.

The following error message will be returned if the rate limit is reached:
HTTP429 Error: Too many concurrent calls

Please try to reduce the number of concurrent calls and try again.

Additionally, the following limits will apply too:

  • Up to 20 extension archives can be uploaded
  • The last upload must be older than 5 minutes
  • The maximum archive file size is 20 MB
  • There shall be less than 3000 files in an archive
  • A file compressed in the archive must not exceed 30 MB
  • The uncompressed size of all files of the archive must not exceed 100 MB 

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

 

Administration – Improved variant table load for knowledge bases

The replication mechanism will be improved for variant tables of knowledge bases when reloading: Only variant tables of changed knowledge bases will be loaded.

There will be a new option to enforce a full reload, for example, after a system refresh:

2411 Variant table load.PNG

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

 

Administration – New Fields for the Display of Condition Records

New fields will be added for the display of condition records:

  • Deletion indicator (KONP-LOEVM_KO): Helps to understand why a condition record is skipped.
  • Exclusion indicator (KONP-KZNEP): Helps to understand why a condition type was skipped.

2411 Condition Record Display.PNG

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

 

 

With that, you have a good overview of what innovations are planned for the November release. Please check the updated roadmap and release notes after the release date to see which of these features were delivered as planned.

 

 

1 Comment