Time-based pricing allows you to set and configure the price of a given product or SKU for a defined amount of time. For example a SKU can be priced differently between January 1 and January 7 than during the rest of the year. Time-based pricing can also be used to create start and end dates for entire price lists, instead of just individual products and/or SKUs.
To do this, price lists are capable of containing multiple prices per price key. A price key is a SKU ID, a product ID, or a combination of the two used to look up a price in a price list. The system retrieves the multiple price items and, depending on your system settings, filters them to ensure that it obtains the correct price.
The startDate and endDate fields identify the pricing time range in the price repository item. Note that it is possible to have prices with a start date but no end date; these are prices that are considered to have an indefinite duration. It is also possible to have a price with an end date, but no start date; these are prices that are assumed to have started at some point in the undefined past. A price that has no start or end date is considered to be permanently valid, equivalent to an ordinary non-time-based price.
The process for obtaining time-based pricing is similar to the way that non-time-based pricing occurs. The following is an overview of how time-based prices are returned from a price list:
The
PriceListManageruses agetPricemethod to initiate the price retrieval process.The method looks for a cached price from the
PriceCacheand, if one is found, returns it and continues on to the next step.If there is no cache price, the
PriceListManageruses thegetUncachedPricesmethod to determine if the price list is current and then continues on to the next step.The
PriceListManageruses thelookForPricesmethod to run a query against the price list for any prices matching the required parameters.The
getUncachedPricesmethod filters the prices to ensure that, where there are multiple currently valid prices, it returns only the price that took effect most recently.Note: If two or more currently valid prices that have the same start date are found in the current price list, there is no guarantee as to which price will be returned.
A
PriceFilter, by default aDatePriceFilter, determines the most suitable price from the list of prices and returns it to thePriceListManager. The system searches for a price in the current price list. If no suitable price is found, the system turns to the base price list and begins the process of price retrieval outlined in the above steps on the base price list.Note that if the current date falls outside the period defined by the price list’s start and end dates, the price list will not be included in the search results. This means that any prices within that price list that may be inside the current date are ignored, as the price list is identified as not current.
The system searches until it finds the first price list with at least one suitable price. It selects the first price list it finds, even though, if the system continued searching, it might find other suitable price lists. For example, when running the DatePriceFilter, if the system finds a permanent price in the current price list, but there is a base price list that has a price that is valid only today, the filtering rule of “Use the price which started most recently” might suggest that the system would use the base price list’s price. However, as the system has already found another price that matches the filtering rule, it will not continue further to search the base price list.
Filtering occurs while populating the cache with prices that occur in the future, as well as when retrieving an actual price for the current time and date. Filtering during population of the cache allows the cache to include all prices for the current time and a future time. This provides some flexibility in determining when the price cache entries expire. By setting the cache to include prices for future times, you can avoid the price item’s end date dictating when the price cache entries expire. This can be helpful when maintaining a cache during times of heavy traffic. For example, if a large sale ends during the middle of a holiday rush, you may want to cache a couple of extra days’ worth of pricing so that all of the cache items do not expire the instant that the sale ends. This avoids server-intense cache repopulation during a busy time.
