Hi,

This is interesting. I don't have an answer right now, that would need a deep look into the promotion engine (which is the most complex code we have), but if possible:

• Which Commmerce version are you using
• What is the settings of your promotion? 

We take the rounding very seriously, but it's not easy (read, very difficult) to get right. If we can reproduce the issue, we will surely fix it in an upcoming version. 

Thanks

 - We use EPiServer Commerce v 11.2.6.0.

 - I use test product with price 11.00 USD and buy 3 pieces of it.

There are two promotions applied to order (order level and item level respectively): 

1. Spend at least X amount and receive a discount off total order value.

Spend at least X = 5.00

Get the following discount (Amount off)  = 1.00

2. Buy at least X items from catalog entries and get related catalog entries at a discount.

At the following discount (Amount off) = 1.00

So I expected that total discount will be 4.00 (3 * 1 (item discount) + 1 (order discount))

But actual total discount is 3.99 (cause item promotion discount is 2.99).

I suppose the rounding happens then discount price is applying to items.

We filed a bug for this and will look into it ASAP. Thanks.

EDIT: I think I should explain a bit. With the old system the order of evaluating promotions is strictly lineitem => order => shipping, regardless of priority. So an item promotion which priority of 100 will be applied after another item promotion with priority 1000, but will always be applied before an order promotion, even if that promotion has priority of 5000. 

In new promotion system such restriction was lifted. So the difference, in this case, is about the order which promotion applied. How should we fix this is still an open question.

Thanks for the answer.

I tried to debug EPiServer.Commerce.Marketing assembly very deeply and suspicion fell on PriceCalculationBase class in EPiServer.Commerce.Marketing.Internal namespace.

There is a method ApplyDiscountProportionally which uses Currency.Round() for calculating.

For testing purposes I removed these rounding (other behaviour of the class still unchanged) and I got expected results. Maybe this information will be usefull.  

Hello 

Quan Mai, could you please provide a ticket number to check a status of the bug

My applogies, I should have posted the work item here. It was COM-6518, but it is not yet made public (nor fixed). I'm not sure WHY, but my best guess is

"The reason that you get inconsistent results is that the priorities of the promotions are "illogical" - in the old promotion system we had a hard restriction so you always evaluated line item promotions, order promotions and finally shipping promotions. In the new system we don't enforce that restriction but it is highly recommended."

So basically we consider that is a bug, but not something of high priority.

Thanks