Suggestion: Plug-able Price Engine

Adding this to the forums for a larger discussion.

I've been thinking about the price engine and how it applies to the customization's I've made.

In my opinion it feels like price calculations have become one of the most extremely complex code segments in the core installation. Perhaps it might be doable to abstract it all away and create a core pricing engine that allows you to create pricing engine types that can be installed as plugins ('simple price','tier price', 'pricing by attribute combination','customer enters price', etc). Doing this would allow you to develop custom pricing scenario's that would have their own admin ui and portable logic code base that outputs the needed price info for the core abstract engine.

Thoughts / Opinions?

Hi Cybernexus:
I fully agree with you. Furthermore I think this becomes much more complex when we take into account discounts and promotions. I feel this is an area that has to be rethought and V4.00 could be the moment.

It's a good thought, but I wonder what the impact would be on performance if the core has to call the 'chain' of plugins looking for first to return a price (e.g. possibly in reverse order of your list "'simple price','tier price', 'pricing by attribute combination','customer enters price', etc").

Thanks a lot for suggestion! I've just created a work item here.

I would be interested to see how this can help in normal price calculation scenarios that presently require customization. For example, the one that is very common that I have to customize in each version of nop is the flexibility to adjust quantities of associated products within a kit.  Presently, the quantity of an associated product in a kit is a fixed quantity, but this scenario isn't that popular in my experience. Typically customers want to buy various quantities of items in a kit, but still only buy qty of 1 for the overall product.
So I end up just creating a custom product template with numeric input box for each attribute. Where things become complex is, within priceattributeparser, pricecalcuationservice... there is no referenced models... data is retrieved with the domain classes, so even touching quantities in those objects persists to the database.  I end up either adding the nop.web (where such a model exists) or just create a class in the services library project so that I can adjust a quantity of an attribute and pass along to the PriceCalculationService, and have discounts, etc all work correctly.  All the functions within the pricecalcuationservice and parser classes use the domain classes instead of a model equivalent (which forces even more customization).

So...long story short...if price calculations could be abstracted from the core, then I wouldn't have to copy/paste or even re-code each version of nop...I could just keep using a plugin.  I don't expect the scenario I describe above to be added to the core for the same reason this work item was created, which is, the number of possible scenarios of pricing workflows are extensive, and the core couldn't possibly account for all scenarios.  This would allow the ability to respond to business with faster solutions without customizing the core.  Hope to see this in 3.8!

New York wrote:

Hey New York,

I don't think I would write the engine mapping as a many to one. It would make more sense to have a one to one mapping because in each of the scenario's you don't really need to have multiples. I think in the end it may actually make the pricing calculations faster because each engine could be fine tuned for it's specific purpose. All of the current pricing options could easily be written and used this way.

I would probably store the mappings similarly to how scheduled tasks are stored, a table of installed price engine types and the product table would contain the id of the price engine. Then all of the setup, logic, admin configuration screens, etc could be stored as separate plugins. This would also let the end user install just the engines they need for their product line.

also in need of something like this for calculating prices based on width and height:

https://www.nopcommerce.com/boards/t/43227/nopcommerce-custom-price-calculation-rules.aspx