Retail:Discounts and Promotions Rules

Contents 1 Introduction 2 New discounts engine 3 Promotion Types 3.1 Fixed Percentage Discount 3.1.1 How to Define 3.1.2 How it Works 3.2 Buy X pay Y of same product 3.2.1 How to Define 3.2.2 How it Works 3.3 Buy X pay Y of different product 3.3.1 How to Define 3.3.2 How it Works 3.4 Buy X and get Y as gift 3.4.1 How to Define 3.4.2 How it Works 3.5 Packs 3.5.1 How to Define 3.5.2 How it Works 3.5.3 Using packs from Web POS 3.6 Discretionary Discounts 3.6.1 Discretionary discounts types 3.6.2 How to Define 3.6.3 Security 3.6.3.1 Role Based Security 3.6.3.2 Approvable Discounts 3.6.4 Using Discretionary discounts from web POS 3.6.4.1 Delete Discretionary discounts 3.6.4.2 Delete Discretionary discounts with multiple instances 3.6.4.3 Multiple instances per line 4 Discounts & Promotion per Hour 5 Discounts which include or exclude certain characteristic values 6 Discounts incompatibilities 7 Limitations

Introduction

Discounts and Promotions is a free commercial module that comes with the Openbravo for Retail distribution starting from RMP17 (Retail Maintenance Pack).

It provides four new Promotion Type implementations. This document explains how to define promotions based on new rules. Before using this document, it is recommended to first make oneself familiar with promotions in general which is explained in the Discounts and Promotions document.

New discounts engine

The discounts engine has been reimplemented using newer technologies and patterns. The new implementation has been designed as an independent component, built on plain Javascript functions, which can be reused and deployed in different ways. The WebPOS will use this new engine, but it will also be used as part of a Webservice that can be consumed by external systems, to provide a list of discount candidates which should be applied to a given ticket.

Even though the implementation is completely new and built from scratch, from a functional point of view it should work essentially the same as the previous one. Old definitions of discount rules and configuration are still valid, and each discount should work like before.

Still, there has been a few changes and improvements in the new implementation:

• The "Priority" field indicates the order the promotions will be sorted and be applied in the discount engine (priority 1 promotion will be executed before priority 2 promotion). If priority field is null, the priority for that promotion is assumed to be 0.
• The "Apply next discount" flag has been generalised, and now can be used with any kind of discount. If it is flagged, if the discount is then applied, it will not "consume" any units, and it will be possible to apply other discounts to those units in cascade.
• Together with this change, the consumed units and cascading price has also been generalised. If a discount is applied, the price of the affected line is reduced. If a second discount is then applied in cascade on top of this one, the price for which the new discount will be calculated will be the discounted price. This was true for some rules in the old engine, but not all of them, and now it has been homogenised, and is general for all rules.
• Now no rule can generate a discount greater than the price of the product. If a discount would be greater than the corresponding price, it is then automatically modified to reduce the line price to zero. If a line is already zero, the discount will not be applied.
• Some rounding errors have been fixed in some rules.
• Bytotal discounts have been improved. Before, they were always applied at the end, and always consumed all units. Now they follow the priority order as all other discounts, and they only consume units if "Apply next discount" is not checked. This means that it is possible now to create a configuration in which by total discounts are applied, and then other discounts are applied on top of them. This was previously not possible
• Some rules allow the discount to be "distributed" over several lines. For these rules, previously the discount sometimes was shown on just one unit, even if internally it was distributed over the lines. This was wrong, because it could be misleading as taxes for different lines might be different. Therefore, the new engine shows the real discounted amount on each line if the rule is configured to distribute the discounts. It is of course still possible to uncheck the "distributed" option if you want the discount to be applied only on one line, but now the engine will always show the real calculated discount at each line.

Like in the previous version of the engine, all the specific filters are checked to confirm whether the discount can be applied to a particular order or not. In order for the discount to be applied, the order must fulfill the criteria for all the filters. So, as an example, if a discount excludes some business partners, includes some specific products, and some specific characteristic values, it will be applied only if the order is not linked to any of those business partners, includes at least some of the products, and those products also have the specified characteristics.

Promotion Types

In the following sections each promotion type included in this module is explained in detail.

Additional modules can implement new rules, such as:

• Combo
• By Total
• Scaled price

