Currently we use old marketing system in our solution. As I know the legacy promotion system will be completely replaced by new the marketing system.
So I started to research how the new promotion system works. My approach is very simple: I create configuration on one site with old promotion system and the same promotion configuration with new discounts on another site. After that I compare results. And I see slightly different values.
For example we have two promotions applied to our cart: item level and order level.
Old system shows the following calculation: item promotion 3.00, total discount 4.00, subtotal 30.00
New promotion system shows the following calculation: item promotion 2.99, total discount 3.99, subtotal 30.01
I can assume that new workflow or default promotion engine implementation uses intermediate rounding in calculation which leads to loss of accuracy.
I suppose that such behaviour can be handled by custom implementation of promotion engine but I am afraid that code responsible for this calculation is very deep on marketing system.
Could you please comment this behaviour or advice any possible solution.
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:
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.
- We use EPiServer Commerce v 188.8.131.52.
- 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.
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.