# 1 Promotions

pos_promotion
Label Description
Promotion ID This is the Unique identifier of the promotion. It is the serial of the table 'pos_promotion'.
Promo
Promo priority The priority of the promotion is the way the sequential algorithm scans the promotions. First, it takes into account the promotions with the lowest Priority. If two promotions apply the same discount, the final promotion aplied will be the one with the lowest priority.
Promo status The status of the promotion (automatic) indicates if the promotion lies between the 'date_from' and 'date_to' fields, and is enabled.

• Default: 1
• Values:
• 0: Disabled.
• 1: Active.
Store code Store code of the store where the promotion wishes to be applied, if it wants to be applied only to a specific store. If this field is not informed, then all the stores of the system will be able to apply the promotion.
Country code This code informs about the country where the promotion is active. If this field is null, then the promotion will be valid in all the countries of the system
Customer ID This ID belongs to the customer to whom the promotion will be applied. If this field is not informed, then the promotion is valid for all the customers.
From price This field indicates the minimum amount that the ticket must have for the promotion to be applied. From this amount, the promotion is always available (in terms of money, not date requirements).

Discount type This field informs about the type of discount that the promotion will apply. If this field is 1, then the discount will be a percentage with respect to the total amount of the scoped items. If this field is 0, then the discount will be a direct amount, no matter the amount of the ticket, as long as the from_price is lower than the scoped items total amount.

• Default: 0
• Values:
• 0: Amount. Amount
• 1: Percentage. Percent
Discount This field indicates the amount (in direct amount or percentage, depending on the discount type field) that will be applied to the tickets of the promotion.
Voucher type This field informs about what type of voucher will be generated when the promotion is applied. If this field is not reported, the promotion discount will be applied directly to the ticket. If this field is reported, a ticket of this type is generated, which contains the amount indicated in the 'discount' field.
Voucher date This date is the initial date when the voucher starts being valid. In order for this field to work, the field 'voucher_type' must be informed as well, as this field is the one who generates the voucher in the first place.
Return refund If this field is 1, the returns of products from the original ticket (the one which had the promotion), will be able to refund the vouchers generated, if the import returned is greater than the from_price field. If this field is 0, then the vouchers generated with the promotion will last until they are refunded (or expired), and the returns of products from the original ticket (where the promotion was generated) will not influence the voucher state.

• Default: 0
• Values:
• 0: No.
• 1: Yes.
From date This field informs about the date when the promotion starts to be available.
Date up to This date is the last available day of the promotion. From this date on, no ticket can have this promotion.
Monday This field indicates that the promotion is available on Mondays (if selected) or is NOT available on Mondays (if not selected).

• Default: 1
• Values:
• 0: No.
• 1: Yes.
Tuesday This field indicates that the promotion is available on Tuesdays (if selected) or is NOT available on Tuesdays (if not selected).

• Default: 1
• Values:
• 0: No.
• 1: Yes.
Wednesday This field indicates that the promotion is available on Wednesdays (if selected) or is NOT available on Wednesdays (if not selected).

• Default: 1
• Values:
• 0: No.
• 1: Yes.
Thursday This field indicates that the promotion is available on Thursdays (if selected) or is NOT available on Thursdays (if not selected).

• Default: 1
• Values:
• 0: No.
• 1: Yes.
Friday This field indicates that the promotion is available on Fridays (if selected) or is NOT available on Firdays (if not selected).

• Default: 1
• Values:
• 0: No.
• 1: Yes.
Saturday This field indicates that the promotion is available on Saturdays (if selected) or is NOT available on Saturdays (if not selected).

• Default: 1
• Values:
• 0: No.
• 1: Yes.
Sunday This field indicates that the promotion is available on Sundays (if selected) or is NOT available on Sundays (if not selected).

• Default: 1
• Values:
• 0: No.
• 1: Yes.
Note This comment field helps the user understand more specific information about the promotion
Created by Automatic field that informs about which user created the promotion.

• Default: USER
Date created This field is an automatic field that informs about the date of the creation of the promotion

• Default: CURRENT
User updated Automatic field that informs about which user updated the promotion for the last time

• Default: USER
Date updated This field informs automatically about when was the last time the promotion was modified.

• Default: CURRENT

# 2 Scope of promotions

The scope of a promotion is the set of combinations of products, customers, brands, etc. it is applied to. In total, there are 11 parameters that can be modified. These parameters are:

