3.7.24

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.

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.

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.

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

A bug that prevented the creation of a zero frequent points modifier when it was allowed has been fixed.

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

Handling of the system parameter manufacturerCouponPromotionTenderTypeCode has been fixed so that it is 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 null pointer exception 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.

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

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.

Discount tx-related proration calculates wrong result for SALES_MINUS_RETURNS and new price

Transaction-related monetary discount promotion with SaleReturnCode = SALES_RETURNS/"00", calculationBase = CALCBASE_01/"01" and PriceModificationMethodCode = NewPrice could not prorate the benefit correctly in case a mixture of sold and returned items was present in a transaction. This bug has been fixed.

Bonus points tx-related proration is not working for SALES_MINUS_RETURNS

Bonus points transaction-related promotion with SaleReturnCode = SALES_RETURNS/"00" and calculationBase = CALCBASE_01/"01" could not prorate the benefit correctly in case a mixture of sold and returned items was present in a transaction. This bug has been fixed.

Amount value of an external RPM on a return line item is processed incorrectly

Mapping of a RPM on a return line item 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.

Customer points not calculated for some item combinations

Under a very specific set of conditions, including a certain number of normalized line items, a certain number of colliding but not conflicting line item-related promotions and a presence of a custom RebatableItemFilterPlugin which rejects a certain subset of normalized line items as triggers, the remaining normalized line items might not be available at all for other line item-related promotions with a sequence and a calculationBaseSequence value equal to or higher than the sequence of the previously applied colliding promotions. This bug in the product PCE code has been corrected.

Coupons are consumed by promotions with CONSUMPTION_02

If a coupon promotion with CONSUMPTION_02 was applied, the coupon was consumed for any further promotion with CONSUMPTION_01 or 00 preventing such a promotion to be applied. This bug has been fixed.

Incorrect ExtendedAmountBefore and AfterModification on the normalized item level

Correction of value-computation for fields (ExtendedAmountBeforeModification and ExtendedAmountAfterModification) on the normalized item level in case line item-related and transaction-related promotions are applied at once.

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.