Have you encountered uncontrolled stacking of discounts?
Typical scenario: three promotions sum up, giving 70% discount instead of expected 15%. Or a promo code triggers together with a general promotion, and the customer gets the product almost for free. In one project, incorrect LAST_DISCOUNT configuration led to significant losses. The root cause is incorrect priority and LAST_DISCOUNT flag setup. We configure rules so that each promotion applies strictly according to its conditions, and stacking control eliminates losses.
Our experience: 7+ years working with Bitrix, over 50 marketing configuration projects. According to the 1C-Bitrix documentation, LAST_DISCOUNT is a key mechanism to prevent multiple discount application. Additionally, we use custom OnSaleDiscountRuleAction events for non-standard mechanics. Proper configuration can save substantial revenue.
Why may promotions in Bitrix stack incorrectly?
The problem arises when several discount rules have the same priority and the 'Stop further processing' flag is not set. For example, a '10% off first order' promotion and a '5% off entire catalog' promotion apply together, giving 14.5% instead of 10%. The solution: set priority 100 for the main promotion and enable LAST_DISCOUNT. If stacking is desired, use joint application in settings. In complex cases, we add a check in the OnSaleDiscountCondition event to programmatically control applicability.
Example implementation of custom promotion with condition
// event OnSaleDiscountCondition class MyCondition extends \Bitrix\Sale\Discount\Condition\Base { public static function getClassName() { return __CLASS__; } public static function getControlId() { return 'MyCondition'; } public static function checkCondition(array $params, array $arOrder) { // Check if basket contains product from desired category $basket = $arOrder['BASKET_ITEMS']; foreach ($basket as $item) { if ($item['IBLOCK_SECTION_ID'] == 42) { return true; } } return false; } } How to distinguish a catalog discount from a marketing rule?
| Type | Module | Scope | Capabilities |
|---|---|---|---|
| Catalog discount | catalog | Product price before basket | Percent/fixed, periods, groups |
| Marketing rule | sale | Basket | Gifts, shipping discount, many conditions |
Catalog discounts (table b_catalog_discount) work at the product price level before the basket. Marketing rules (section 'Basket rules') operate in the basket, allowing gifts, shipping discounts, conditional chains. According to Wikipedia, catalog discounts are classic price discounts, while marketing rules are a more complex mechanism. Using marketing rules gives 30% more flexibility than catalog discounts because you can combine conditions and impose restrictions.
Creating a promotion via the builder
Store → Marketing → Discounts and promotions → Add:
-
Conditions — AND/OR builder:
- Order total greater than X
- Basket contains product from section N
- User in group G
- Promo code used
Actions:
- Discount on order (percent, fixed)
- Discount on basket items
- Shipping discount
- Add gift (product with zero price)
Application settings:
- Priority
- 'Stop further processing' — important for mutually exclusive promotions
- Joint application with other discounts
Custom
OnSaleDiscountRuleActionevents allow implementing mechanics 2-3 times faster than creating a custom module. For example, we added a discount on the second product in the basket — it took 2 hours instead of a week of development.Promo codes: common, unique, and user-specific
In promotion settings, enable coupon (
Store → Marketing → Coupons). Coupon types:Type Description Common for all One code, multiple uses Unique One code, one use Unique for user Tied to a specific user Coupons are stored in
b_sale_discount_coupon. When activated, the coupon is checked via\Bitrix\Sale\DiscountCouponsManager::add. If a promo code doesn't apply, check coupon activity, expiration date, and type — the issue is often in basket data caching.What to do if promotions don't trigger?
First, check the error log in
Store → Marketing → Discounts and promotions → Application report. If a promotion is not applied, ensure it is active and conditions match the basket. Also check the condition grouping: maybe an 'AND' condition instead of 'OR' is blocking execution. Enable debug mode inbitrix/php_interface/dbconn.phpto view SQL queries:$DB->showSqlStat = true;. This helps find caching problems or incorrect relations.What's included?
Stage Duration Audit of current promotions 1-2 hours Logic design 1-3 hours Implementation via builder or code 3-5 hours Testing on a test order 1-2 hours Documentation and training 1 hour - Audit of current promotions and rules
- Design of discount application logic
- Implementation via builder or custom code
- Testing on a test order
- Documentation and staff training
- Support for one month after launch
Contact us for an audit of your marketing rules. Order a consultation to avoid losses from incorrect discounts. Setup of 3-5 standard promotions with promo codes — 3-5 hours. Complex mechanics with gifts and custom actions — 1-2 working days. Cost is calculated individually after analyzing the specification. Additionally, you get a guarantee on correct promotion operation for 30 days.
Get a detailed audit and optimization plan — just write to us.