Technical overview of price matrix

Optimizely Configured Commerce introduced the Price Matrix early in the development process to accommodate a wide variety of different pricing schemes in a generic way. It was designed against 4 separate ERP systems to find the common architectures and pricing options so that it could offer a comprehensive and robust pricing capability and support the viewpoint that commerce should be able to be conducted without having to rely on a live connection to the ERP.

The PriceMatrix table itself is intentionally flat and non-normalized to increase efficiency and speed in price calculations. To use the price matrix structures, however, it is incumbent upon the developer to ensure they understand the pricing algorithms and pricing rules in the targeted system, typically the ERP, and then must essentially replicate that rule set. Many customers find that using real-time calls to exposed APIs from the ERP is a better approach, which Configured Commerce supports. With that in mind, it is essential that the individuals implementing the Price Matrix fully understand how the different customer and product price levels are set, both from a business and technical point of view.

Initially, the Price Matrix was rolled out using a stored procedure which, while fast, required multiple single-reads into the database. With 3.7.1 we moved from stored procedures directly to a pricing service, encapsulating all of the stored procedure logic into code. We provide the Generic pricing service as defined by the application setting PriceCalculator, which has a lot of functionality and is a good basis for building out a customized version for specific use.