Retail discounts and promotions can be used together with the Coupons functionality, to implement discounts that apply to a given customer, and with a limited number of uses.

Fixed Percentage Discount

How to Define

The only field to fill is Discount %, which defines the percentage to be discounted.

How it Works

It discounts a fixed percentage of the base price.

Buy X pay Y of same product

How to Define

• X Units: This is the number of units of the product that the user has added to the ticket.
• Y Units: Number of units of the product that needs to be paid for each x units.

This rule applies to specific Products or to all products inside specific Product Categories. These can be defined in the Filter Options.

How it Works

When there are at least X units of a product that is eligible, the promotion is applied. For each X units, Y are paid. So for each X units, X-Y units are discounted.

Examples:

• Definition:
  • X Units: 6
  • Y Units: 5
  • Is applied to products: A (price 5€) and B (price 10€)

• Ticket 1:
  • Lines:
    • 1. A x 7 -> 35€
    • 2. B x 5 -> 50€
    • Total (without promotion): 85€
  • Promotion:
    • Promotion is applied to line 1 because there are six units of A which is >= than six. This reduces the price with one price unit of A, which is 5€.
    • Line 2. The quantity doesn't reach the six required units so no promotion is applied.
    • Final amount to be paid: (35€ - 5€) + 50€ = 80€

• Ticket 2:
  • Lines:
    • 1. A x 19 -> 95€
    • 2. B x 6 -> 60€
    • Total (without promotion): 155€
  • Promotion:
    • Promotion would be applied to line 1 because there are 19 units of A which is >= than six. It would subtract the price equivalent to three units of A, this is 15€, because there are three groups of six units.
    • Line 2. It also applies the promotion, discounting the equivalent to one unit of B, 10€.
    • Final amount to be paid: (95€ - 15€) + (60€ - 10€) = 130€

Buy X pay Y of different product

This rule is similar to the previous one, but the numbers for X and Y are calculated by summing all quantities of any of the products the rule can be applied to.

How to Define

• Apply Next Discount: Because this promotion type requires multiple lines to be computed, it does not allow to apply other promotions afterwards, so this flag needs to be set to false.
• X Units: This is the number of product units that makes the promotion applicable.
• Y Units: Number of product units to be paid for each x units.
• Discount Subtype: Defines how the amount to discount is calculated. It can be:
  • Apply to Lowest Price. For each bundle of X units, the ones with the lowest price are selected to be discounted.
    • Distribute Between Lines. In case of Apply to Lowest Price, this field is shown. If unflagged, the complete discount will be within the line of the cheapest product. If flagged, the amount to be discounted will be the same, but it will be distributed between all the lines with products participating in this promotion. Distribution will be done for each line based on its amount. Note this distribution is internal and the final user will not see it in the ticket. The ticket will display the complete discount in the cheapest lines, in the same way as when the field is not checked.
  • Apply Average Price. When this subtype is used, the applied discount is not based on the price of the cheapest product but on the average price of all product participating in the promotion.

How it Works

This promotion can be applied whenever there sum of the units of all products that fit the filter for the promotion is at least X.

Grouping of products is done in the most favourable way for the customer. The most expensive products are grouped first and in case some of the candidate products cannot be included in the promotion (because total quantity is not a multiple of X), these are the cheapest ones, see example for ticket 1 below for a detailed explanation on this topic.

The following 2 examples depict how products are selected to be included in the promotion. If subtype is Apply Average Price, groupings would be done in the same way.

Examples:

• Definition:
  • X Units: 3
  • Y Units: 2
  • Discount Subtype: Apply to Lowest Price
  • Distribute Between Lines: false
  • Can be applied to products: A (price 5€) and B (price 10€)

• Ticket 1:
  • Lines:
    • 1. A x 1 -> 5€
    • 2. B x 3 -> 30€
    • Total (without promotion): 35€
  • Promotion:
    • There are in total 4 units of different products that can participate in the promotion. As X is 3, it is possible to apply this promotion just once, but not twice (it would require 6 products to be included).
    • There would be 2 different way of grouping products to include in the promotion:
      • A x 1, B x 2 (B x 1 is out the promotion). In this case the equivalent of A x 1 would be discounted because it is the cheapest product in the promotion, this is 5€.
      • B x 3 (A x 1 is out the promotion). So B x 1 would be discounted, this is 10€ off. This is the preferred option.
    • Final amount to be paid: 5€ + (30€ - 5€) = 30€

• Ticket 2:
  • Lines:
    • 1. A x 8 -> 40€
    • 2. B x 2 -> 20€
    • Total (without promotion): 60€
  • Promotion:
    • There are in total 10 units of products that can participate in the promotions. As X is 3, it is possible to apply the promotion 3 times (3*3=9), so 3 units can be discounted.
    • The way to do the grouping is:
      • group 1: B x 2, A x 1. Promotion would discount A x 1 (5€) because it is the cheapest product in the group.
      • group 2: A x 3. Promotion discounts A x 1 (5€).
      • group 3: A x 3. Promotion discounts A x 1 (5€).
      • ungrouped: A x 1. No promotion can be applied.
    • Total discount is 15€. Final amount to be paid: (40€ - 15€) + 20€ = 45€

Buy X and get Y as gift

This rule defines what the number of units (X) of a product needs to be bought, in order to be able to discount Y units of another product.

How to Define

• Filters. This type requires to define filters in a slightly different manner than other ones.
  • Included Products field must be of Only those defined type.
  • In Products tab, two extra fields are shown: Quantity and Gift Product. In order to apply the promotion is required to have in the ticket at least the quantity of all products.
    • Quantity is the required number of units of this product in order to be able to apply the promotion
    • Gift Product indicates whether the product is discounted. If it is a gift product, quantity represents the number of units of this product that will be discounted from the ticket.
• Apply Next Discount: Because this promotion type requires multiple line to be computed, it does not allow to apply other promotions after it, so this flag is forced to be false.
• Distribute Between Lines: As in the previous rule, this flag is internally used to decide how the discount is applied among lines. In any case it is transparent in the ticket, which will display the complete discount in the gift products.

How it Works

This promotion is only applied when in the ticket there are at least the number of units described as Quantity for all the products in the list of the rule, in this case, lines of products marked as Gift Product will be discounted in a number of units equal to Quantity of this product in the rule definition.

Examples:

• Definition: Buying 1 unit of C and 2 units of B, you get 1 unit of A for free.
  • Product A (5€):
    • Quantity: 1
    • Gift Product: true
  • Product B (10€):
    • Quantity: 2
    • Gift Product: false
  • Product C (15€):
    • Quantity: 1
    • Gift Product: false

• Ticket 1:
  • Lines:
    • 1. A x 1 -> 5€
    • 2. C x 3 -> 45€
    • Total (without promotion): 50€
  • Promotion:
    • Even there are 3 units of C which is one of the required products to get the promotion, there are no lines with B which is a requisite to get the promotion. So in this case the promotion cannot be applied and the final amount to pay remains: 50€.

• Ticket 2:
  • Lines:
    • 1. A x 1 -> 5€
    • 2. C x 3 -> 45€
    • 3. B x 2 -> 20€
    • Total (without promotion): 70€
  • Promotion:
    • In this case the promotion can be applied once as there is enough quantity of all products. The discount to apply would be A x 1 (5€) which is the only Gift Product in this promotion.
    • Final amount to pay: (5€-5€) + 45€ + 20€ = 65€

Packs

A pack is a list of products with a fixed price when they are all included in the ticket. A pack also works as a product in Web POS, allowing you to sell a pack, when a pack is added as it was a product, new lines for each of the products in the packs are inserted in the ticket.

How to Define

• Filters. This type requires to define filters in a slightly different manner than other ones.
  • Included Products field must be of Only those defined type.
  • In Products tab, an extra field is shown: Quantity In order to detect the pack and apply the promotion is required to have in the ticket at least the quantity of all products defined for the pack.
    • Quantity is the number of units of this product to be included in the pack
• Apply Next Discount: Because this promotion type requires multiple line to be computed, it does not allow to apply other promotions after it, so this flag is forced to be false.
• Discount/promotion price. Indicates the total price of the pack.
• Currency. Currency the price is expressed in. When applying this kind of discounts, only the ones matching the same currency as the in use price list can be selected, note currency conversion is not done.
• UPC/EAN. Because packs work as a product, an UPC/EAN code can be assigned in order to scan it from web POS.
• Image. Because packs work as a product, an image can be assigned. This image will represent this pack in Web POS.

