A common configuration used on Commerce sites involves assigning a pair of price lists to each customer, with one price list containing the list prices for all SKUs in the catalog, and the other price list containing sale prices for the SKUs that are currently on sale (and empty values for SKUs that are not on sale). The customer profile’s priceList property is set to the price list holding the list prices, and the profile’s salePriceList property is set to the price list holding the sale prices.

When the application looks up the price of an individual SKU, the following logic is applied:

In other words, use the sale price if there is one, and if there isn’t, use the list price. The resulting value is referred to as the active price.

The Guided Search integration includes classes that support this configuration. These classes assume each customer is assigned a price list pair. There may be only one price list pair that is assigned to all customers, or there may be different price list pairs for each site in a multisite environment. For example, a multisite environment with multiple country stores might have a different price list pair for each country store, to handle different currency, catalogs, or pricing; the customer is assigned price lists based on the defaultListPriceList and defaultSalePriceList site properties for the current site.

When the Guided Search integration generates records for a given SKU, various classes are used to retrieve the data associated with specific price list pairs:

Note that if your application uses only a single price list pair, the PriceListPairVariantProducer and the PriceListPairFilterBuilder are not needed and can be disabled. If your application assigns price lists based on criteria other than site, you may need to write alternative classes (e.g., a different variant producer) to implement price-handling logic.