Setting up order discounts in 1C-Bitrix: marketing rules, promo codes

Order discounts in 1C-Bitrix: why the cart calculates incorrectly

A discount in the cart is the result of several independent mechanisms: marketing rules, coupons, product discounts, and the cart settings themselves. Individually, they calculate correctly.

As soon as two or three conditions trigger for the same order at once, a cart rule conflict begins: one rule recalculates the order line, the second relies on the already changed amount and produces an incorrect discount calculation.

From the outside, this looks like a broken cart — the figure changes after refreshing the page or moving to payment.

Most often, the cause is the opaque priority of marketing rules.

If several rules have the same trigger conditions, while priority and the prohibition on further calculations are left at default, the platform applies them in the order built into the settings, not the order intended by the marketer.

This leads to double application of a condition: a coupon is layered on top of a promotion, a product discount on top of an order discount.

Then the discrepancy carries into payment. The customer sees one amount, the payment system receives another, and the manager sees a third in the order: somewhere the discount was calculated before rounding, somewhere an already applied coupon was not taken into account.

This is not a cosmetic error in the order total — the order fails at payment or is handled manually, and the customer stops trusting the price in the storefront.

Below, we break down how this is resolved: how to set up rule priorities, where to prohibit repeated discount application, and how to test the calculation across all scenarios.

What changes after putting the cart rules in order

Order in cart rules means, above all, predictable calculation. Each rule gets an explicit priority, a set of conditions (order total, contents, customer group, validity period), and a flag for whether it can combine with other discounts.

In the order card, you can see which rule triggered and how the price was formed — instead of “magic” in the total. On the 1C-Bitrix platform, this is covered by built-in tools, without core modifications or workaround modules.

Checkout speed increases because the discount is applied automatically when the condition is met, rather than after entering a promo code.

The cart is recalculated once on the server; intermediate states are not passed back and forth between browser and server, so moving between checkout steps no longer “waits.” The page keeps one clear reference point: the current total and a hint about how much is missing until the next discount.

The share of abandoned carts decreases when the customer sees the logic, not just the number: “one item is missing for the set discount,” rather than a silent price change at the final step.

The wording “promo code doesn’t apply” disappears — the rule is picked up when the threshold is reached, and exceptions are described in human language.

Support workload and the volume of manual edits drop thanks to a log of applied rules. The manager sees how the total was formed and recalculates the order without manually rebuilding line items; the share of orders requiring edits after checkout noticeably decreases. “Why didn’t the discount apply” requests turn into standard self-check scenarios for support.

Discount calculation formats: promo codes, cart rules, sets

In 1C-Bitrix, conditions are calculated by three mechanisms, and they are not interchangeable.

Cart rules calculate a discount based on order contents and total, coupons and promo codes give the customer a code, and condition sets describe combinations of products, quantities, and customer groups.

Mixing modes in one rule is a common reason a discount lands on the wrong line item or is reset to zero during cart recalculation.

The priority of rule application is set manually and determines which mechanism wins in an overlap.

We record a priority matrix and run it on test carts: we check what share of line items received the discount as intended, whether there is double accrual, and whether recalculation after removing an item is correct.

We separately check compatibility with already active promotions — a new rule should not override an old one without an explicit decision.

How we implement: from cart audit to handover of policies

We start with a cart audit: we export all active discount rules and look at how they overlap and at which checkout step they trigger.

Often the source of the conflict is not the discount itself but the order in which it is applied: a rule triggers for a line item when an order-level effect is expected, or accumulation is calculated where it was not intended.

That is why we first assemble the calculation scheme, and only then go into configuration — otherwise edits are selected by trial and error rather than designed.

1. Cart and current logic audit. Inventory of active rules, promo codes, links to customer groups and payer types, and trigger points at checkout steps.
2. Calculation scheme. We fix the application order: from line item to order, what is summed, what is overridden, and when rounding and taxes are calculated.
3. Rule configuration. We transfer the scheme into marketing rules and promo codes: conditions by cart total, contents, and sections; restrictions by channels, terms, and usage frequency.
4. Test orders. Reference sets: minimum total, mixed contents, applying and removing a promo code, repeat checkout, cancellation, and return.
5. Scenario testing. Control examples at the boundaries: a threshold exactly one unit away, competition between two promotions, a discount on an already marked-down product, guest versus logged-in customer.
6. Handover to operation. Change policy, change log, owners responsible for launching promotions, and the procedure for quickly rolling back the latest rule.

Each stage ends with a verifiable result: a list of rules with priorities, a calculation scheme with examples, and a set of test orders with expected totals.

After handover to operation, your team launches new promotions according to the policy — without us and without the risk of breaking already working discounts.

What you get: rules, promo codes, schemes, and policies

The result of configuration is not individual promotions but a manageable order discount loop in 1C-Bitrix: marketing rules, coupons, a priority scheme, and a policy by which a marketer changes conditions without affecting the cart and checkout.

We hand over a set of artifacts — using them, a new administrator can figure things out without contacting a developer.