The packs are grouped in a product category called Pack. An image for this category can be defined by selecting the type pack in Discounts and promotion types window (System Administrator role is required to access) and then uploading an image for it.

How it Works

This promotion is only applied when the ticket includes all the products of a defined pack.

Examples:

• Definition: Pack Boots + Helmet: Buying 1 unit of boots and 1 unit of helmet, you get a special price of 250€
  • Product Boots (230.5€)
    • Quantity: 1
  • Product Helmet (90.5€)
    • Quantity: 1

• Ticket 1
  • Lines
    • 1. Boots x 2 -> 461€
    • 2. Helmet x 1 -> 90.5€
    • Total without promotion (551.5€)
  • promotion
    • Because there are 2 units of boots and 1 unit of helmet the pack Boots + Helmet is detected, so the pack price is applied (250€). The pending unit of boots will be sold with the standard price of the product (230.5€). So in this case the final amount to pay is: 480.5€

Using packs from Web POS

When a promotion of type pack is defined a new product category called "pack" appears in the browse tab of Web POS. This product category contains all the defined packs.

To sell a pack, just browse the category and click into the selected pack. This action will include the products in the ticket and the promotion will be applied.

Discretionary Discounts

Unlike the rest of promotions and discounts, this kind of discounts is not automatically applied to the ticket in base of some rules. It is the cashier who needs to manually apply them.

Discretionary discounts types

• User defined amount
• User defined percentage
• Discretionary fixed amount
• Discretionary fixed percentage

User defined ones allow the user that inserts the discount to edit the amount or percentage to be discounted from the line. Fixed ones predefine this discount, user is allowed to select one of the available discounts, but she cannot edit it.

How to Define

• Filters. Filters doesn't matters for this type of discounts
• Definition
  • Percentage/Amount discount. In case of fixed discount types, this field is required and it is the percentage or amount that will be discounted. In editable types, this field is optional, when it is set, this amount or percentage is the discount that will be proposed by default.

• • Allow multiple instances per line. This check allows to apply multiple instances of this promotions in the same line

• • Apply after automatic discounts. If this option is checked, the discretionary promotion will be applied after the automatic promotions are calculated, instead of being applied at the beginning of the discounts application process

Security

This utility can be secured through preferences.

There are 2 preferences which must be set as Y in order to enable discretionary discounts.

• Web POS action Advanced Discounts
• Web POS action Apply discount

Note: The menu item to access to discretionary discounts will be disabled until the ticket have lines.

Role Based Security

It is possible to define for a Discretionary Discount which roles can apply it. Note a user/role in order to apply a Discretionary Discount needs to be granted also with the preference explained in the section above.

Security based on role is assigned in the same way other filters are: using the Role subtab together with the Included Roles field in Discounts and Promotions window.

Approvable Discounts

Discretionary discounts marked as Approval Required, require of a supervisor to approve the ticket before it is paid. Note the approval is requested prior to close the ticket but not when the discounts are added.

The preference to define supervisors for this action is Web POS Discretionary Discount Approval. For more information on how to configure supervisors read this document.

Using Discretionary discounts from web POS

1. Create at least one discretionary discount. In this case we will create two discount. (fixed percentage and user defined percentage)

2. Add products to the ticket, and through the menu select Receipt discounts (Before Ticket discounts)

3. Select the discount that you want to apply.

• 3.1 Fixed discounts: The keyboard will be disabled because this discount is fixed and the amount cannot be changed.

• 3.2 User defined discounts: This discount, initialy will apply the default amount. This amount can be changed using the keyboard. Just write the amount and press intro key to apply -> The amount to apply will be updated

4. Select the lines which will be affected by the discount. (All the lines can be selected checking Apply to all lines)

5. Indicate if this discount will override existing promotions. If this field is checked, no more promotions will be applied to affected lines. When unchecked, discretionary discounts are applied before any other discount.

6. Apply the discount.

7. The new discount is applied to the ticket

Delete Discretionary discounts

If you have one or more lines selected you can go to EDIT tab and click Delete Discount button. Once clicked a popup will be raised asking for the discounts to remove. If you click Cancel button nothing will be removed.

Delete Discretionary discounts with multiple instances

If you have several instances of the same promotion to delete in the same line, the "Discounts to delete" popup shows each promotion instance separately to allow the user to delete only one instance if necessary.

Multiple instances per line

