Pricing System

Elements

"Product price" means the sale price of a product. The system covers regular prices and offer prices, so to set the price of a product properly the following elements are required:

Base Price: The price of a product or option when the product is not marked as being on offer.
Offer Price: The price of a product or option when the product is flagged as on offer. The offer price is applied when the product is flagged as being on offer; higher than zero, but less than its base price. Also, in this case the base price is set as the previous price ("before...") to the offer ("now...").
Offer: This is a boolean operator (true or false) indicating whether the base price or the offer price is to be applied.

Products on offer are not considered as discounted products. Discounts are a tool for making a deduction from the sale price at the time of purchase, while the offer is a sale price too, simply temporarily lower than the usual price for whatever reason. So, it is normal to have the option of giving discounts on the offer price of a product. However, exceptions can be made, as explained below.

These three elements can be present in any of the types of price outlined below.

Types of Price

"Types of price" means groupings of product prices established in very specific situations. These are the collections available:

• Base rate

• Pricing policy

• Price list

• Percentages (prices by percentage)

The amount finally applied as the price payable in the shopping cart will be determined according to well-defined criteria (described below).

Base Rate

"Base rate" means the initial price of products, before applying any kind of price list or policy on pricing, percentages or discounts. The base rate defines the sale price if no other modifier alters it.

Pricing Policy

"Pricing policy" means the set of requirements or definitions whose function is to replace the base rate price of a product. These definitions are based on user filters, user groups, countries or areas of countries. Prices are said to be replaced because the amounts in the base rate are replaced by the amounts defined in the pricing policy that meets the most specific requirement.

"Most specific requirement" means the criterion that carries the most weight. The weight of the criterion is governed by a specific order defined in advance and taken into account when deciding which filter to use when more than one applies at the same time; these filters are described below.

As pricing policies replace prices, they can generate offers where there were none before or, on the contrary, eliminate existing offers.

Example:

Product1:

An ordinary user will buy Product1 for €5 (as it is on offer). A user in the "VIP" group will buy it for €3 (as they fulfill the requirement of belonging to the "VIP" group and the product is on offer). A user in France will buy it for €12 (as they fulfill the requirement of being in France and the product is not on offer).

*What happens if a user is from France and also belongs to the "VIP" group? The requirement that carries more weight is applied; in this case, belonging to the "VIP" group (see the explanation below).

Price List

When you create a price list you define a set of prices for the purpose of replacing the price in the base rate for a product. The amount used to substitute it may be the result of applying a percentage increase or reduction (calculated price list) or of a figure defined directly (no base rate or manual price list). In the case of the calculated price list, the percentage increase or reduction can be applied to the base rate or to another list of prices defined beforehand.

Price lists are defined on the basis of user filters, user groups, countries or areas of countries. As before, prices are said to be replaced because the amounts in the base rate are replaced by the amounts defined in the price list that meets the most specific requirement.

The difference between a pricing policy and a price list is that the price list can calculate the final sale price using a percentage. Another important difference is that the price list cannot change the offer status of a product, even if the offer price was included in the price list.

In price lists filters by warehouse can be set up (these are applicable if the warehouse fulfilling the order is the one selected by the system). However, this cannot be done with pricing policies.

Example:

Product1:

An ordinary user will buy Product1 for €10 (as it is not on offer). A user in the "VIP" group will buy it for €8 (20% of 10, as they fulfil the requirement of belonging to the "VIP" group and the product is not on offer). A user in France will buy it for €9 (10% of 10, as they fulfil the requirement of belonging to France and the product is not on offer).

*What happens if a user is from France and also belongs to the "VIP" group? The requirement that carries more weight is applied; in this case, belonging to the "VIP" group (see the explanation below).

Percentage

"Prices by percentage" means the set of definitions creating a series of amounts as the result of applying a percentage increase or reduction to a particular pricing policy, price list or base rate. It acts as an additional layer that corrects the price provided with a pricing policy, price list or base rate (the one used to meet the most specific requirement).

Percentages also use user filters, user groups, countries or areas of countries. As before, prices are said to increase or decrease because their amounts up to now are replaced by the amounts calculated on the basis of the percentage set in the definition of the percentage that meets the most specific requirement.

Definitions of percentages cannot generate filters by themselves but are based on filters established by the pricing policies or price lists. For example, you can apply a percentage increase to Policy1 or List1 (based on the filter for users belonging to the "VIP" group), but if this pricing policy or price list does not exist, a percentage applicable to the "VIP" group cannot be either created or increased for this group.

Percentages are generally defined at category or product level. Definitions can be inherited, so that if a percentage has been applied to a main category the secondary ones implicitly inherit this percentage, unless the said percentage is individually, explicitly redefined for a secondary category or for a product in any of the secondary categories. For categories that have no percentage defined, either at category level or at a higher level (in any of the main categories), the value is assumed to be 0% and the prices do not vary.

Prices by percentage are also known as Pricing Policy by Category, as because these percentages can be applied to categories, they can define increases or reductions only in certain categories or product families.

Calculating the Price

You can set prices for products and for options. The amounts you specify for the options will always be added to those you defined for the product. Prices of both products and options can be defined on the basis of the base rate, price lists or pricing policies. This could lead to a user seeing more than one price.

To set the order the system will follow when obtaining a single price, you must be aware that on the one hand you have the pricing policies and price lists, and on the other the filters to be applied (user filters, user groups, countries or areas of countries).

This is the order in which the filters are applied:

1. User

2. User group

3. Country

4. Area

Therefore, in price lists through each of these filters, in the event of a "draw", the price list set for specific users applies first, then the one set for groups of users, then that for countries, and finally the one set for areas. The same happens with pricing policies. Following the above example, a user in the "VIP" group and from France would have the list or policy set for the "VIP" group applied to them.

If you have price lists and policies created with the same filters, they are applied in the following order:

1. Pricing policy based on users

2. Pricing policy base on user groups

3. Price lists

   1. List based on users

   2. List based on user groups

   3. List based on countries

   4. List based on areas

4. Pricing policy based on countries

5. Pricing policy based on areas

6. Base rate

So, pricing policies take priority over price lists only if they are based on users or groups of users; they do not take priority over price lists if they are based on countries or on areas. If no policy or list meets the requirements of the filter, the base rate price will always be applied in the end.

Applying Percentages

After retrieving the price from the right list or policy by following the order defined, the percentage according to your definition, if any, will be applied regardless of the price used.

For any product, the system first gets the price by examining the price lists and policies. Then it looks to see whether there is any definition by percentage created explicitly for this product; if it finds one and it is compatible with the filter, it applies the percentage to the amount found. If not, it checks whether the product category has a percentage defined; if it finds one and it is compatible with the filter, it applies the percentage. If not, the system checks whether the main category has a percentage defined, and so on until it reaches the root.

Resuming Product1 example: You have the same List2, the same Policy2, a new Policy3 (applicable to users in Europe) and a user located in France. Supposing that you have defined product level percentages based on Policy2, Policy3 and the base rate, and category level percentages based on List2, Policy2, Policy3 and the base rate:

Without considering the percentage applicable to it, the price would be defined by List 2 (€10 - 10% = €9) because, according to the criterion mentioned above, the price list takes priority over a policy defined by country.

The system then checks whether there is a percentage defined at the product level (for Product1) and finds those based on the definition in Policy2, Policy3 and the base rate. Following the criterion of order of application, the system takes that in Policy2 because the country filter takes priority over the area filter (and of course over the base rate).

Therefore, the price will be: €9 + 5% = €9.45.

Imagine now that there are no percentages defined at the product level, only at category level. The system checks whether there is a product percentage defined (for Product1) and does not find anything. It then checks at category level and finds the percentages based on the definition of Policy2 and List2.

Following the criterion of order of application, the system takes the percentage in List2 because price lists take priority over policies by countries.

Therefore, the price will be: €9 -20% = €7.20.

Additional Configuration of Percentages

It is possible to change the behavior of the percentage definitions when you configure them. You can activate the parameter Apply to Base Rate. Once activated, policies and lists are ignored, and the percentage is always calculated on the basis of the base rate for the product. Otherwise, the calculation is based on the appropriate price in the policy or list defined.

If you activate the parameter Apply to Offers, you can indicate whether the price to be taken to make the calculation is to be the Offer Price, if one exists. Bear in mind that if this parameter is not activated, not defined or else active but no offer exists, the percentage will be applied to Base Price value.

Finally, there is the parameter Show Base Price. When activated, if the percentage to be applied is negative, you are indicating that the resulting price is to be considered an offer and that the value before calculating the price should be shown as the price before the offer. Activating this parameter therefore means generating offers automatically.

Diagrams

The final price of the product will be obtained as shown in this simplified diagram:

If the price of the options needs to be added, this other diagram - also simplified - will apply:

Offers

As we have seen, both for products and for options, and both for lists and for policies, you can specify two prices: Base Price and Offer Price. When a product is marked as on offer, the system makes additional checks on the prices, so that a product is not shown as being on offer when in fact it is not (if the offer price proves to be higher than the base price). This also involves certain limitations: it can only be determined whether a product is on offer on the basis of its own price, without taking options into account. Even so, once it is considered an offer, offer prices will only be applied when the sum of the offer price of the options plus the offer price of the product is less than the sum of the base prices. Therefore, providing the offer is active, the possibilities will be as follows:

• Base Price > Offer Price: considered an offer.

• Base Price <= Offer Price: NOT considered an offer.

• Base Price = 0 and Offer Price = 0: considered an offer because it is considered that the price is determined by the options.

• Base Price = 0 and Offer Price > 0: NOT considered an offer.

Therefore, there are two correct ways for proceeding:

• Configuring the price on the product (without extras) and applying increases on the options to make the product more expensive. All the options can have an increase, but the price set for the product will determine whether the offer price is applied.

• Configuring the price directly for the options and leaving product prices at 0. The system will determine at the time whether or not to apply the offer price; it will do so if the sum of the base prices for the options is greater than the sum of the offer prices for the options.

Combinations of the following type cannot be made: "base price on product + offer price on options" or "base price on options + offer price on product". The following combinations will not work, and the system will apply "base price for product + options":

• Indicating the same base and offer prices for the product, and a reduction or increase for the options.

• Indicating 0 for the product base price and a value for the offer price.

• Indicating a value only for the product base price and a value for the options offer price.

• Indicating a negative value for the product base price greater than the negative offer price and assigning increases in the options (negative values for product base prices are not accepted).

Unlike what happens with products, with options it is possible not to specify an offer price; if the product is on offer, the system will use the base price. In other words, if you leave Offer Price blank, the system will use the Base Price value. If on the other hand the offer price is 0, the system will increase the product price by 0 (this is considered a normal increase).

In options too, if you do not define either a base price or an offer price for a particular price list or policy, the system looks for the prices in the next policy or list that would apply.

For example, the system determines that a particular user is eligible for a certain pricing policy defined at user group level (Policy1 linked to the "VIP" group) and a pricing policy defined by country (Policy2 linked to France). Following the order criterion, the system finally chooses Policy1 because policies by user group take priority over policies by country. In Policy1, no prices have been set for options, but in Policy2 the prices have been filled in. As the system does not find prices for the options in Policy1, it looks in the next policy or list that would apply, in this case Policy2. As it finds prices defined there, it adds these values to those found in Policy1. If there were no other policy or list afterwards (the user is not from France so Policy2 does not apply to them), the system would add together the values in the Base Rate for the options.

See the examples in Examples of Option Combinations.

Calculated Price Lists

As explained above, you can have calculated price lists; these are price lists that instead of having product prices defined, they depend on the base rate or some other predefined price list. In this case, you must define a percentage increase or reduction on the base rate or price list it depends on, so that the final prices will be calculated by applying this percentage to the prices in the base rate or the list it depends on. As is the case with ordinary price lists, these must also follow the criterion for standard ordering.

You can create a chain of dependencies between lists, so that the first depends on a second which, in turn, depends on a third one and so on. If such a chain of price lists exists, the percentage is applied in a concatenated way, because to determine the price it is necessary to know the price it is based on and, in turn, involves applying its percentage of a hypothetical third list and so on.

If the list is based on another that does not exist (it has been deleted), the chain is broken because the system does not know what percentage to apply. In this case, it simply applies the base price with the accumulated increase or reduction.

Example:

The requirement for ListA is to belong to the "VIP" group. Product1 will cost users in this group:

Product1 = €13.68 = (€19 - 20%) - 10%

As ListC does not exist, the system looks for the base rate price and applies -20% to it to determine the price ListB would set. Once it has this, it applies -10% to get the ListA price. If ListC has a manual price, the -20% is calculated on the basis of this price (if it exists there is no need to look for the base rate).

This criterion is applied separately to the product price and the price of the options (each one is calculated separately).

The price lists to which the percentages are applied need not have the same filter type. For example, if ListB requires the user to be in France, ListA, which requires them to belong to the "VIP" user group, can be based on ListB because the latter only serves to supply prices for ListA, not to filter.

There are two types of calculation:

• Standard: the base price for the price list is calculated by applying the percentage to the value of the base price in the list it is based on, and the offer price is calculated by applying the percentage to the value of the offer price in the list it is based on, i.e. nothing is mixed together and each value is calculated by applying the percentage to its counterpart in the list it is based on.