• Rule descriptions — which condition (total, quantity, product or group, period, customer role) affects what and how it combines with the others.
• Priority scheme — a table of trigger order: cart discount, line item discount, coupon, cumulative, personal; it shows what is applied first in an overlap.
• Configured mechanisms — marketing rules, coupons with usage limits and validity period, discounts by customer groups, restrictions by payment and delivery methods.
• Roles and access — separation of administrator, content manager, and developer rights so that editing conditions does not affect checkout settings.
• Edit policy — what is changed in the interface by marketing, what requires an engineer, and how each change is recorded.
• Administrator instructions — step-by-step scenarios: add a rule, check an overlap, disable a coupon, view the history of triggers and cancellations on returns.
• Test order set — scenarios that verify each discount, its cancellation, and the correctness of the final total in documents.

The priority scheme and policy cover the main risk: two promotions in the same period will not start stacking and will not give the customer a larger discount than intended. Conditions recorded in writing survive a change of contractor and edits to checkout.

Case study: how cart conversion grew after rebuilding the rules

A store on 1C-Bitrix lived with a set of rules that had accumulated haphazardly: some discounts were calculated in the checkout handler, others by third-party promo code modules.

There was no common priority, and when promotions overlapped, the result depended on the call order: the customer saw one total in the cart and another at the payment step.

That was exactly where most orders were lost, and every discrepancy in total turned into a request to the manager and a manual recalculation.

What we changed

We moved the calculation to the cart level and consolidated conditions into a single marketing rules mechanism: each received a priority, scope, compatibility with promo codes, and a prohibition on accumulation with other promotions.

Cumulative conditions — for volume, for customer segment, for repeat purchases — are calculated from the base price once and are not recalculated on every cart change, so the total stopped “floating.”

The storefront, email, and invoice now use the same calculation, so there are no discrepancies between them.

The decrease in checkout-step failures provided the main increase in cart conversion, and predictable cumulative conditions brought customers back — the share of repeat purchases more than doubled.

How a promo code differs from a cart rule and what to choose

A promo code is a discount that the customer activates themselves: they enter the code in the cart, and only then is it applied.

A cart rule in 1C-Bitrix triggers without customer involvement — the system itself checks the total, product contents, user group, and period, and then recalculates the price.

The choice depends on reach and on how you will manage the mechanics going forward. A promo code is appropriate when a narrow audience receives the discount: newsletter subscribers, affiliate program participants.

A rule is used when the discount should work for everyone: a total threshold, a cumulative discount, a selection of promotional products.

Overlapping conditions are the main source of errors. If both a promo code and a rule apply to an order, the result depends on the priority set in the settings: the mechanics either stack or one absorbs the other.

Before launch, we build a combination matrix and run test orders for each pair — otherwise it is easy to give a larger discount than planned.

The mechanics diverge in terms of maintenance. The promo code list grows quickly: each has its own term, usage limit, and customer binding, and without a policy it turns into hundreds of codes where no one remembers which are active.

Rules are edited centrally in one section, but composite conditions require caution: editing one parameter changes the behavior of the entire promotion.

Short answer: targeted campaigns with channel control — promo code; mass and cumulative discounts — cart rule. A single project often needs both mechanics, and then priorities and rules for joint application are built in from the start.

Technical concerns: compatibility, conflicts, rollback

Order discounts in 1C-Bitrix are calculated by one mechanism — cart marketing rules and coupons. That is why new conditions rarely conflict with already configured ones: the issue is not compatibility but application priorities and whether discounts are allowed to overlap.

Before modification, we export the active rules and assemble a set of control carts, against which we then verify final totals. This also provides a safe rollback: the previous configuration is restored in full, without manually editing conditions.

Can the calculation be migrated from another system?

We transfer the logic into marketing rules and coupons: the same conditions, thresholds, and exceptions by products and groups. Then we check against historical orders — the total should match the previous calculation.

Why was the discount applied twice?

The condition triggered both in a cart rule and in a coupon for the same product. We separate them by scope, set priority, and prohibit overlap — or explicitly design a composite discount where the second tier depends on the first.

What will happen to orders if something goes wrong during modification?

We work on a copy, publish after verification, and export the rule configuration before every change. Rolling back to the previous calculation takes minutes, and the customer sees the usual prices the entire time.

Let's discuss your task: send us the cart calculation scheme

To come back with an estimate and work plan, we need source data on the current cart mechanics, not a general description of “we need discounts.” The more accurately you show how totals are currently calculated and where rules overlap, the fewer clarification cycles preparation will take.

• Discount conditions: which product groups or catalog sections they apply to, from what order total they trigger, whether there is a cumulative principle and validity period.
• Rule priorities: what should win if several discounts and a promo code apply to one cart — apply the maximum, sum them, or block overlaps.
• Five to seven order examples: cart contents, applied promo code, expected final total, and pre-discount total — using them, we will test the calculation logic on a test copy.
• Current configuration: screenshots or an export of existing cart rules, a list of active promo codes, and the terms of their restrictions.
• Integration data with 1C: how prices and discounts arrive, whether there are restrictions by product range, and how often the catalog is updated.
• Access to the test copy: staging environment, accounts for the required roles, and a list of what must not be changed in production — we test edits in isolation.
• Desired cart behavior: whether the discount is calculated for the entire order or per line item, whether delivery is included, and how the discount line is displayed at checkout.

Describe the task in this scope — we will come back with an estimate and work plan: we will break the logic down into rules, show their priority order, and test the calculation on your examples before deploying to the live site.