I am working on Commerce 12.15.0, we have a requirment to calculate the promotions on Regular price and not the placed price. For example:
SKU 001 has a Regular Price $10 and Sale Price $8. Upon entering a valid coupoun the discount is currently applied on the placed price which is $8 by default. But the client wants to apply the discount on Regular price and then honor the lowest price between the two (Discounted Regular Price and Sale Price). So if the Discount is 50% off, then the Discount is applied to regular price which makes it $5 and then compare the Discounted Regular Price and Sale Price and take the lowest price between the two.
So should I have my own implementaton of the IPromotionEngine interface or should I create a new promotions processor? This is my first time working with promotions, I apprecite any ideas on how to approach this.
With the current implementation, I think it's impossible to customize your case. The promotion system works only with PlacedPrice and the logic is internal core, so you can't override that.
Only workaround I can see would be to set the lineitems' placed price to your regular price and store your sale price in a custom meta field.
It would require you to only use your own custom promotions that all compares their discounted price with the sale price, as well as a custom line item calculator that makes sure to use the right price in the calculations of totals.
Thanks Erik for your suggestion. However, I can see a complicated logic handling for all other modules in EPi that use PlacedPrice all the time like "IPriceService", "DefaultPlacedPriceProcessor" and even Commerce Manager carts\purchase orders modules.
When customizing the promotion system like this there will undoubtfully arise other issues that needs to be taken into account. For example:
What happens if you have a LineItem with Quantity >= 2 and only one of those is applicable for a discount that would make the price lower than the sale price? With this situation you'd end up with a LineItem with two different "base" prices. Or some kind of inbetween price that probably would confuse the customer and/or your accountants. :)
@Siddharth Gupta: did you end up with a solution to your case? I am having the exact same problem.
@Toke Frostholm: Sorry for the late reply, have a look at the link mentione below: