3.14.14
Release Date: 2025-05-14
Software Version
The document refers to the following applications and corresponding software versions:
| Application | Version |
|---|---|
| Promotion Calculation Engine | 3.14.14.RELEASE |
What's New
| Issue Key | Summary |
|---|---|
| PPCE-8440 |
Third-party library fixes Tomcat upgrade 9.0.104 (CVE-2025-31650) |
| PPCE-8417 |
Provide dummy value for RetailTransactionPromotionRecommendationFulfilledTrigger.triggerIDQualifier The triggerIDQualifier in the RetailTransactionPromotionRecommendationFulfilledTrigger is optional by definition. However, it was marked as mandatory in the GK transaction DB model by mistake. Since it can no longer be marked as optional in a fully compatible way, it was decided that the PCE should always provide a non-null value to avoid issues when persisting transactions. Therefore, from now on, the PCE provides a dummy value __N/A__ whenever there is no other meaningful value to be used in the RetailTransactionPromotionRecommendationFulfilledTrigger.triggerIDQualifier field. As a result, this field always contains a non-null value in GK contexts, regardless of which PCE API is used. This change does not affect the SAP ClientAPI format in any way. |
| PPCE-8331 |
Fix and test mapping of a general rule and eligibility in IRequestMappers PCE can now map generic eligibility and rule types to the internal model from the Recalculate Transaction Rest API. |
| PPCE-8293 |
Resolve Snyk findings CVE-2025-24813 The version of tomcat-embed-libs was increased to 9.0.102 to resolve Snyk issue CVE-2025-24813. |
| PPCE-8179 |
Resolve Snyk findings: CVE-2025-23184, CVE-2024-56128 Update dependencies to platform libraries to mitigate high security vulnerabilities revealed by Snyk tool. |
| PPCE-8140 |
ContextUtils.getSaleReturnTypeCodesForTransaction The method has been renamed and is now getAllSaleReturnTypeCodesSet. The method returns all sale return type codes which are present in the configuration regardless of a transaction content. Therefore, PCE always loads all eligibilities which are related to both sales and returns. |
| PPCE-8042 |
Transaction-related non-monetary benefit proration improved The virtual discount and loyalty points share proration of transaction-related promotions have been improved.
If all virtual discount or loyalty points shares are considered invalid, the corresponding promotion is not applied. As a result, expectations for the following JBehave stories had to be corrected:
|
Resolved Issues
| Issue Key | Summary |
|---|---|
| PPCE-8463 |
Promotion is not triggered after price increase by externally applied benefits PCE did not consider externally applied retail price modifiers that increase the price during eligibility validation. This could lead to some promotions not being applied. This bug has been fixed. |
| PPCE-8354 |
Extensibility: RebatePromotionConditionRuleSO customfield missing The processing of promotion condition rules in GK context has been corrected so that XX custom fields that may be loaded from a DB are not lost and are available to custom extensions. |
| PPCE-8352 |
External line item-related points modifier without sequence does not prevent an internal promotion from being applied An externally applied frequent shopper points modifier with prorateFrom == null and without associated retail transaction price derivation rule is now considered as line item-related and only prevents line item-related promotions from being applied on top. |
| PPCE-8337 |
Fixed missing coupon modifier references Coupon modifier references are now correctly created for every coupon used in a non-consumed way by an eligibility, even in case a previously applied eligibility already used the coupon in question with all of the available coupon count. |
| PPCE-8298 |
Incorrect handling of the ApplyPromotionsForFullyPricedItems flag If a transaction contains a transaction-related externally applied modifier or price modification line item with non-zero amount, any internal transaction-related promotion with a higher sequence and noPreviousMonetaryDiscountAllowedFlag set to true cannot be applied. |
| PPCE-8276 |
Incorrect external modifier mapping in the ClientAPI response An externally applied transaction-related modifier was mapped incorrectly in the ClientAPI response. This bug has been fixed. |
| PPCE-8260 |
Transaction-related external manual rule is not working as expected
|
| PPCE-8248 |
Corrected unexpectedly applied manually triggered promotion In case a single promotion was triggered by multiple manual triggers of the transaction (matching on both manual trigger type and value), then the promotion was applied for each trigger regardless of their calculation level. The issue has been fixed and, as a result, line item level manual triggers may only trigger line item-related promotions, while transaction level triggers may only trigger transaction-related promotions. |
| PPCE-8201 |
Fix missing ManualTriggerSequenceNumber in response Fixed missing ManualTriggerSequenceNumber in FrequentShopperPointsModifier that has been granted by the transaction-related or result-related promotion price derivation rule. |
| PPCE-8195 |
Manual triggers that are referenced to external benefit are not registered to context Any manual trigger which is associated with an externally applied modifier is registered to context from now and can trigger any further internal promotions if its sequence is higher than a sum of the externally applied manual promotion sequence and a manual trigger sequence addend. If a transaction with an already applied manual promotion was suspended and recalculated again, the same manual promotion is not applied due to the correct handling of the promotion sequence and manual trigger addend. |
| PPCE-8154 |
Added missing org.quartz-scheduler:quartz dependency to PCE The previously optional org.quartz-scheduler:quartz dependency was changed to not optional to ensure availability of the required library with the PCE delivery. |
| PPCE-8134 |
Incorrect handling of a Mix and Match promotion with OR combined threshold eligibilities Processing of a promotion with a Mix and Match rule and several logically OR combined threshold-related eligibilities has been corrected. Previously, the Mix and Match rule was skipped and not applied at all if all those eligibilities were successfully triggered but only some of them were actually fulfilled. After the bug fix, the Mix and Match rule is always calculated even if only a subset of triggered threshold-related eligibilities is fulfilled. |