In this article, I overview the common promotion mechanics and their default implementation in SAP hybris. You may be surprised to learn that some things don’t work as expected. I explain the edge cases and typical flaws with the default implementation as well as offer words of advice on how to build it properly.
This list is not full; I didn’t consider the trivial promotion types and their combinations.
Quantity and price discounts
Buy 1 Get 1 Free (BOGOF)
There are two way of implementing this mechanics, depending on the way you understands the idea of BOGOF, as offline retailer or online retailer. In the offline world, it is too late to add a free product to your shopping cart automatically at the checkout. In the online world it may be an expected behavior.
- Option #1. The product should be added automatically
- Option #2. The product should be placed to the cart manually by the customer
Option #1. The product should be added automatically
To implement it in hybris, there is an action “Free gift”. So the promotion configuration will be: If there is a qualified product (ProductA), add a free gift (ProductB).
Example. Buy one apple
add one orange free.
| Cart contains |
Expectations |
How hybris works OOTB |
| 1 apple ($) |
1 apple ($) +
1 orange free |
[as expected] |
| 2 apples ($) |
2 apples ($) +
2 oranges free |
 2 apples ($) +
1 orange free |
| 2 apples +
1 orange ($) |
2 apples ($)+
2 oranges free |
2 apples ($) +
1 orange ($) +
1 orange free |
| 2 apples +
2 oranges ($) |
2 apples ($)+
2 oranges free |
2 apples ($) +
2 oranges ($) +
1 orange free |
| 2 apples +
3 oranges ($) |
2 apples ($)+
1 orange ($) +
2 oranges free |
2 apples ($) +
3 oranges ($) +
1 orange free |
As you can see from the table, the hybris OOTB BOGOF promotion has the following flaws:
- if you buy N products, you will have one free product anyway. If you create two orders in a row instead of one combined, you will get two free products, one per order.
- if your free product is available for purchase, and the customer added this product to the cart manually, the price of this product will not be zeroed.
Option #2. The product placed to cart manually by customer
This template is already implemented in hybris. The configuration is the following: there are two containers, A and B, both have qualified products conditions, for Product A and Product B (supposed to be free), and there is an action that makes the Product B free if Product A is in the cart.
Example. Buy one apple
get one orange free.
| Cart contains |
Expectations |
How hybris works OOTB |
| 1 apple ($) |
1 apple ($) +
1 orange free |
1 apple ($). Orange is not added automatically |
| 2 apples ($) |
2 apples ($) +
2 oranges free |
2 apples ($). Oranges are not added automatically |
| 2 apples +
1 orange ($) |
2 apples ($)+
2 oranges free |
2 apples ($) +
1 orange free. The second orange is not added automatically |
| 2 apples +
2 oranges ($) |
2 apples ($)+
2 oranges free |
[as expected] |
| 2 apples +
3 oranges ($) |
2 apples ($)+
1 orange ($) +
2 oranges free |
[as expected] |
Thanks to
Cristian Caprar for useful additions to this section:
This way, for any amount of P1 in the cart, the same amount of P2 is free (but the user needs to add P2 to the cart, it is not added automatically by the system).
To make the rule working as following: “put P1 in the cart, P2 gets added automatically in the same quantity as a free gift”, besides custom code there can be a workaround in case the amount is limited (let’s say up to 5 items):
- Create the promotion rule as 5 different promotions, one for each quantity of P1 (5xP1 -> 5xP2, etc), give priorities from the 5 down to the 1 quantity and then make them not stackable.
This can quickly become too much configuration if quantities are not limited, of course, but avoids custom code.
You may expect that a parameter called “a number of rule executions” in hybris promotion rule configuration means how many promotions can be applied to the shopping cart. It is not so. It is just about the rule executions that means nothing, because one rule execution can seize all product in the cart if they meet the conditions. In order to limit the number of free products or applied discounts you need to make a custom action and condition in hybris.
Rule executions unfortunately does not help at all, as the system does not know to also consume from the qualifying product P1 each time rule is executed. For example, if the rule as you make it says P1 = 1 (not >=) for P2 = 1 free gift, and in the cart there are 2 P1, it would be nice that the system executes it once, consuming one qualifying item P1, then fires again (say rule executions is any number > 1) and sees it can consume one more qualifying P1, then stops as there are no more qualifying P1 left to consume.
Buy 1 from category X get 1 from category X free
Promotion template: Product perfect partner percentage discount
Example. Buy any fruit get one milk product free
(not specific product; any product from the Milk Products category, as the customer
wants). Apple is a fruit. Yogurt is a milk product.
| Cart contains |
Expectations |
How hybris works OOTB |
| 1 apple ($) |
1 apple ($) +
a message
“you can buy any milk
product for free“ |
Only if the potential promotion is configured for this case |
| 1 apple ($) + 1 yogurt ($) |
1 apple ($) + 1 yogurt free |
[as expected] |
| 2 apple ($) + 1 yogurt ($) |
2 apple ($) +
1 yogurt free |
[as expected] |
| 2 apple ($) + 2 yogurt ($) |
2 apple ($) +
2 yogurt free |
[as expected] |
Example.
- Buy any fruit get one milk product free. Apple is a fruit. Yogurt is a milk product.
- Buy any vegetable get one milk product free. Cucumber is a vegetable.
| Cart contains |
Expectations |
How hybris works OOTB |
| 1 cucumber ($) |
1 cucumber ($) +
a message
“you can buy any milk
product for free“ |
[as expected] |
| 1 apple ($) +
1 cucumber ($) |
1 apple ($) +
1 cucumber ($) +
a message:
“you can buy two milk
products for free“ |
[not exactly, but near enough] |
| 1 apple ($) +
1 cucumber ($) +
1 yogurt ($) |
1 apple ($) +
1 cucumber ($) +
1 yogurt free +
a message
“you can buy one milk
product for free“ |
[as expected] |
| 1 apple ($) +
1 cucumber ($) +
2 yogurts ($) |
1 apple ($) +
1 cucumber ($) +
2 yogurt free |
1 apple ($) +
1 cucumber ($) +
1 yogurt free +
1 yogurt ($) |
| 1 apple ($) +
1 cucumber ($) +
3 yogurts ($) |
1 apple ($) +
1 cucumber ($) +
1 yogurt ($) +
2 yogurts free |
1 apple ($) +
1 cucumber ($) +
1 yogurt free +
2 yogurt ($) |
|
|
|
As you can see from the table, the existing products are not replaced with the gifts with the same SKUs. It is not a bug, but this peculiarity shouldn’t come as a surprise.
Buy 2 from category X get 1 from category Y free
Promotion template: Product perfect partner percentage discount
Example. Buy two fruits get one milk products free.
| Cart contains |
Expectations |
How hybris works OOTB |
| 2 apples ($) |
2 apples ($) +
a message
“you can buy one milk
product for free“ |
[not exactly, but near enough] |
| 3 apples ($) |
3 apples ($) +
a message:
“you can buy one milk
product for free“ |
[not exactly, but near enough] |
| 4 apples ($) |
4 apples ($) +
a message
“you can buy two milk
products for free“ |
[not exactly, but near enough] |
| 4 apples ($) +
1 yogurt ($) |
4 apples ($) +
1 yogurt free +
a message
“you can buy one milk
product for free” |
[as expected] |
| 4 apples ($) +
2 yogurts ($) |
4 apples ($) +
2 yogurts free |
[as expected] |
| 2 apples ($) +
2 peaches ($) +
2 yogurts ($) |
2 apples ($) +
2 peaches ($) +
2 yogurts free |
[as expected] |
| 2 apples ($) +
2 peaches ($) +
1 yogurt ($) +
2 bottles of milk ($) |
2 apples ($) +
2 peaches ($) +
1 yogurt free +
2 bottle of milk free +
1 bottle of milk ($) |
|
Buy 2 of X and 1 of Y and get 1 free Z
Promotion template: Product perfect partner percentage discount
Example. Buy 2 apples and 1 cucumber and get 1 yogurt free
| Cart contains |
Expectations |
How hybris works OOTB |
| 1 apple ($) |
1 apple ($) +
a message
“buy 1 apple and 1
cucumber and get 1 free
milk product“ |
[not exactly, but near enough] |
| 2 apples ($) |
2 apples ($) +
a message
“buy 1 cucumber and get 1
free milk product“ |
[not exactly, but near enough] |
| 2 apples ($) +
1 cucumber ($) |
2 apples ($) +
1 cucumber ($) +
1 yogurt free |
[as expected] |
| 2 apples ($) +
1 cucumber ($) +
1 yogurt ($) |
2 apples ($) +
1 cucumber ($) +
1 yogurt free |
2 apple ($) +
1 cucumber ($) +
1 yogurt free +
1 yogurt ($) |
| 2 apples ($) +
1 cucumber ($) +
2 yogurt ($) |
2 apples ($) +
1 cucumber ($) +
1 yogurt ($) +
1 yogurt free |
2 apple ($) +
1 cucumber ($) +
1 yogurt free +
2 yogurt ($) |
| 4 apples ($) +
2 cucumbers ($) |
4 apples ($) +
2 cucumbers ($) +
2 yogurt free |
4 apple ($) +
2 cucumber ($) +
1 yogurt free |
| 4 apples ($) +
2 cucumbers ($) +
2 yogurts ($) |
4 apples ($) +
2 cucumbers ($) +
1 yogurt free +
1 yogurt ($) |
4 apple ($) +
2 cucumber ($) +
2 yogurt ($)
1 yogurt free |
In hybris this type of promotion is implemented as:
- AND-Group of
- Container 1: SKU = apple, amount = 2
- Container 2: SKU = cucumber, amount = 1
- Action: Free gift, amount = 1
However, as my experience shows, this configuration doesn’t work well in hybris, it is buggy and unpredictable.
Buy 3 Items from Category X for Y$
Example. Buy 3 different/same shirts for $100
| Cart contains |
Expectations |
How hybris works OOTB |
| 1 shirt ($) |
1 shirt ($) +
a message
“add 2 shirts to buy
all three for $100“ |
[not exactly, but near enough] |
| 1 Shirt A ($) +
1 Shirt B ($) |
2 shirts ($) +
a message
“add 1 shirt to buy
all three for $100“ |
No OOTB support |
| 2 Shirts A ($) |
2 shirts ($) +
a message
“add 1 shirt to buy
all three for $100“ |
No OOTB support |
| 1 Shirt A ($) +
2 Shirt B ($) |
If the total price < $100,
each shirt gets a calculated
discount to make $100 in
total |
No OOTB support |
| 3 shirts A ($) |
If the total price < $100,
the price of the cart item “3
shirts A” is now $100 |
No OOTB support |
| 4 shirts A ($) |
If the total price of 3 shirts
A < $100, the price of the
cart item “4 shirts” is now
$100 + retail price of one
shirt A.
+message “add 2 shirts to
buy all three for $100″ |
No OOTB support |
| 2 shirts A ($) +
2 shirts B ($)Price of Shirt A is $35
Price of Shirt B is $45 |
There are two options on
how to combine shirts in
the group of 3 shirts:
1. Group(A+A+B) and B
2. Group(A+B+B) and A
First, the groups below
$100 is not in a play.
Among the remaining
groups, the cheapest option
wins.
1. $35+$35+$45=$115 <-this
2. $35+$45+$45=$125
for the first option, the total
price if $145 ($100+$45)Shopping cart after the
promotions are applied:
2 shirts of A – $70
2 shirts of B – $75 (-16%) |
No OOTB support |
The main challenge with this promotion type is grouping items and implement a strategy which group is the best for the seller/customer. The simplest approach is to pick the first group, but it may create customer dissatisfaction. The cheapest group is a more comprehensive strategy, but it is also the most complex one in terms of implementation.
“3 same-SKU shirts => fixed price”
SAP hybris doesn’t support it OOTB. The expected behavior for the rule “any three t-shirts costs $30:
| Cart contains |
Expectations |
How hybris works OOTB |
| 3 shirts ($15×3=$45) |
3 shirts ($30) |
$30 |
| 4 shirts ($15×4=$60) |
3 shirts ($30) +
1 shirt ($15) +
a message
(“add 2 more shirts…) |
No OOTB support |
| 5 shirts ($15×5=$75) |
3 shirts ($30) +
2 shirt ($15×2=$30) +
a message
(“add 2 more shirts…) |
No OOTB support |
| 6 shirts ($15×6=$90) |
6 shirts ($30×2=$60) |
No OOTB support |
| 7 shirts ($15×7=$105) |
6 shirts ($60) +
1 shirt ($15) |
No OOTB support |
“3 different shirts => fixed price”
SAP hybris doesn’t support it OOTB.
There is an OOTB promotion “Bundle product fixed price” that looks like one for this promotion type. However, it is not working as expected.
The formula of OOTB Bundle product fixed price is
- Condition
- Container A
- Condition for the first product in the bundle
- Container B
- Condition for the first product in the bundle
- Container C
- Condition for the first product in the bundle
- Action
- Target bundle price (A+B+C)
It works if conditions are on categories, but it is not working if conditions are about the same category. In our example, “Shirts” is a category that needs to be used in all three conditions (Qualified categories = “Shirts”). Hybris can’t work with such configuration: your rule will work incorrectly with this setup.
Buy 2 get 3rd free (Buy 3 for the price of 2)
Example. Buy 3 apples for the price of 2.
| Cart contains |
Expectations |
How hybris works OOTB |
| 1 apple ($) |
1 apple ($) +
a message
“buy it free if you add 2
more apples“ |
Only if the potential promotion is configured for this case |
| 2 apples ($) |
2 apples ($) +
1 apple free |
[as expected] |
| 3 apples ($) |
2 apples ($) +
1 apple free |
3 apples ($) +
1 apple free |
| 4 apples ($) |
3 apples ($) +
1 apple free |
4 apples ($) +
1 apple free |
| 5 apples ($) |
4 apples ($) +
2 apples free |
5 apples ($) +
1 apple free |
| 6 apples ($) |
4 apples ($) +
2 apples free |
6 apples ($) +
1 apple free |
The way how hybris works is straightforward and clear, but a bit unfair from the customer perspective. If you receive one apple free for any two purchased apples, in hybris e-shop, as a customer, you can split the order of 6 apples into 3 separate orders and receive 3 free apples instead one free apple for the whole order as hybris works OOTB. The table above shows this case, but implementing the right way is a challenging thing.
Buy any from Category X and any from Category Y and get the cheapest free
Example. Buy 1 fruit and 1 vegetable and get the cheapest free
| Cart contains |
Expectations |
How hybris works OOTB |
| 1 apple ($5) +
1 cucumber ($2) |
1 apple ($5) +
1 cucumber free |
hybris OOTB can’t find the cheapest from the pair. |
| 1 apple ($5) +
1 cucumber ($7) +
1 cucumber ($3) |
1 apple ($5) +
1 cucumber ($7) +
1 cucumber free |
— ” — |
| 1 apple ($2) +
1 cucumber ($7) +
1 cucumber ($3) |
1 apple free +
1 cucumber ($7) +
1 cucumber ($3) |
— ” — |
| 1 apple ($2) +
1 apple ($5) +
1 cucumber ($7) +
1 cucumber ($3) |
There are two combinations:
* (A$2 + C$7) & (A$5+C$3)
* (A$5 + C$7) & (A$2+C$3)
for the first, $7+$5=$12
for the second,$5+$5=$10
depending on the strategy,
first or second wins |
— ” — |
The last example shows that there is more than one way to group products in the cart. The simplest approach is to group products without analyzing what grouping is better for the seller or customer. Just pick the first one. However, your customers may think differently. Good new is that it is a rare situation. The alternative approach, with comparing groups and finding the most efficient for the seller or customer, may be too expensive and complex, so my recommendation is to go with the simplest approach, analyze the sales and customer complaints about the point.
There is a selection strategy in the promotion configuration having two options, DEFAULT and CHEAPEST. Don’t be confused: CHEAPEST doesn’t mean X or Y needs to be selected for a 100% discount. It works if more than one product found in Y. If your cart has more than one product from Category Y, the cheapest one will be selected.
Buy 1 Get the 2nd Half Off (Buy 2 get 1 half price)
Example. Buy 1 apple ($10) get 50% off for 2nd apple ($5).
| Cart contains |
Expectations |
How hybris works OOTB |
| 1 apple ($10) |
1 apple ($10) +
a message
“get 1 more apple and you will get 50% off” |
hybris OOTB can’t
apply a discount for a second product of the same SKU |
| 2 apples ($10+$10) |
2 apples ($15) |
–“– |
| 3 apples ($10+$10+$10) |
3 apples ($25) |
–“– |
| 4 apples ($40) |
4 apples ($30) |
–“– |
Buy X and get Y with the Z% discount
Example: Buy an apple and get a cucumber with 10% discount.
| Cart contains |
Expectations |
How hybris works OOTB |
| 1 apple ($10) |
1 apple ($10) +
a message
“buy a cucumber with 10% discount” |
[not exactly, but near enough] |
| 1 apple ($) +
1 cucumber ($10) |
1 apple ($) +
1 cucumber ($9) |
[as expected] |
| 1 apple ($) +
2 cucumbers ($10×2=$20) |
1 apple ($) +
1 cucumber ($9) +
1 cucumber ($10) |
[as expected] |
| 2 apples ($) +
2 cucumbers ($10×2=$20) |
2 apples ($) +
2 cucumbers ($9×2=$18) |
[as expected] |
Add X to cart and get Y for the fixed price of $Z
Example: Buy an apple and get a cucumber for $5.
| Cart contains |
Expectations |
How hybris works OOTB |
| 1 apple ($10) |
1 apple ($10) +
a message
“buy a cucumber for $5” |
~ |
| 1 apple ($) +
1 cucumber ($10) |
1 apple ($) +
1 cucumber ($5) |
[as expected] |
| 1 apple ($) +
2 cucumbers ($10×2=$20) |
1 apple ($) +
1 cucumber ($5) +
1 cucumber ($10) |
[as expected] |
| 2 apples ($) +
2 cucumbers ($10×2=$20) |
2 apples ($) +
2 cucumbers ($5×2=$10) |
[as expected] |
Buy X product from Category X and get any product from Category Y for $Z
Example: Buy any fruit and get any vegetable for $5.
| Cart contains |
Expectations |
How hybris works OOTB |
| 1 apple ($10) |
1 apple ($10) +
a message
“buy any vegetable for $5” |
[not exactly, but near enough] |
| 1 apple ($) +
1 cucumber ($10) |
1 apple ($) +
1 cucumber ($5) |
[as expected] |
| 1 apple ($) +
2 cucumbers ($10×2=$20) |
1 apple ($) +
1 cucumber ($5) +
1 cucumber ($10) |
[as expected] |
| 2 apples ($) +
2 cucumbers ($10×2=$20) |
2 apples ($) +
2 cucumbers ($5×2=$10) |
[as expected] |
| 1 apple ($) +
1 peach ($) +
2 cucumbers ($10×2=$20) |
1 apple ($) +
1 peach ($) +
2 cucumbers ($5×2=$10) |
[as expected] |
| 1 apple ($) +
1 cucumber ($12) +
2 carrot ($10) +
1 cabbage ($12) |
In this example, the cheapest product should be taken to the promotion group (a carrot)
1 apple ($) +
1 cucumber ($12) +
1 carrot ($5) +
1 carrot ($10) +
1 cabbage ($12) |
[as expected] |
Buy different Xs, get Y% off for a 2nd and Z% for a 3rd
Example (
from Svayznoy.ru, where I used to work). If you buy two different accessories from the list, you will get
10% off for a second. If you buy three items, the second will cost
10% off and the third will cost
25% off.
hybris OOTB can’t be configured for this type of promotion.
| Cart contains |
Expectations |
How hybris works OOTB |
| 1 iphone case ($20) |
1 iphone case ($20) |
|
| 2 iphone cases ($20) |
1 iphone case ($20) +
1 iphone case ($20) |
|
| 1 iphone case A($20) +
1 iphone case B ($40) |
1 iphone case A ($20) +
1 iphone case B ($36) |
hybris OOTB can’t
distinguish different/same products in the promotion |
| 1 iphone case A($20) +
1 iphone case B ($40) +
1 iphone case C ($28) |
1 iphone case A ($20) +
1 iphone case B ($18) +
1 iphone case C ($21) |
— ” — |
| 2 iphone cases A ($20) +
1 iphone case B ($40) +
1 iphone case C ($28) +
1 iphone case D ($14) |
2 iphone case A ($20) +
1 iphone case B ($18) +
1 iphone case C ($21) +
1 iphone case D ($14) |
— ” — |
This promotion type is not 100% compatible with drools to be implemented as a single rule. The reasons are:
- the number of groups is not fixed (two or three)
- the first group must contain the most expensive product if the cart contains more than one product from the list of qualified products
- the second group must contain the most expensive product among the remaining products
- the third group must contain the most expensive product among the remaining products
- for the remaining products, the grouping starts from the first group again
One of the possible solutions is to use a custom rule group, with three stackable promotions in it.
| Promotion |
Conditions |
Actions |
| #1 (Stackable) |
- Qualified products (a list)
|
Blacklist the most expensive |
| #2 (Stackable) |
- Qualified products (a list) except for blacklisted
- Promotion #1 was fired
|
Blacklist the most expensive (product X)
Create a discount (configurable) for the product X (10%) in the cart |
| #3 (Stackable) |
- Qualified products (a list) except for blacklisted
- Promotion #2 was fired
|
Identify the most expensive (Product Y)
Create a discount (configurable) for product Y (25%) in the cart |
All [category/product(s)] for $X
Example. All fruits for $10
| Cart contains |
Expectations |
How hybris works OOTB |
| 1 apple ($15) |
1 apple ($10) |
[as expected] |
| 1 apple ($15) +
1 cucumber ($12) |
1 apple ($10) +
1 cucumber ($12) |
[as expected] |
| 1 apple ($15) +
1 cucumber ($12) +
1 peach ($16) |
1 apple ($10) +
1 cucumber ($12) +
1 peach ($10) |
[as expected] |
| 1 apple ($5) |
1 apple ($5) |
[as expected] |
| 1 apple ($5) +
1 peach ($12) |
1 apple ($5) +
1 peach ($10) |
[as expected] |
| 10 apples ($11×10=110) |
10 apples ($10×10=$100) |
[as expected] |
Example. Some products (apples, cucumbers) for $10
| Cart contains |
Expectations |
How hybris works OOTB |
| 1 apple ($15) |
1 apple ($10) |
[as expected] |
| 1 apple ($15) +
1 cucumber ($12) |
1 apple ($10) +
1 cucumber ($10) |
[as expected] |
| 1 apple ($15) +
1 cucumber ($12) +
1 peach ($16) |
1 apple ($10) +
1 cucumber ($10) +
1 peach ($16) |
[as expected] |
| 1 apple ($5) |
1 apple ($5) |
[as expected] |
| 1 apple ($5) +
1 peach ($12) |
1 apple ($5) +
1 peach ($12) |
[as expected] |
| 10 cucumbers ($11×10=110) |
10 cucumbers ($10×10=$100) |
[as expected] |
Percent discount
Example. All apples 30% off.
| Cart contains |
Expectations |
How hybris works OOTB |
| 1 shirt ($100) |
1 shirt ($70) |
[as expected] |
| 2 shirts ($200) |
2 shirts ($140) |
[as expected] |
Bundle products
Example. If you buy both apples and cucumbers, 10% off for a bundle
| Cart contains |
Expectations |
How hybris works OOTB |
| 1 apple ($20) |
1 apple ($20) |
hybris OOTB can’t
apply a discount to a total bundle price |
| 1 apple ($20) +
1 cucumber ($10) |
1 apple ($18) +
1 cucumber ($9) |
— ” — |
| 1 apple ($20) +
2 cucumbers ($10) |
1 apple ($18) +
1 cucumber ($9) +
1 cucumber ($10) |
— ” — |
| 2 apples ($20×2=$40) +
2 cucumbers ($10×2=$20) |
2 apples ($36) +
2 cucumbers ($18) |
— ” — |
| 3 apples ($20×3=$60) +
2 cucumbers ($10×2=$20) |
2 apples ($36) +
1 apple ($20) +
2 cucumbers ($18) |
— ” — |
| 2 cucumbers ($10×2=$20) |
2 cucumbers ($20) |
— ” — |
Fixed amount discount
Example. Apples 10% off
| Cart contains |
Expectations |
How hybris works OOTB |
| 1 apple ($20) |
1 apple ($18) |
[as expected] |
| 1 apple ($20) +
1 cucumber ($10) |
1 apple ($18) +
1 cucumber ($10) |
[as expected] |
Order history
X% discount for customers who place more than Y orders before
Hybris doesn’t support it OOTB. If you need to implement this promotion type, consider the following points:
- Identify the system which is a source of truth for the orders. Commonly, the e-shop sends the orders to the external system and these orders can be changed/canceled there without notifying the e-shop. Certainly, if the e-shop is currently using the order history for other purposes, this situation is likely unreal.
- Order history can be huge and slow. Any real-time requests can slow down your system. Think about caching the order totals to make the calculations faster. Ideally, the number and total cost of the delivered orders should be calculated each time the order status is changed to “DELIVERED”.
- List all statuses and edge cases that may create inconsistencies. For example, the system will take only delivered orders into account to use with this promotion type.
Get $X% off if bought more than $Y worth of products before
Hybris doesn’t support it OOTB. If you need to implement this promotion type, consider the following points (in addition to the mentioned above):
- Period of time. Open periods are not good for this promotion type, they don’t motivate to buy more, and after years they come back with problems for the business.
- Currencies. Some purchases can be done in different currencies from the same account
- Refunds and returns.
- Purchases paid by points/non-monetary payment methods.
Customer groups
X% discount for customers whose email contains text [‘company.com’]
Hybris doesn’t support it OOTB. If you need to implement this promotion type, consider the following points:
- If e-mails can give the customer the discounts, the registration process will be more comprehensive for the customer. The customer needs to confirm the e-mail address before this address will be recognized as qualified for the promotion type.
- Needless to say that “@company.com” must be a trailing part of the e-mail and must contain a “@” character. If your system checks just for a substring, the emails like “blablabla+company.com@gmail.com” can be wrongly identified.
Delivery Promotions
Free shipping on all products
Hybris does support it. However, you can face to the problems if the free shipping is also a condition for other promotions. hybris OOTB doesn’t have such condition, so in the default setup it is not an issue. For example,
- delivery cost is $13
- 10% discount for all apples if the delivery is not free (because in fact it is not really free for the seller; it pays for it anyway and they prefer not to give any discounts when the delivery is free for the customer);
- if the total worth of products in the cart is more than $100, the delivery should be free.
With these rules, you can face to the interesting issue:
- apples costs $11/lb
- you decide to buy 10 lb, so the total cost is $110
- the delivery is not free by default, so you have a 10% discount, your final price is $99 ($110-11) + $13 for the delivery = $112
- $99<$110, so the delivery will not be free even if your original total price is more than $100
So the order of promotions counts in this case. If the discount promo is the first, you will have a lower price ($99), but you also need to pay for the delivery ($13). If the discount promo is the last, you will have a free delivery ($0), but you will pay a full price for the apples ($110).
You also need to take into account that hybris promo actions doesn’t change the order by default. They extend it by adding the discounts. It means that if you need to implement the condition “if the delivery is not free”, there are two things that bring this information:
- CartRAO. Is it created by the promotion module BEFORE the promotion engine starts working.
- DeliveryRAO. It is created by promotion actions DURING the promotion engine is working.
For the statement “if the total worth of products in the cart is more than $100, the delivery should be free”
, the promotion engine creates DeliveryRAO, but CartRAO remains untouched. After the promotion calculation process, all DeliveryRAO are applied to the Cart.
Buy x, get free shipping on order
Hybris does support this promotion type. It is a combination of Qualified products and Free Delivery.
Coupons
In hybris, you can apply/redeem a coupon that brings no benefits. Unfortunately, OOTB hybris doesn’t check if the coupon is used or not. The customer can waste their coupons if there are any promotions capable working with this coupon.
Order discount with the coupons
There is an OOTB condition that checks if the coupon is applied to the order. In hybris, coupon itself doesn’t have the information about its value. The value is supposed to be set in the promotion action.
Gift coupons
Gift coupons are issued when the order is placed. This approach has some drawbacks.
The order can be canceled or reconsidered just after the purchase. In this case, the coupon needs to be called off. If the coupon is used by the customer, you can’t call it off, but you also can’t cancel the order just because you have issues with the customer’s gift coupon.
The right way is to issue the coupon after the order is delivered. The coupon should be generated in one of the last steps in the order process. Even in this case, you need to think about what to do if the purchase is returned.
© Rauf Aliev, April 2017
Anoop Kumar
8 May 2017 at 09:56
Hello Sir,
We are facing an issue in production which is related to promotionresult type data in production.
It is increasing rapidly , Due to this increase in data of this type it has reached to 69 GB for one type only. Could you please explain how this table become responsible for huge data means in how many ways data is being inserted in this type?
Which are the the actions which are responsible for entries in this table? So that we can try to find loophole if it is there by performing same actions.
Thanks
Anoop
Rauf Aliev
8 May 2017 at 12:43
Interesting.. I will look closer on how it works , thanks
Anoop Kumar
31 May 2017 at 10:41
Hello Sir , Did you get something on this if you got sometime to do analysis on promotion result table?
Rauf Aliev
31 May 2017 at 14:48
Unfortunately, I can’t find enough time for that.. let’s conndct on Skype, it’s easier to discuss the details
Anoop Kumar
8 May 2017 at 09:58
Just wanted to inform more that ,Our application is based on telco accelarator, where bundles and subscription plans come in action.
Cristian Caprar
24 May 2017 at 01:28
Hello Rauf, can you tell whether you implement promotions using the new rule engine or the legacy Jalo based one? I assume you talk about the new engine with rules. Thanks, Cristi
Rauf Aliev
24 May 2017 at 07:14
Hi, Cristi. Certainly, that’s about the rule-based promotion engine.
Cristian Caprar
12 June 2017 at 09:24
Hi Rauf, which version of hybris are you using to get this behavior? On 6.3.0.5, I tried some of the rules.
For example, Buy 1 Get 1 Free (BOGOF) (your first tests) seem to be working as expected all the time (1 apple $ -> 1 orange free, 5 apple $ -> 5 orange free, 1 apple $ and 2 oranges in the cart -> 1 apple $, 1 orange free, 1 orange $).
Rauf Aliev
12 June 2017 at 11:49
Christi, I use hybris 6.3 and I just also tried. Please check:
https://hybrismart.files.wordpress.com/2017/04/2017-06-12_11h45_01.png?w=1862
As you see, 4 apples lead to 1 apple as a gift
The rule is:
* Condition: Qualified products: p_apple, >=1
* Action: Free product, p_apple, 1
Cristian Caprar
13 June 2017 at 03:00
I see what you did, a little different than what is the standard behavior of the BOGOF template, I understand now the difference of the approaches.
What I use is the same template, but the rules are:
* Condition: Container 1 – Qualified product: P1 >=1, ANY
* Condition: Container 2 – Qualified product: P2 >=1, ANY
* Action: Discount 100% on perfect partner product P2 of product P1
* Rule executions: 1
This way, for any amount of P1 in the cart, the same amount of P2 is free (but the user needs to add P2 to the cart, it is not added automatically by the system).
To make the rule working as you intend (put P1 in the cart, P2 gets added automatically in the same quantity as a free gift), besides custom code there can be a workaround in case the amount is limited (let’s say up to 5 items):
* Create the promotion rule as 5 different promotions, one for each quantity of P1 (5xP1 -> 5xP2, etc), give priorities from the 5 down to the 1 quantity and then make them not stackable.
This can quickly become too much configuration if quantities are not limited, of course, but avoids custom code.
Rule executions unfortunately does not help at all, as the system does not know to also consume from the qualifying product P1 each time rule is executed. For example, if the rule as you make it says P1 = 1 (not >=) for P2 = 1 free gift, and in the cart there are 2 P1, it would be nice that the system executes it once, consuming one qualifying item P1, then fires again (say rule executions is any number > 1) and sees it can consume one more qualifying P1, then stops as there are no more qualifying P1 left to consume.
It would be very useful if you could detail more the conditions and actions for your tests, to eliminate confusion and make it clear what you tried to do.
In any case, useful info as usual on this blog. Maybe you start something on customizing the promo engine to make it work as expected on some examples.
Best,
Cristi C.
(skype: ccaprar)
Rauf Aliev
13 June 2017 at 08:24
Thanks for this information! I made changes in the article. I’m a bit of a hurry, I hope everything is ok. Feel free to contact me directly if you see that something needs to be clarified/changed etc. Rauf_Aliev@epam.com, skype Rauf_aliev
Dino
29 May 2017 at 10:58
Hello, I am facing issue with multi-firing of promotions from the same group.
As you mention “number of executions” is just upper bound – RuleGroupExecutionRRD.allowedToExecute is always true until it hits that number.
I have BXGY promotion and I would like to consume qualifying products so they cannot participate in a condition of another firing of same promotion rule.
I don’t know how to consume them, or is it the best way to go even ?
Rauf Aliev
29 May 2017 at 13:54
I am not sure I understood you correctly… Let’s connect on Skype? (Rauf_aliev)
Stoyan
27 June 2017 at 14:46
Hi Raulf, I am struggling to find a solution for having only one promotion to be consumed by a product this to be determined by the priority of the promotion (as it was before 6.X version).
For example:
I have a product X and Promotion Rule 1 (priority 1001) giving 10% on Product X.
Product X belongs to Category X.
I have Promotion Rule 2 (priority 1000) giving 5% on Category X.
In that case I would like to have on Promotion Rule 1 executed on Product X and no other rules to be executed on Product X, i.e. Line Item is consumed by only one promotion.
Your help will be greatly appreciated.
Rauf Aliev
27 June 2017 at 16:03
The quick solution is
1) two rule groups, four promotions p1 (10%) and p2 (5%).
p11 in g1: 10% product is =product X=
!p12 in g1: product is =not product X=
p21 in g2: 5% product is in =category X= and p11 has been fired
p22 in g2: 5% product is not in =category X= and p12 has been fired
need testing, but at the first glance it should work.
Kelly
14 July 2017 at 04:44
Hello Rauf,
I would like to ask whether the following mechanism is supported by Hybris OOTB or not?
(If buying more than 3 items from markdown category will get 20% off on every sale items)
I have created a promotion rule with 2 containers and action of “Percentage discount on partner products”.
So it is working fine when I purchase 3/6/9… items, but it is not working for other number of items. I have tried to add one more target product container (let says for 4), but it will apply 20% off twice and one 20% off on the 4th item…
So I would like to clarify with you is this situation actually supported by Hybris?
Anyway, thank you so much for your explanation, it already helped me a lot!
Best Regards,
Kelly
Sravan
14 July 2017 at 12:11
Rauf,
We have bunch of catalogs with the same product code. Hybris OOTB, Promotions are not catalogaware i.e. when we added the product to the Promotion Condition we loose the catalog by just retaining the code. So promotion being applied to all Catalogs for the selected product. so wondering if you have thoughts on Making catalog aware?
Thanks,
Sravan.
Rauf Aliev
14 July 2017 at 13:00
Hybris 6.4 has catalog aware promotions
Manoj
13 December 2017 at 05:19
Hi Rauf,
I would like to know if We can set maximum discount for a product in OOTB implementation. I want to have 10 % discount on all product s of a category but maximum discount allowed is say $X.
Mickey
26 September 2018 at 01:46
Hi Rauf ,
Does the updatePromotion method of promotion service is only for Cart type .Or it is also for Order Type.In its argument it take AbstractOrderModel,this should hv made it apt for both type but still is not woriking for order Type while it works fine for Cart type