• General scope:
1. Store code
2. Country code
3. Customer ID
4. Day of the Week
• Product scope:
1. Category
2. Category children
3. Brand
4. Product ID
5. Combination ID
6. Assortment
7. Provider

## 2.1 Promotions without product scope

Promotions that do not have any Product scope assigned will be Header promotions. These promotions will normally affect all the items in the ticket and will appear in the printed ticket, and in the PDF.

### 2.1.1 Promotion without scope examples

1. An example of these promotions is a 10% discount for a sale greater than 100€. A sale of 120€ with this promotion would cost 108€, and the promotions will be visible in the ticket header.

This promotion would be parametrized as shown below:

Non-scoped promotions: sample 1

As shown, all the Days of the Week are marked, since we want the promotion to ve valid throughout the week. the field From price is set at 100€. The type of discount we want to apply is a Percentage (not a direct amount), and we want to apply a 10% discount. Therefore, the fields type of discount and reduction are set accordingly.

The other scope fields are left with null values to tell the algorithm that it does not have to take them into acccount.

2. Another example is a 5% of the sale as Voucher for a sale greater than 100€. Voucher active from 1/1/2021. This promotion will generate a voucher that will be available form the 1st of January, 2021.

Non-scoped promotions: sample 2

Notice now that the field Voucher Type is indicated, as well as the start date of the voucher. If one does not selects a Voucher Type, the promotion will apply the discount directly to the ticket.

### 2.1.2 Promotions without scope view in POS

In the Point of Sales screen, the promotions are applied to the ticket once we proceed to the payment. In this view, the Sales view, the promotion of the header (without scope) can be seen with its name in the lower left corenr of the window.

The image below shows an example of a ticket with a promotion TIQUET MORE THAN 100€, GET 20% DIRECT. This view shows as well the discount generated in the promotion (in case it is a percentage promotion).

Non-scoped promotions: POS view

## 2.2 Promotions with product scope

If one of the fields of the product scope is selected, the promotion will be applied only to the lines of the ticket, since a ticket can have many different products. Then, this promotion will only take into account the total value accumulated by the products that satisfy the conditions of the promotion.

E.g: If a promotion: 10% of the sale of products of Brand A as direct discount is applied to a ticket with 50€ of products of Brand A and 50€ of products of Brand B, the total discount will be 5€, accounting for a 10% of the total 50€ spent on Brand B

The product scope of a promotion can be very specific, ranging from category to product ID. The product scope is built with an auxiliar table, pos_promotion_items, which stores all the conditions of the promotion. The table contains all the Categories, Brands, Products ID, Assortments and Providers that want to be part of the promotion.

### 2.2.1 Category ID tree structure and scoped promotions

The category ID field of the scoped promotions is a bit more complex than the other fields. Given the fact that the categories can be built in a tree-structure (parent category is a category in the table, which has a category parent as well), there are two ways that a Category ID can be treated when scoping the promotion, and these two ways are given by the category_child column. This column can have three values:

1. 0 (null) : this value is selected when the Category ID of the scope line is not informed.
2. 1 (Equal category): when the category ID is informed, and the category_child is 1, the products to which the category will be applied must belong to the exact same category ID.
3. 2 (Recursive child selection): when the category ID is informed, and the category_child is 2, the products to which the cateogry will be applied must belong to either the same category ID or a descendant of this category ID.

Below you can find a visual representation of the influence of the column category_child in the selection of categories for the built SQL Clause (see next section).

### 2.2.2 Include/Exclude modes and the Built SQL Clause

The conditional clause of the product scope is built with these rows, and thus the scope can be really personalised. It is to notice the include/exclue mode of the lines of the product scope. This mode alters the way the selected paramter of the row (category, brand, etc.) is inserted in the condition.

• If the mode is include, the condition will include all the products that have this parameter into the promotion.
• On the other hand, if the mode is exclude, the condition will remove all the products that satisfy this parameter from the promotion.

The available promotions for each ticket are selected as follows:

    SELECT promo_id, ...
FROM pos_promotion, ...
WHERE ( (Include 1 OR Include 2 OR Include 3 OR ... OR Include N) AND (Exclude 1 AND Exclude 2 AND Exclude 3 AND ... AND Exclude M))


