1C-Bitrix Price Rules Module Development
Imagine: a manager wants to set a promotion "15% off all brand X items for customers from Moscow whose order sum over the last 30 days exceeds 10,000 rubles, but only if the cart contains no items from category Y." The built-in Bitrix discount module (sale) handles straightforward cases, but combined conditions involving order history or regional logic either require hacky code in the cart template or a separate module. We specialize in building such modules turnkey—this avoids bulky core modifications and preserves compatibility with system updates.
Why the built-in discount module falls short
Built-in discounts in sale operate through the b_discount table and predefined condition types: user group, order total, product set. The OnGetDiscountConditionTypes event allows adding custom conditions, but its capabilities are limited—you cannot flexibly combine conditions or add order history dependencies through standard means. Moreover, performance suffers: with 5–10 rules, a query to b_discount_condition can take 0.2–0.5 seconds per check, and with 50 rules up to 2 seconds, critical for high-load stores. In the 1C-Bitrix documentation, the event is described as an extension point but does not guarantee performance for complex chains.
Features of the Price Rules Module
Our custom module is built on top of sale, without touching the core—a key decision that ensures compatibility with 1C synchronization and third-party integrations. We use tagged caching for conditions to minimize database load. For example, a basic module costs from $2,500 and can save up to $15,000 annually, with payback in under six months.
The rules engine stores configurations in its own table myvendor_price_rules. Each rule is a JSON structure with conditions and actions:
Click to see JSON rule example
{ "conditions": [ {"type": "user_group", "value": [5, 8]}, {"type": "region", "value": ["RU-MOW"]}, {"type": "order_history_sum", "period_days": 30, "min_sum": 10000} ], "condition_operator": "AND", "actions": [ {"type": "percent_discount", "value": 15, "target": "brand_X_items"} ], "priority": 100, "stackable": false } The condition evaluator is a set of strategy classes implementing ConditionInterface::check(). Conditions requiring database queries (order history) are cached within a single request using a static array.
Detailed: order history condition
This is the most expensive condition. Without optimization, an aggregation query on b_sale_order over 30 days can be slow. We use this approach:
Click to see PHP code example
$cacheKey = "order_history_{$userId}"; if (!isset($_SESSION['price_rules_cache'][$cacheKey])) { $sum = \Bitrix\Sale\OrderTable::getList([ 'filter' => [ '=USER_ID' => $userId, '>=DATE_INSERT' => (new \Bitrix\Main\Type\DateTime())->add('-30D'), '=CANCELED' => 'N', ], 'runtime' => [ new \Bitrix\Main\Entity\ExpressionField('TOTAL', 'SUM(%s)', 'PRICE'), ], ])->fetch()['TOTAL'] ?? 0; $_SESSION['price_rules_cache'][$cacheKey] = (float)$sum; } Excluding conditions (block when a category Y item is present) are implemented via a separate ExclusionCondition type.
How to ensure performance with many rules?
The key element is tagged caching of check results for each rule. We also introduce priorities: rules with simple conditions (e.g., by group) are checked first to eliminate most buyers before heavy queries. As a result, even with 100+ rules, cart check time does not exceed 0.3 seconds. More about caching in 1C-Bitrix can be found in the official documentation.
Deliverables
Each project includes the following deliverables:
- Analysis of current discounts in
b_discountand import of existing rules. - Design of condition and action architecture (up to 10 types in the basic version).
- Module implementation with tagged caching and event handlers.
- Integration with the cart via
OnSaleOrderBeforeSavedandOnBeforeBasketAddevents. - Administrative interface: visual rule constructor, applicability preview, history of firings.
- Full documentation (user guide, API reference, technical specification) and manager training session.
- Access to complete source code (Git repository).
- 3 months of technical support and module warranty.
Performance comparison
| Parameter | Standard module | Our module |
|---|---|---|
| Check time per rule | 0.1–0.5 s | 0.02–0.1 s (with cache) |
| Region support | No | Yes, via region code |
| Condition flexibility | 15 preset types | Unlimited types |
| Priorities | By creation date | Customizable, drag-and-drop |
Our module processes rules up to 5 times faster than the standard one due to session-level caching and lightweight queries.
Development timeline and cost
| Scope | Composition | Timeline | Cost (USD) |
|---|---|---|---|
| Basic | Up to 5 condition types + % and fixed discounts | 3–4 weeks | from $2,500 |
| Medium | + order history + regional logic + priorities | 5–7 weeks | from $5,000 |
| Full | + visual constructor + analytics + A/B testing | 8–12 weeks | from $10,000 |
The cost of module development is calculated individually, depending on complexity and required functionality. Automation of manual promotions can save up to $15,000 annually, with payback period less than six months.
Before starting, we conduct an audit of your current discounts—often importing existing rules takes longer than expected. We also evaluate database performance and help optimize indexes.
We have 10 years of experience in 1C-Bitrix development and over 50 successful projects in this field. Contact us for a free consultation and get an estimate for your project. Order the development of a price rules module—we will help implement any promotional logic.