3.14.13

Triggering line items without benefit do not get modifier references when the total price modification method is used

As long as the promotion is successfully applied, all triggering items get a modifier reference, even if they do not get any benefit due to price increase, zero discounts or for any other reason.

M&M does not grant zero virtual discount when allowZeroRebate is set to false

Zero virtual discount (virtual discount types are: GIFT_CERTIFICATE("01"), TENDER("02"), COUPON("04"), MANUFACTURER_COUPON_TENDER("99")) must always be applied regardless of the rule type and allowZeroRebate flag state. This bug has been fixed.

Exception when deserializing an unknown eligibility during recommendation

The GK-specific object mapper has been configured so that it does not fail when an unknown eligibility type is loaded during a recommendation process.

NPE during validation of an unknown eligibility type for recommendation when TRACE log level is active

During validation of an eligibility with an unknown eligibility type for recommendation, the PCE could throw a null pointer exception when a TRACE log level was active. This bug has been fixed.

GiftCertificateExpirationDate in PCE response contains time zone information

Description of the GiftCertificateExpirationDate in the swagger file describing the recalculate-transaction API v1 has been updated to match the current format of a value returned by the PCE. The time zone or even the time information itself is not needed there, but changes to the data format could cause compatibility issues on the client side. This is why the time zone information is still provided in the recalculate-transaction v1 response as before.

ExclusiveConditionDiscountablePositionHandler performance issue

A bug that caused significant performance degradation when a transaction-related promotion was applied on top of a line item-related promotion has been fixed. In addition, the ExclusiveConditionDiscountablePositionHandler also considers FrequentShopperPointsModifiers and externally applied modifiers from now on.

RPM for applied transaction-related promotion is missing in the transaction

If a single transaction-related manual promotion was applied multiple times due to several manual triggers registered in a transaction with different trigger sequence numbers, and if that manual promotion conflicted with some other promotion(s) and the Brute Force conflict resolution algorithm was used to resolve the conflicts, then some retail price modifiers or frequent shopper points modifiers for successfully applied promotions might be missing in the result transaction. This bug has been fixed.

Zero transaction-related points validation

Bonus points validation for transaction-related promotions was unified with discount validation. A bug that prevented the creation of a zero frequent points modifier when it was allowed has been fixed. LineItemRebateValidators and RebateValidators are now called after the discount share is calculated.

Zero position-related non-total points validation

Bonus points validation for line item-related promotions with non-total price modification methods was unified with discount validation.

Fix missing handling for manufacturerCouponPromotionTenderTypeCode and benefitChooseItemMethod

Handling of the system parameters manufacturerCouponPromotionTenderTypeCode and benefitChooseItemMethod has been fixed so that they are no longer ignored by the PCE.

Promotions with the same sequence and different resolutions applied to the same item if TransactionRebateMethod=TOTAL

Handling of transaction-related promotions in the case of TransactionRebateMethod value TOTAL has been corrected. Prior to the fix, if a line item was not used as a trigger but received a benefit because it was used for the calculation base amount due to the TransactionRebateMethod value TOTAL, such a line item may have received further benefit from another promotion with the same sequence and a lower resolution or, even worse, from another promotion with the same sequence and the same resolution. From now on, only one transaction-related promotion with a given sequence can use any line item as a trigger or grant it a benefit.

Correct handling of "not consumed" coupons

Coupon consumption code NOT_CONSUMED(02) now behaves as "consumed per transaction".

When a promotion with such a consumption code is applied, the coupon is consumed by a transaction and is not available for subsequent promotions with a different consumption type (CONSUME(00) and CONSUME_PER_ITEM(01)). However, the coupon consumed by a transaction will be available for subsequent promotions with the same type of consumption (NOT_CONSUMED(02)).

See the Functional Guide for more details.

NPE when some fields are not specified in the external modifier

PCE code for mapping a ClientAPI request and response has been adjusted to not throw a NullPointerException when any optional field is missing in a modifier or a modification line item is added to the request for an externally applied promotion price derivation rule.

Corrected appliedQuantity for prorated Buy N Get M benefit

The retailPriceModifier's appliedQuantity value has been corrected for Buy N Get M benefits which are prorated between all triggering items. Prior to the fix, the appliedQuantity contained the quantity of all triggering items - in this scenario, the quantity of proration items. This was corrected according to the specification, which says that the appliedQuantity is the sum of the quantity of all discounted items.

Externally applied benefits are not considered and, at the same time, points proration is wrong for bonus points transaction-related promotions

Within this task, two problems related to bonus points transaction-related promotions were fixed. First, it has been fixed that externally applied benefits are considered. In addition, it has been fixed that proration for each line item is calculated correctly.

Line items are not sorted according to their sequence number for Recalculate Transaction API

The sorting of line items according to their sequence number for Recalculate Transaction API has been fixed.

ProrateFrom link not referring to the correct line item

Inconsistency in sequence numbers has been fixed. ProrateFrom link is now referring to the appropriate line item - either PriceModificationLineItem or LoyaltyRewardLineItem in the most cases. Regarding backwards compatibility, inconsistency can occur only in some edge cases.

Wrong mapping of the external RPM's action code in ClientAPI

If PreviousPrice or NewPrice parameters are missed in the request in the externally applied Retail Price Modifier, the amount's action code in the response may be wrong. The bug has been fixed and now the action code in the response is the same as in the request for the externally applied Retail Price Modifiers.

NPE with Greedy - Multiple CSP promotions

If multiple conflicting Customer Specific Price promotions with the same sequence and resolution are resolved by the Greedy conflict handler resolution strategy, a null pointer exception may be thrown. This bug has been fixed.

Bugs in conflict resolution algorithm

Two bugs in the conflict resolution algorithm(s) have been corrected:

1. The conflict resolution algorithm no longer stops completely if a group of conflicting partial results was fully resolved by a conflict resolution pre-processor
2. The algorithm correctly splits conflicting partial results into independent groups and no longer produces any ghost groups that only bring calculation overhead

NPE is thrown in case manual eligibility is present but manual trigger is missing

NPE has been fixed in cases where an ad-hoc promotion contains a manual trigger eligibility but the manual trigger in the line item is missing.

MAPO modifier on a weighted line item with a fixed price leads to lower discount

A bug in the normalization of external and MAPO modifiers in a line item with a fixed price has been corrected. Such modifiers no longer lead to a reduction of the calculation base amount because of rounding and therefore to a lower discount of regular promotions applied by the PCE.

Incorrect detection of the independent promotions for best price calculation

If, for some reason (e.g. due to a limit), the trigger item did not receive a benefit from a promotion, then it was considered as not related to this promotion. This could lead to incorrect identification of independent promotions and incorrect calculation of the best price. This bug has been fixed.

Fix mapping of the LoyaltyRewardLineItem

Mapping of a LoyaltyRewardLineItem from the ClientAPI request to the internal PCE data model and back to the ClientAPI response was fixed. Now, all appropriate values (PointsAwardedCount, FrequentShopperPointsEarnedAmount and CalculationBaseAmount) are correctly inverted based on a transaction category.

Negative values in ClientAPI response on the PriceModificationLineItem are not allowed

Mapping of a PriceModificationLineItem from the ClientAPI request to the internal PCE data model and back to the ClientAPI response was fixed. Now, all appropriate values (Amount, ExtendedAmountBeforeModification, ExtendedAmountAfterModification, ExtraAmount and CalculationBaseAmount) are inverted correctly.