• Base Price Policy: works in the same way as the percentages. A price is calculated by using one of the two price values (the base price or the offer price) in the price list, depending on the configuration. There are two parameters to control the way it works:

• • Apply to Offers: indicates whether offer prices are to be used to apply the percentage indicated. If this parameter is not activated or the product is not on offer, the base price will be used for the calculation.

  • Show Base Price: if the percentage to be applied is negative, there is the option of showing the value before the calculation was made as the price before the offer. For this the product must necessarily be on offer.

Here are some examples for each case:

• We start out with a product with these features:

• • Base price 100

• • Offer price 80

• And we have a price list calculated with a -20% reduction.

*In this case, the offer status indicated beforehand for the product is maintained.

Examples of Option Combinations

When calculating the final price, the price of options must be taken into account. Here are several examples of how the price of options works with zeros and unspecified values:

Prices by Quantity

With prices by quantity you can report the price of a product or an option by quantity ranges. Offering the product price depending on the quantity purchased allows you to adjust prices better so that the cost per unit is lower, which can help to boost volume purchased.

Prices by quantity can be defined both for products and for options, and both for price lists and for pricing policies. The price of the first tier less than or equal to the quantity purchased is always applied. For example, if you have defined the following prices by quantity, when 5, 6, 7, 8 or 9 units are purchased, the price for 5 units will apply:

As different prices can be set by quantity (i.e. different tiers) in price lists, pricing policies and the base rate, you must bear in mind that when a list or policy is applied, the prices by quantity assigned are always those in that list or policy. Tiers in a list are never mixed with those in a policy. You must therefore define the tiers in each of the lists and/or policies separately. Supposing that a product does not have its unit price defined in a policy or list; as the unit price to be applied would be that of a policy, if this has tiers defined then the tiers will be applied. For example:

In PolicyA there are 2 tiers:

• From 1 to 4 units: €9

• 5 or more units: €7

In PolicyB there are 4 tiers:

• From 1 to 2 units: €9

• From 3 to 4 units: €8

• From 5 to 9 units: €7

• 10 or more units: €6

On ListA there are 2 tiers:

• From 1 to 14 units: €9

• 15 units or more: €5

In ListB the price is always €8, whatever the quantity.

In ListC, where the price for this product has not been defined, the tiers in the policy corresponding to the user would be applied, falling back on the base rate if there is no other more specific one; i.e. if the price is not defined, the system ignores it and looks for another that meets the requirements.

Prices by Currency

You can specify the different monetary amounts in the Commerce in whatever currencies it has active. This includes the prices of products and their options, monetary amounts in the discount conditions and costs arising from payment system, as well as the shipping cost and the amounts in the price tiers that can be set for shipping to determine its cost.

In the case of products, for example, if you have 3 currencies active (euros, dollars and yen), you can indicate the price of a product and its options in each of these 3 currencies, i.e. you can specify how much it will cost in euros, in dollars and in yen. The system will always try to give the price in the currency in which the user is browsing.

In the case of products and options, you can define prices by currency in the price list, the pricing policy or the base rate. You can also do this in each of the tiers defined with prices by quantity. In short, the prices amount you enter in a policy, list or range of quantities can be in any of the active currencies.

An Commerce can have many currencies active, but you must specify one as the main currency. Only prices in the main currency must be entered; for other currencies it is optional. If the price of a particular product is not in the browsing currency, the system will convert from the main currency to the browsing currency.

In the case of both products and options, the system will first determine which policy, list, quantity range or base rate applies in the main currency (as described in Calculating the Price). Once this price has been retrieved, the system checks whether there is a price entered in the browsing currency that points exactly to price in the policy, list, quantity range or base rate found in the main currency. If the system finds a match, this price is shown; if not, the price in the main currency is converted to the browsing currency.

Bear in mind that the currency exchange rates used are updated every hour with the latest exchange rates. Therefore, the advantage of entering the price in other currencies is that you can set a specific price that will not change during the day.

Apart from the main currency, there are accounting currencies which are configured at the invoicing company. From all the accounting currencies you have configured, the system will determine which to use in each situation (depending on the channel or other parameters, such as the country). So, you could have a browsing currency, another as the main one and a third for invoicing.

The system follows these steps when making calculations for the shopping cart:

1. Retrieving all the prices in the browsing currency (they may have been entered or they may need to be converted).

2. Converting the amounts into the accounting currency.

3. Making the calculations in the accounting currency.