Overview

Price lists facilitate product pricing strategy and represent an independent data structure which allows to enter prices for SKU code that have not yet been set up in PIM. This gives flexibility in managing prices without worrying about product data and plan ahead by configuring the active time frame. 

At the fundamental level price list consist of many price records. Each record represents list and sale prices of a SKU at particular moment in time for a given quantity. To be a little bit more specific and bring in some of the terminology here are some details on the properties of price record:

Property	Mandatory	Examples	Description
SKU code		701423-L31	SKU code that corresponds to SKU in PIM   Note this relationship is weak, which means SKU code does not necessarily have corresponding SKU that exists in PIM
Quantity		1	Price record activation quantity (quantity tier). For example quantity of 1 means that list/sale prices are available for given SKU when 1 or more items are in cart. Quantity 10 would mean that customer has to add at least 10 items of this SKU to activate this price
List price		9.99	The price of 1 unit of SKU for given quantity tier   It is recommended to align list price across all price records for SKU in a given period
Sale price		8.99	Sale price of 1 unit of SKU for given quantity tier. Should be less than list price   Sale price is optional
Valid from		01-Jan-2016 23:59	Activation time of this price record.   Optional and can be left blank, which indicates that record is active from beginning of time.
Valid to		10-Jan-2016 23:59	De-activation time of this price record.   Optional and can be left blank, which indicates that record will be always active after it had activated.
Tags		xmas summer2016	Tag can be used by business user to group together price records belonging to a specific price campaign, such as Christmas or Summer sales

In addition to basic information there are some optional advanced configurations:

Each price record can provide its own combination of properties to facilitate various use cases. For example:

1. Base list prices provided by price records with list price at quantity 1, no sale price and no from/to time to indicate that it is always available. It is recommended to keep single base list price record for each SKU available in shop to ensure default price is always available.

    Products with a base price will not appear in frontend unless specified as "Showroom" in the inventory record
2. Sale prices provided by price records with list price and sale price at quantity 1 and may optionally define from/to time period. There can be many sale price records with different from/to periods, even when timeframes overlap. The platform will automatically deduce best customer value sale price for current point in time for current customer.
3. Multi buy prices following the same rules as sale prices and allow to take them one step further by also checking the current quantity in customer shopping cart to provide bulk discounts. Major difference in multi buy price record is that quantity tier is greater than one.

4. Cost (or buy in) prices that use  COST_[fulfilment centre code]  policy naming convention (e.g. COST_Main), which allow to track the cost of the product to the business and are useful for automatic price generation and reporting   

   Cost prices are automatically resolved and saved with placed orders enabling generation of profit/loss reports and aiding  any other audit, export or reporting function
5. Special prices that use a mixture of policy and fulfilment centre configurations to provide special prices available to a specific customer niche.

Some use cases

Topic of pricing strategy is quite difficult due to multitude of influential factors, so it is probably easier to go though a simple examples to bring some context to the discussion.

'Summer campaign' example

Consider the following typical set of business requirements:

1. A company has base price lists for all items that it sells online (we are going to tag these as base prices)
2. A company has bulk discounts policy on various items that it offers (we are going to tag these as multibuy prices)
3. During Summer company will offer 10% discount on a range of products (tagged as SummerXX), with discount increasing to 20% in July (tagged as JulyXX) and then going into clearance with 50% discount in August (tagged as AugXX).

To make it simple we are going to consider a single SKU "A001" with the following pricing parameters:

1. Base price for A001 is 9.99
2. A001 has multi buy discount of 30% on 50 items or more (i.e. 6.99)
3. A001 will participate in "Summer" campaign (i.e. Summer price is 8.99, then in July 7.99 closing in August with 4.99)

Figure below depicts the price records data entries and corresponding price resolution, which customers will see at certain points in time. Arrow at the bottom of the diagram denotes timeline stating months which correspond to customer page views.
 

All price records are entered before the summer campaign starts. Each price record corresponds to business pricing requirements in relation to "A001". Base price record is the ultimate fallback value of A001 for purchases of one item and more. Multi buy price record has quantity tier set at 50, thus making sale price applicable only for quantities 50 or above. We have three summer campaign sale price records. Note that 10% discount sale price has timeframe between 1st June and 31st August overlapping July and August records (thus this is the fallback value for this period). Then for July we provide 20% discount sale price and in August we provide 50% discount sale price. Altogether these five price records represent the business requirements that we described at the beginning of this example.

When looking at month of May it can be noted that base price takes effect on product details, search results and small quantity cart pages. For large quantity cart page multi buy price takes effect since its sale price is less than base and therefore represents the best customer value price.

Moving into June SummerXX price record is activated. Now there are two active records: base at 9.99 and SummerXX at 8.99. The best customer value price is 8.99 and therefore will be shown to the customer. However for bulk purchase cart multi buy at 6.99 is better offer and hence multi buy is still used.

In July three records are active: base at 9.99, SummerXX at 8.99 and JulyXX at 7.99. The best customer value price is 7.99 and therefore will be shown to the customer. However for bulk purchase cart multi buy at 6.99 is better offer and hence multi buy is still used.

Going forward to August three records are active: base at 9.99, SummerXX at 8.99 and AugXX at 4.99. Note that JulyXX has expired and therefore is not considered anymore. The best customer value price is 4.99 and therefore will be shown to the customer. Bulk purchase cart multi buy at 6.99 now offers worse value, so 4.99 is used instead thus making all prices at all quantities align with 4.99.

In September all summer campaign price records are now expired and we revert to the base and multibuy prices.

Note that business user enters the 'summer campaign' prices long before the campaign starts and does not need to make any adjustments during the campaign, which gives freedom to plan ahead. Another interesting point is that JulyXX and AugXX where overlapping with SummerXX, so if for some reason business decided to withdraw 50% discount in August only that record would need to be removed and SummerXX sale at 10% would still remain thus preventing disagreement with the original campaign. This layered approach allows to create long term and short term pricing strategies as well as enable quick changes according to business needs in this rapidly changing and competitive environment.

VIP customer example

Consider the following typical set of business requirements:

1. A company has base price lists for all items that it sells online (we are going to tag these as base prices)
2. A company has bulk discounts policy on various items that it offers (we are going to tag these as multibuy prices)
3. A company has a number of VIP client to which it wishes to provide special prices for specific products which they often buy  (tagged as vip)

To make it simple we are going to consider a single SKU "A001" with the following pricing parameters:

1. Base price for A001 is 9.99
2. A001 has multi buy discount of 30% on 50 items or more (i.e. 6.99)
3. A001 will participate in "VIP" campaign with special price 7.99 on the basis of VIP policy

Figure below depicts the price records data entries and corresponding price resolution, which customers will see depending on their pricing policy configuration in their profile.

Discounted stock example 3.7.0 

Consider the following typical set of business requirements:

1. A company has base price lists for all items that it sells online (we are going to tag these as base prices)
2. A company sometimes encounters products with damaged packages but otherwise fully functional, which it would like to sell at a discounted price

To make it simple we are going to consider a single SKU "A001" with the following pricing parameters:

1. Base price for A001 is 9.99
2. Discounted price for A001 with damaged packaging is 8.99

Figure below depicts the price records data entries and corresponding price resolution, which customers will see when they add A001 either from main fulfilment centre or damaged packaging fulfilment centre.

Price list management

SKU price records are managed per shop per currency using the price lists management section. This section provides various searching capabilities by SKU code, product name and by tags. The match is partial by default to allow business user quick searches without having to type full SKU code or tags. 

Adding SKU price requires SKU code and list price (currency and shop are automatically used from current view). Note that SKU code does not necessarily needs to match the existing SKU data. If the SKU code does correspond to an existing SKU data the table with price records will display SKU name, otherwise the SKU name will remain blank. "Quantity" represents the quantity tier of given SKU. "List price" represents the base price for a SKU, whereas "Sale price" (which is optional) represents discounted list price. "Valid from" and "Valid to" define price record active period. If left blank the platform assumes that record is always available.

It is anticipated that most of the price list management will be done via import/export facility automatically. In case of manual management manual import/export facility will also be useful when managing prices for large catalogs.

Validating prices configurations

With complex prices and promotions setup it is sometimes difficult to determine which price will be applied at what time frame. This is where prices tester tool can help in many ways. It allows to create a combination of products with corresponding quantity tears and specify additional parameters such as fulfilment centre and shipping method. The end result is like for like calculated cart for give setup that shows exactly which price will be applied and any promotions that might trigger in the process as well as taxes applied. Moreover the tool allow to set time frame for when the calculation should occur thus giving the opportunity to test what will happen as time elapses.