Developing a Promotion Management Module for 1C-Bitrix

The standard `sale` module includes a discount mechanism via `b_sale_discount` — rules based on basket conditions. It's a powerful tool but is tailored for automatic order-level discounts. Marketing promotions with banners, periods, participant counters, usage limits, 'buy 2 get 3' mechanics — all o

Our competencies:

Frequently Asked Questions

The standard sale module includes a discount mechanism via b_sale_discount — rules based on basket conditions. It's a powerful tool but is tailored for automatic order-level discounts. Marketing promotions with banners, periods, participant counters, usage limits, 'buy 2 get 3' mechanics — all of this either cannot be implemented with standard tools or requires cumbersome workarounds. Clients often come with a request: 'create a promotion buy 2 for the price of 1', but in Bitrix this is not a product discount but a full-fledged bundle. Standard capabilities lack flexibility for conditions at the basket level — for example, a discount only for registered users or when reaching a sum with a specific SKU. All of this requires a separate module. Over 5+ years of Bitrix module development, we have accumulated dozens of cases where standard discounts were insufficient. Our promotion management module enhances bitrix discounts, bitrix coupons, bitrix bundle, bitrix gifts, and bitrix cashback with custom conditions. It fills this gap — we offer a ready-made ORM model, a flexible promotion builder, and integration with any sales channels. Use the ready module and forget about the headache of custom events. Get a consultation — we'll help you select the optimal configuration.

Why Standard Discounts Are Not Enough

b_sale_discount is linear rules: discount on sum, on product, on group. Anything beyond that — promotions with coupons, bundles, gifts based on custom conditions — requires either workaround events or an external module. Our approach: a separate b_vendor_promo_action table with JSON conditions and rewards. This gives flexibility without overhead. Development time savings — up to 60% compared to custom solutions, costing 40% less on average.

Architecture and Features

Data Model

The vendor.promo module with the following tables:

  • b_vendor_promo_action — promotions: id, code, name, type (discount/gift/bundle/coupon/cashback), date_from, date_to, is_active, priority, usage_limit, usage_count, conditions (JSON), reward (JSON), banner_image_id, description
  • b_vendor_promo_coupon — coupons: id, action_id, code, discount_type (percent/fixed), discount_value, usage_limit, usage_count, user_id (null = shared), expires_at, is_active
  • b_vendor_promo_usage — usage history: id, action_id, coupon_id, order_id, user_id, discount_amount, applied_at
  • b_vendor_promo_gift — gift products of the promotion: id, action_id, product_id, quantity

Promotion Types

  • Discount by condition: "conditions": {"min_sum": 3000, "iblock_section_id": 12} — 10% discount on orders from 3000 rubles in the 'Electronics' section.
  • Bundle: "type": "bundle" — when product A is added to the cart, product B is automatically added with a discount. Implemented via the OnSaleBasketItemAdd event.
  • Coupon: generation of unique codes in b_vendor_promo_coupon, verification during checkout.
  • Gift: when basket conditions are met — product from b_vendor_promo_gift is automatically added with price 0.
  • Cashback: accrual of loyalty program points instead of a discount.

How Condition Checking Works

class PromoChecker { public function check(PromoAction $action, \Bitrix\Sale\Order $order): CheckResult { $conditions = $action->getConditions(); $basket = $order->getBasket(); if (isset($conditions['min_sum']) && $basket->getPrice() < $conditions['min_sum']) { return CheckResult::fail('Minimum order amount not reached'); } if ($action->getUsageLimit() && $action->getUsageCount() >= $action->getUsageLimit()) { return CheckResult::fail('Promotion usage limit exhausted'); } return CheckResult::success(); } } 

Promotion Priority and Compatibility

Multiple promotions can be active simultaneously. The priority parameter determines the order of application. The exclusive field in the promotion settings means other promotions are not combined with it.

Logic: active promotions are sorted by descending priority. For each, CheckResult is evaluated. If a promotion is exclusive and passes the check, it is applied and the loop breaks.

Administrative Tools

Coupon Generator

Bulk generation of unique codes for email campaigns:

$generator = new CouponGenerator($action); $coupons = $generator->generate(1000, [ 'length' => 8, 'prefix' => 'SALE-', 'charset' => 'ABCDEFGHJKLMNPQRSTUVWXYZ23456789', ]); // batch insert into b_vendor_promo_coupon + CSV file for export 

Characters similar to digits (O/0, I/1) are excluded from the charset to avoid errors during manual entry. Up to 10,000 codes can be generated in a single batch.

Promotion Statistics

The administrative interface shows for each promotion:

  • Number of applications and percentage of limit
  • Total discount over the period
  • Conversion: how many users added a coupon to an incomplete order vs completed payment
  • Top products covered by the promotion
  • Daily usage dynamics (graph)

Administrative Interface

  • List of promotions with filter by status, type, date
  • Builder for conditions and rewards
  • Coupon management: bulk generation, deactivation, export to CSV
  • Report per promotion with breakdown by orders

Project Scope

What Is Included in Module Development

Component Description
ORM tables Ready D7 entities for promotions, coupons, usage
Condition builder Interface for setting basket rules (sum, section, product, user)
Reward types Percentage/fixed discount, gift, bundle, coupon, cashback
Coupon generator Bulk generation with digest check and CSV export
Promotion compatibility Priorities, exclusivity, tagging
Statistics Reports per promotion: application count, discount, conversion
Administrative interface Filters, reports, coupon management
Testing Load testing simulating 1000+ simultaneous checks
Documentation Module instructions, API reference, deployment guide
Access Admin panel, source code repository
Training 2-hour online session for administrators
Support 1 month warranty, extended support available

Development Timeline

Stage Time
ORM tables, model 1 day
Condition checking, discounts 2 days
Gifts and bundles 2 days
Coupon generator 1 day
Priorities and compatibility 1 day
Reports and statistics 1 day
Administrative interface 2 days
Integration testing 1 day

Total: 11 business days turnkey. Integration with an email platform — additional 1–2 days.

How to Implement a 'Buy 2 Get 3' Promotion (Quick Steps)

  1. Create a new promotion of type 'bundle'.
  2. Set condition: basket must contain at least 2 items of product X.
  3. Set reward: add 1 item of product X with 100% discount.
  4. Set usage limit and priority.
  5. Save and activate.

This takes 5 minutes, compared to days of custom event coding.

Comparison of Standard Approach vs Our Module

Criteria Standard Discounts Our Module
Promotion 'buy 2 get 3' Requires events and workarounds Configured in 5 minutes
Coupons for email campaigns No built-in generator Bulk generation of 1000+ codes
Promotion priorities Not supported Built-in priorities and exclusive
Reports on promotions Only basic Conversion, dynamics, top products
Development speed ~20 days custom 11 days turnkey, 60% faster
Cost Higher due to custom work Up to 40% less

Our module reduces development time by 60% compared to custom events, and costs 40% less on average for typical projects.

Contact us — we will evaluate your project and offer the optimal solution. Drawing on 5+ years of experience with Bitrix, we guarantee the module's functionality and integrability into your existing architecture. Order the development of a promotion management module and get a flexible tool for marketing campaigns.

Reference to official documentation: ORM D7. 1C-Bitrix: D7 ORM