How to integrate an advanced pricing system


#1

I have a product with 1 - n prices (list price, action price, bundle price…) and I don’t know how to integrate it into Pimcore. In the documentation https://pimcore.com/docs/5.x/Development_Documentation/E-Commerce_Framework/Working_with_Prices/index.html I’ve found the solution how to deal with a price attribute (AttributePriceSystem) on the product. In the best practice part https://pimcore.com/docs/5.x/Development_Documentation/Best_Practice/Advanced_Pricing_System.html there is an example how to deal with a standalone price table. But both examples will map to one attribute on the product, and in my example I have multiple price elements with several fields (quantity, valid_from, valid_until, list_price, discount).

What is the best approach to build up the price structure in the product itself? Especially in perspective regarding performance, indexing and filtering. I was thinking about blocks, but I have some concerns regarding the filtering for price ranges. Another idea could be, to create a price data object and add them as a relation to the product, but then I think I’ll loose the advantages from the pricing system at all and the performance might be a problem too.


#2

CoreShop solves that using Specific Product Price Rules, maybe you take a look at it.


#3

Hi,
it depends a bit where the prices are coming from? Are they maintained in Pimcore, or are they imported from an external system, e.g. ERP system?

If they are imported, I would go for a similar approach as in our best practice article, with the difference that the price table not only has the reference to the product-id, but also to other criteria like timerange etc.
Then the price system can filter for that additional attributes and also consider them in filtering (with custom implementation of filterProductIds).

If you need to maintain the Prices within Pimcore, you could either

  • create a custom interface for maintaining price data in an additional table
  • create custom datatype that stores price information in an additional table
  • use fieldcollections for different prices
  • go for price data objects (which would quite heavy weight)
    and then adapt your price system implementation to retrieve the data from the desired price storage (would also be possible with other data objects as you can create completely custom queries).
    I wouldn’t go for blocks, as they are stored just serialized in the database and querying and filtering them is not really possible.

BR
Christian