3.3.11

Accept the TriggerSequenceAddend for externally applied manual promotions

The TriggerSequenceAddend is now considered for externally applied manual promotions. This means that the next promotion that could be applied internally must have a sequence that is greater than the sum of the sequences from an externally applied promotion and the TriggerSequenceAddend.

Change logging level to WARNING in case an invalid value is to be used for a system parameter but default value is used instead

Logging level has been changed from ERROR to WARNING in case an invalid value is to be used for the system parameter but the default value is used instead. Unified logging in case null value was used. Redundant logging has been removed.

Unify validation algorithm for points and discounts

Unified the validation algorithm for points and discounts for the line item-related total price modification methods.

PCE validators - Remove redundant validation

Calculation result validation has been improved and redundancy has been removed.

The PCE core implementations of the LineItemRebateValidator interface were split into three parts:

• LineItemZeroRebateValidator
• NegativePriceRebateValidator
• PriceIncreaseRebateValidator

Refactor use of ManualRuleWrapper

The PCE internal ManualRuleWrapper class was refactored and optimized. After the changes, the manual rule wrapper was added to the PCE's model API to make sure that it is stable for release. Separate default and GK-specific implementations are maintained now. The latter allows convenient access to the GK-specific custom fields of the rule. The use of the ManualRuleWrapper was optimized so the previously observed double rule wrapping is now avoided in all cases.

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.

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

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.

ComputationBaseAmount on PriceModificationLineItem is not calculated correctly

The value of the ComputationBaseAmount on the PriceModificationLineItem has been fixed. The reason was the wrong value of the amount on the external RPM of the normalized return line item that has been set to zero. Now there is a correct non-zero value.