|Number of votes:||2|
Overriding how sale prices are calculated in Episerver’s promotion engine for SKUs and packages outside of the cart requires a minor customization. Good examples of where this applies are category landing page and product detail pages where you may show a discount price(s). Sales price calculation is usually done by a) evaluating the prices associated with a SKU or package and b) applying the site’s business rules to determine the correct price of an item for a customer. The sales price is calculated in the promotion engine to determine the price from which to subtract the promotion discounts. As I previously mentioned here, using the PromotionEngine GetDiscountPrices() method involves an important constraint: It has a default sale price calculation built in which may or may not fit your site’s business rules. Here is how to customize the promotion engine to use alternate pricing calculation logic.
The sale price for items to be evaluated in the promotion engine is calculated in the PromotionEngineContentLoader class by calling the ReadOnlyPricingLoader GetDefaultPrice() method. This method returns the lowest “All Customer” price for an item that has a valid date and is the correct currency and market for the current customer. So it doesn’t use customer-specific, price group, or custom sale price types to calculate the sale price. An instance of PromotionEngineContentLoader is stored in the IOC container and used in the promotion engine - so it can be overridden in your implementation.
To override this sale price calculation in the promotion engine, create a class that inherits from PromotionEngineContentLoader and then configure your IOC container to use this new implementation. Here’s an example of how you can do this:
Notice that an IOrderGroup is used to contain the SKU or package. The InMemoryOrderGroup is simply an implementation of that interface that allows carts and one-off SKUs or packages to be processed for promotion calculation in the same way. This also simplifies promotion calculation. It allows for the custom promotion processors (see here) that you create to simply process the IOrderGroup instance rather than having separate methods for one-off items and carts. The PromotionProcessorContext class contains an IOrderGroup property and is passed into the Evaluate() method for promotion processor classes.
Finally, add initialization of your IOC container to point to your custom implementation like this:
The ModuleDependency ensures that the new implementation is set/used, overriding the original implementation set in Episerver’s commerce initialization module.
As you can see, overriding the promotion engine sale price takes very little effort. I think the new promotion engine has made calculating discounts a lot easier with a straight-forward and exposed model that can be overridden.