The Include or Exclude comaprative is a direct comparison:

 product_id = product_id, brand_code = brand_code, etc

For all the parameters but the Category ID. In this case, we have to take into account the mode category_child that will alter the way the SELECT is built. If this mode is 1, then the Include or Exclude mode is similar to the other parameters:

category_id = p_category_id, category_id != p_category_id

But if the mode is 2, then the SELECT will inject the category ID clause as:

 EXISTS (SELECT category_id FROM pos_product_categories WHERE product_id = p_product_id AND category_id = p_category_id)

or

 NOT EXISTS (SELECT category_id FROM pos_product_categories WHERE product_id = p_product_id AND category_id = p_category_id)

depending on the Include/Exclude mode of the promotion line.

### 2.2.3 Scoped promotions examples

#### Voucher of 10€ from sales greater than 50€ in products of Brand 'BRAND_TEST1' OR Category 'TEST' AND not of Provider 'Test provider' AND Assortment 'Test Assortmet'

This promotion, in the form of promotions would have the following view:

Scoped promotions: combination

And the rows of the scoped promotion would have the following view:

Scoped promotions: sample rows

The final SQL Clause built will look similar to this one:

    SELECT promo_id, ...
FROM pos_promotion, ...
WHERE ( (brand_code = 'BRAND_TEST1' OR category_id = 1173) AND (provider_code != 'TEST1' AND assort_id = 1 ) )


#### Direct discount of 10% of the sale in ballerinas

This promotion, in the form of promotions would have the following view:

Scoped promotions: 'Ballerinas'

The line of Category 'Ballerina' makes the promotion an scoped promotion, and this clause is added to the SQL statement as seen above. In this case as:

    SELECT promo_id, ...
FROM pos_promotion, ...
WHERE category_id = [category ID of 'ballerina']


Therefore only the products from this category will be suitable for the promotion.

#### 5% of sale of Assortment 1 as Voucher

This promotion, in the form of promotions would have the following view:

Scoped promotions: Assortment

Notice the 'VG' in the field type of voucher, indicating that this promotion will generate a voicher, instead of applying a direct discount to the ticket.

#### 10€ as Voucher for sales greater than 50€ of brand TEST1 and not Brand TEST2

This promotion, in the form of promotions would have the following view:

Scoped promotions: brands

Notice here the modes include and exclude of the brands TEST1 and TEST2, respectively. This will build the SQL clause:

    SELECT promo_id, ...
FROM pos_promotion, ...
WHERE ( brand_code = 'TEST1' ) AND ( brand_code != 'TEST2')


### 2.2.4 Scoped promotions view in POS

As with the general promotions, the scoped promotions can be seen as well from the Point of Sales. These promotions are applied to the ticket once we proceed to the payment. Since the promotions are scoped, these will not be applied to all the ticket (ticket header), but instead to the ticket lines.

As consequence, these promotions are visible in each line that has an scoped promotion, as a label icon. Let's take as example the first example of the previous section. The view of this promotion in POS is shown below.

Scoped promotions: POS view

Notice the little label icons that are found in the lines with products of category 'Ballerina'. This indicates that that products has a promotion. If the promotion is a direct discount, the reduced price will be shown in the screen, as in this case. If the promotion generates a Voucher, the label icon will appear next to the line, but the price won't be reduced.

If one desires to see which promotion is applied to each line, a helper will appear when hovering the mouse over the label icon. This helper can be seen in the figure below.

Scoped promotions: POS view detail

# 3 Redemption of vouchers generated with promotions

As it has been informed, some promotions can generate vouchers, which customers can redeem in the future. These vouchers are very similar to vouchers generated from returns of products. However, they contain a field 'promo_id', which informs about what promotion has generated the voucher. If the field is informed, this means the voucher was generated as a result of a promotion applied to a ticket. Therefore, if this 'promo_id' is informed, vouchers will be able to be redeemed and cancelled by returning products from the original ticket.

Sample case: There is a promotion: 10€ for sales of product A higher than 150€. A customer buys 150€ of these products, getting a voucher of 10€. If the customer, later, comes to return products of the original ticket, the value spent on products A will be inferior than 150€. Then, the promotion will not be valid anymore, and the voucher (if not redeemed previously) will be automatically cancelled.

This can only happen if the field voucher_redem is 1. If it is 0, then the customers will be able to return as many items as they wish, while conserving the voucher.