Show last authors
1 {{toc/}}
2
3 = Overview =
4
5 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>>doc:3\.3\.x.For Business Users.JAM - Admin App.PIM - Product information management .WebHome]]. This **gives flexibility in managing prices without worrying about product data** and plan ahead by configuring the active time frame.
6
7 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:
8
9 |=Property |=Mandatory |=Examples |=Description
10 |SKU code |(% style="color:green" %){{icon name="check"/}}|701423-L31 |SKU code that corresponds to SKU in [[PIM>>doc:3\.3\.x.For Business Users.JAM - Admin App.PIM - Product information management .WebHome]]
11 (% style="color:orange" %){{icon name="exclamation-triangle"/}} Note this relationship is weak, which means SKU code does not necessarily have corresponding SKU that exists in PIM
12 |Quantity |(% style="color:green" %){{icon name="check"/}}|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
13 |List price |(% style="color:green" %){{icon name="check"/}}|9.99 |The price of 1 unit of SKU for given quantity tier
14 (% style="color:orange" %){{icon name="exclamation-triangle"/}} It is recommended to align list price across all price records for SKU in a given period
15 |Sale price |(% style="color:red" %){{icon name="times-circle"/}}|8.99 |Sale price of 1 unit of SKU for given quantity tier. Should be less than list price
16 (% style="color:orange" %){{icon name="exclamation-triangle"/}} Sale price is optional
17 |Valid from |(% style="color:red" %){{icon name="times-circle"/}}|01-Jan-2016 23:59 |Activation time of this price record.
18 (% style="color:orange" %){{icon name="exclamation-triangle"/}} Optional and can be left blank, which indicates that record is active from beginning of time.
19 |Valid to |(% style="color:red" %){{icon name="times-circle"/}}|10-Jan-2016 23:59 |De-activation time of this price record.
20 (% style="color:orange" %){{icon name="exclamation-triangle"/}} Optional and can be left blank, which indicates that record will be always active after it had activated.
21 |Tags |(% style="color:red" %){{icon name="times-circle"/}}|xmas
22 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
23
24 In addition to basic information there are some optional advanced configurations:
25
26 |=Property |=Examples |=Description
27 |Policy |COST_Main
28 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>>doc:3\.3\.x.For Business Users.JAM - Admin App.Marketing.Price rules.WebHome]] {{html}}<span class="label label-info">YCE</span>{{/html}} and [[reporting>>doc:3\.3\.x.For Business Users.JAM - Admin App.Customers (CallCenter).Report.WebHome]])
29 |Fulfilment centre {{html}}<span class="label label-default">3.7.0+</span>{{/html}}|Main|Limits this price only to items ordered from specific [[fulfilment centre>>doc:3\.3\.x.For Business Users.JAM - Admin App.Inventory.WebHome]].
30 (% style="color:green" %){{icon name="check"/}} Useful tool for market place configurations and special prices products (e.g. damaged or used products)
31 |Price upon request {{html}}<span class="label label-default">3.5.0+</span>{{/html}}|true|Hides the price in frontend so that customers cannot see it. This allows to make the product visible without disclosing the actual price.
32 (% style="color:green" %){{icon name="check"/}} Useful tool for "request for quote" products
33 |Offer price {{html}}<span class="label label-default">3.5.0+</span>{{/html}}|true|Allows to display list price as sale price (i.e. visually styled as sale price)
34 (% style="color:green" %){{icon name="check"/}} Useful tool for automatic price imports that only provide one final price for the day but do give an indication flag that this price is limited time only
35
36 Each price record can provide its own combination of properties to facilitate various use cases. For example:
37
38 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. (% style="color:orange" %){{icon name="exclamation-triangle"/}} Products with a base price will not appear in frontend unless specified as "Showroom" in the [[inventory>>doc:3\.3\.x.For Business Users.JAM - Admin App.Inventory.WebHome]] record
39 1. **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.
40 1. **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.
41 1. **Cost (or buy in) prices** that use {{box}}COST_[fulfilment centre code]{{/box}} 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—é (% style="color:#337ab7" %){{icon name="info-circle"/}} 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
42 1. **Special prices** that use a mixture of policy and fulfilment centre configurations to provide special prices available to a specific customer niche.
43
44 = Some use cases =
45
46 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.
47
48 == 'Summer campaign' example ==
49
50 Consider the following typical set of business requirements:
51
52 1. A company has base price lists for all items that it sells online (we are going to tag these as **base** prices)
53 1. A company has bulk discounts policy on various items that it offers (we are going to tag these as **multibuy** prices)
54 1. 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**).
55
56 To make it simple we are going to consider a single SKU "A001" with the following pricing parameters:
57
58 1. Base price for A001 is 9.99
59 1. A001 has multi buy discount of 30% on 50 items or more (i.e. 6.99)
60 1. A001 will participate in "Summer" campaign (i.e. Summer price is 8.99, then in July 7.99 closing in August with 4.99)
61
62 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.
63
64
65 (% style="text-align:center" %)
66 [[image:yc-3.7.0-marketing-calc-summer-campaign.png]]
67
68
69
70 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.
71
72 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**.
73
74 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.
75
76 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.
77
78 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.
79
80 In September all summer campaign price records are now expired and we revert to the **base** and **multibuy** prices.
81
82 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**.
83
84 == VIP customer example ==
85
86 Consider the following typical set of business requirements:
87
88 1. A company has base price lists for all items that it sells online (we are going to tag these as base prices)
89 1. A company has bulk discounts policy on various items that it offers (we are going to tag these as multibuy prices)
90 1. 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)
91
92 To make it simple we are going to consider a single SKU "A001" with the following pricing parameters:
93
94 1. Base price for A001 is 9.99
95 1. A001 has multi buy discount of 30% on 50 items or more (i.e. 6.99)
96 1. A001 will participate in "VIP" campaign with special price 7.99 on the basis of **VIP** policy
97
98 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.
99
100
101 (% style="text-align:center" %)
102 [[image:yc-3.7.0-marketing-calc-vip.png]]
103
104 == Discounted stock example {{html}}<span class="label label-default">3.7.0</span>{{/html}} ==
105
106 Consider the following typical set of business requirements:
107
108 1. A company has base price lists for all items that it sells online (we are going to tag these as base prices)
109 1. A company sometimes encounters products with damaged packages but otherwise fully functional, which it would like to sell at a discounted price
110
111 To make it simple we are going to consider a single SKU "A001" with the following pricing parameters:
112
113 1. Base price for A001 is 9.99
114 1. Discounted price for A001 with damaged packaging is 8.99
115
116 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.
117
118 (% style="text-align:center" %)
119 [[image:yc-3.7.0-marketing-calc-damaged.png]]
120
121
122
123
124 = Price list management =
125
126 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.
127
128 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>>doc:3\.3\.x.For Business Users.JAM - Admin App.PIM - Product information management .Product data.WebHome]]. 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.
129
130 (% style="color:orange" %){{icon name="exclamation-triangle"/}} 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).
131
132 (% style="color:red" %){{icon name="times-circle"/}} 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>>doc:3\.3\.x.For Business Users.JAM - Admin App.Marketing.Taxation.WebHome]] documentation, which explains this topic in detail.
133
134
135 (% style="text-align:center" %)
136 [[image:yc-3.7.0-marketing-price-management.png||alt="yc-3.0.0-marketing-price-management.png"]]
137
138 (% style="color:#337ab7" %){{icon name="info-circle"/}} 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)
139
140
141 It is anticipated that most of the price list management will be done via [[import/export>>doc:3\.3\.x.For Business Users.JAM - Admin App.Import and Export.WebHome]] facility automatically. In case of manual management [[manual import/export>>doc:3\.3\.x.For Business Users.JAM - Admin App.Import and Export.Manual ImpEx.WebHome]] facility will also be useful when managing prices for large catalogs.
142
143 = Validating prices configurations =
144
145
146 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.
147
148
149 (% style="text-align:center" %)
150 [[image:yc-3.7.0-marketing-prices-tester.png]]
YesCart.org © 2009 - 2020
v.1.0.0