Vulnerability in EPiServer.Forms
We have a client that uses multiple ERPs, handles payments differently for different items, and has complex shipment logic. This forced us to break up our orders in to multiple order forms with multiple shipments. Everything has worked well with the exception of discounts that need to be facilitated/calculated across multiple order forms like whole order discounts when a threshold is met. I've been looking in to the logic changes it would take for OrderGroup level, and they seem pretty extensive.
From what I gather, I would create our own processors which look at the entire OrderGroup, and may need to implement our own version of the promotions for item specific forms, since we don't want to apply rewards in multiple order forms some times. I'm worried what this might mean to maintain, and how long it might take to implement. Has anyone else managed to do something similar. Is there a better way to implement promotions over multiple orderforms?
Judging by the lack of comments, others believed it might be more difficult than I stated. They were not wrong.
For those that are interested I ended up targetting promotion processors like SpendAmountGetOrderDiscountProcessor, extended them, and added an override for Evaluate which looked at all OrderForms to detemine if it met the requirement or not.
There are drawbacks to this, as I had to create an OrderGroupContext which loaded all OrderFormsContext which results in a loss in performance. We will also need to modify new processors as they are added to the Epi ecosystem.
I chose this method as it gave the least amount of technical debt, and would require less work than rewriting PromotionEngine, and all of the private/internal methods that may be needed with it. I started down this path originally, and found I would need a lot of duplicate code to make even the smallest change to PromotionEngine.Run().
It would be great if Epi allowed for multiple OrderForms, since it's a technically a feature devs can use. At a bare miniumum, I would love to see the PromotionEngine class, and its dependencies be made a little more modular so developers could change them if needed without rewriting all of it. We've become very spoiled with the rest of the ecosystem, and this is very difficult to modify.
We ran into a similar situation and instead of using multiple order forms, we used multiple shipments and kept a single order form. We kept shipments organized by extending a property on the shipment that allowed us to group them as needed. Then we were able to implement EntryPromotion types that used these shipment properties to select the correct shipments and look at lines in the shipment to meet the promotion criteria. Applied promotions were added with an extended property that is used to determine which shipment the promotion applied to.
The drawback with this approach, however, is it does not support dollar discounts (only percentage off) without further implementation effort, fortunately, in our case this was not needed.
I agree, it is time for Epi to fully support multiple OrderForms :)