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:
| Property | Examples | Description | |
|---|---|---|---|
| Policy | COST_Main VIP | Policy allow to mark given price record with special access. This is very effective to hide prices from common customers (e.g. only VIP customers should see this price) or all customers (e.g. keep track of internal prices such as "buy in" or "cost" prices, which set basis for price rules | |
Fulfilment centre | Main | Limits this price only to items ordered from specific fulfilment centre.
| |
Price upon request | true | Hides the price in frontend so that customers cannot see it. This allows to make the product visible without disclosing the actual price.
| |
Offer price | true | Allows to display list price as sale price (i.e. visually styled as sale price)
|
Each price record can provide its own combination of properties to facilitate various use cases. For example:
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 |
Cost (or buy in) prices that use 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 |
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.
Consider the following typical set of business requirements:
To make it simple we are going to consider a single SKU "A001" with the following pricing parameters:
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.
Consider the following typical set of business requirements:
To make it simple we are going to consider a single SKU "A001" with the following pricing parameters:
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.
Consider the following typical set of business requirements:
To make it simple we are going to consider a single SKU "A001" with the following pricing parameters:
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.
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.
| Note that SKU must have price for it to be purchasable. If the platform cannot resolve price for SKU the product will not have option to be added to cart or even be shown in searches unless it has inventory record set to "Showroom" availability (which is not purchasable). |
Price that are entered into price list can be either NET (without tax) or GROSS (including tax), which depends on the tax configuration. It is up to business to decide which "mode" will suit best for price management. See taxation documentation, which explains this topic in detail. |
| Two products appear side by side as for purpose of this demo there are two offers: one from Main fulfilment centre and one from damaged items, to show the difference. If you have only one fulfilment centre only one product will be shown with best value price (i.e. lowest) |
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.
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.