If you configure a discretionary promotion as "Allow multiple instances per line" the user is able to apply the same discretionary promotion more than once per line.

Discounts & Promotion per Hour

It is possible to define the Start time and the End time within the day in the definition of Discounts and promotions. This configuration will only be applicable for Openbravo Web POS, not in the Openbravo backoffice.

In the new section Availability, you can set the time in the current day when the promotion is active.

You can select a time interval for the whole week or for each day of the week.

For whole week mark the checkbox All Week and week day are hidden and you can introduce Starting Time and Ending Time.

You can select different hours for each day of the week if you uncheck the All week checkbox and mark the day of the week and enter Start time and End time for each day.

When the promotion is applied in WebPOS, there is a margin of a few minutes before and after the start and end time respectively. To configure this margin use the preference: Extra time for hourly discounts (in minutes)

New Availability tab has been added to replace Availability section.

With this new tab, it is possible to define more than one Start time and End time for the whole week or for each day of the week.

Discounts which include or exclude certain characteristic values

It is also possible to define discounts that should be applied only when certain characteristic values are present in a product, and that should not be applied if certain characteristic values are present. Both are defined independently, so it is possible to define discounts that should be applied if some values are set, if some values are not present, or if several values are present and others not present.

This is defined in two subtabs of the Discounts and Promotions window, named "Included characteristics" and "Excluded characteristics".

Both for included and excluded characteristic values, you have two different options:

• All of the values defined: For included characteristics, this means that all values need to be present for the product to be able to receive the discount. For excluded characteristics, this means that only if all of the values are present for the product, the discount will not be applied.
• Any of the ones defined: For included characteristics, this means that if any of the values is present for the product, the discount can be applied. For excluded characteristics, this means that if one of the values is present in the product, then the discount will not be applied.

Discounts incompatibilities

From this release, it is possible to define discount rules, or discount types, incompatible with one particular discount rule:

If defined, then if any of these discount rules or discount types are applied to a line, then this discount will not be applied to the line, even if the rest of the conditions to apply it are fulfilled.

Limitations

1. Promotions that require multiple lines to be checked in order to know if they can be applied or not (Buy X pay Y of different product and Buy X and get Y as gift), cannot be used in a chain of promotions in case multiple ones are applicable to the same line. However, simple promotions can be applied before. Therefore, in their definition, Apply Next Discount field must be unflagged.

2. When a line participates in a promotion, even though not all the units in that line are part of the promotion, the whole line is considered to be in the promotion, so these units that are not participating cannot participate in another promotion.

3. Even for a single promotion rule, the best possible combination for the customer is done, this rule is not applied among different promotions. This means that in case two different promotions can be applied to the same line, the one with a higher priority will be applied first, even when the other one might be more favourable to customer.

4. Manual (discretionary) discounts are always applied first, and only once thy are applied, automatic discounts are considered.

Example:

• Promotion definitions:
  • P1:
    • Type: Buy X pay Y of different products
    • Priority: 1
    • X: 6
    • Y: 5
    • Can be applied to products: A (price 5€) and B (price 10€)
  • P2:
    • Type: Fixed Percentage Discount
    • Priority: 2
    • Discount %: 50
    • Can be applied to products: A and B
• Ticket
  • Lines
    • 1. B x 10 -> 100€
    • 2. A x 1 -> 5€
    • Total (without promotion): 105€
• Promotions:
  • First promotion to be applied is P1. There are 11 units of products that can participate in this promotion, so it is possible to apply it just once (12 units would be required to apply it twice). Using the best possible grouping for the customer, it would be B x 6 in the promotion so B x 1 (10€) can be discounted.
  • Second promotion is P2. As line #1 has a promotion that prevents cascading the already applied ones, it is skipped even there are B x 4 that were not included in the group required for the promotion. In line #2 a 50% of discount is applied (2.5€).
  • Final amount to pay: (100€ - 10) + (5€ - 2.5€) = 87.5€
  • Note also in this example, limitation #3 happens. It would have been better for customer not to apply P1 at all, but instead applying just P2, which would have resulted in a 50% discount for the entire ticket paying 52.5€ instead of 87.5€.

5.Field Product Category is not working with hierarchical Product Category. If you want to include/exclude categories for a promotion you need to include all categories in the list. If we add a category, it will affect to products of this category, it will not affect products of categories hierarchically below/above the added category

Category: Retail