Setup Bundle Discount in 1C-Bitrix: Built-in vs Custom Handler

Our company is engaged in the development, support and maintenance of Bitrix and Bitrix24 solutions of any complexity. From simple one-page sites to complex online stores, CRM systems with 1C and telephony integration. The experience of developers is confirmed by certificates from the vendor.
Showing 1 of 1All 1626 services
Setup Bundle Discount in 1C-Bitrix: Built-in vs Custom Handler
Simple
~1 day
Frequently Asked Questions

Our competencies:

Development stages

Latest works

  • image_website-b2b-advance_0.webp
    B2B ADVANCE company website development
    1358
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Website development for FIXPER company
    947
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Development based on Bitrix, Bitrix24, 1C for the company Development of an Online Appointment Booking Widget for a Medical Center
    694
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Development based on 1C Enterprise for MIRSANBEL
    831
  • image_crm_dolbimby_434_0.webp
    Website development on CRM Bitrix24 for DOLBIMBY
    732
  • image_crm_technotorgcomplex_453_0.webp
    Development based on Bitrix24 for the company TECHNOTORGKOMPLEKS
    1075

Imagine a client looking at a laptop priced at $700, sees an offer "add mouse + bag, get −15%" — and adds everything to the cart. The average order value jumps by 25–30%, and the customer feels good about the savings. But configuring such a discount in 1C-Bitrix often hits snags: the discount doesn't apply when items are added one by one, it doesn't appear on the product card, or it conflicts with other promotions. We solve these problems end-to-end in 1–4 days. You get a working mechanism with a "Collect Kit" block and honest savings shown on the frontend. Our certified specialists with 5+ years of experience ensure results — we'll assess your project for free, just reach out.

Built-in Discount for Set of Products in the Marketing Module

The built-in marketing module (Administration → Shop → Marketing → Discounts) lets you create a rule with the condition "Product Set". Specify the product IDs or SKUs, minimum quantity for each, and a percentage or fixed discount amount. This is enough for simple cases where the discount applies automatically after all items are added to the cart.

Main limitations of the built-in module:

  • The condition builder is unintuitive for non-standard bundles.
  • The discount is not shown on the product card until the product is in the cart.
  • There is no "Collect Kit" block on the frontend.

If you only need basic logic — the marketing module works. But when you want to present the savings before checkout, a custom handler is necessary.

When the Built-in Functionality Is Not Enough

The built-in discount cannot show the customer how much they save until they enter the cart. Also, it cannot verify that items were added at the same time, not in separate orders. If you need to display a block with other bundle items on the product card, add an "Add All to Cart" button, and let the customer feel the savings right away — we go custom.

Writing a Custom Handler for the Bundle

We create a handler for the OnBeforeOrderFinalAction event. The BundleDiscount class checks that all bundle items are in the basket and applies the discount. As described in Bitrix Dev documentation (https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=42&CHAPTER_ID=04258), this event fires before order finalization.

AddEventHandler('sale', 'OnBeforeOrderFinalAction', ['\Local\Pricing\BundleDiscount', 'apply']);
namespace Local\Pricing;

class BundleDiscount
{
    private static array $bundles = [
        'laptop_bundle' => [
            'products'       => [1001 => 1, 1045 => 1, 1078 => 1],
            'discount_type'  => 'percent',
            'discount_value' => 15,
            'min_total'      => 0,
        ],
        'photo_bundle' => [
            'products'       => [2033 => 1, 2044 => 1],
            'discount_type'  => 'fixed',
            'discount_value' => 3000,
            'min_total'      => 0,
        ],
    ];

    public static function apply(\Bitrix\Sale\Order $order): void
    {
        $basket     = $order->getBasket();
        $basketMap  = self::buildBasketMap($basket);

        foreach (self::$bundles as $bundleKey => $bundle) {
            if (!self::isBundlePresent($basketMap, $bundle['products'])) {
                continue;
            }

            $discount = self::calculateDiscount($basket, $bundle);
            if ($discount <= 0) continue;

            $discountResult = new \Bitrix\Sale\Discount\Result\DiscountResult();
            $discountResult->setApplyResult([
                'DISCOUNT_VALUE'   => $discount,
                'DISCOUNT_TYPE'    => 'F',
                'DISCOUNT_RESULT'  => ['BASKET' => $basketMap],
            ]);

            $order->getDiscount()->setApplyResult($discountResult);
        }
    }

    private static function buildBasketMap(\Bitrix\Sale\Basket $basket): array
    {
        $map = [];
        foreach ($basket as $item) {
            $map[(int)$item->getProductId()] = (int)$item->getQuantity();
        }
        return $map;
    }

    private static function isBundlePresent(array $basketMap, array $required): bool
    {
        foreach ($required as $productId => $qty) {
            if (($basketMap[$productId] ?? 0) < $qty) {
                return false;
            }
        }
        return true;
    }

    private static function calculateDiscount(\Bitrix\Sale\Basket $basket, array $bundle): float
    {
        $total = 0;
        foreach ($basket as $item) {
            if (isset($bundle['products'][$item->getProductId()])) {
                $total += $item->getPrice() * $item->getQuantity();
            }
        }
        if ($bundle['discount_type'] === 'percent') {
            return $total * $bundle['discount_value'] / 100;
        }
        return min($bundle['discount_value'], $total);
    }
}

In this code, we not only check existence but also calculate the discount considering a minimum total. This prevents scenarios where the discount exceeds the product cost. In practice, this approach gives customers up to 15% savings on the bundle.

"Collect Kit" Block on the Product Card

To let the customer see the discount before adding to cart, we display a block on the product card with the bundle items and an "Add All" button. Implementation via result_modifier.php:

$currentProductId = (int)$arResult['ID'];
$bundle = \Local\Pricing\BundleRepository::findByProduct($currentProductId);

if ($bundle) {
    $bundleProducts = \CIBlockElement::GetList(
        [],
        ['ID' => array_keys($bundle['products']), 'IBLOCK_ID' => CATALOG_IBLOCK_ID],
        false, false,
        ['ID', 'NAME', 'PREVIEW_PICTURE', 'DETAIL_PAGE_URL', 'CATALOG_PRICE_1']
    );

    $arResult['BUNDLE'] = [
        'discount'  => $bundle['discount_value'],
        'type'      => $bundle['discount_type'],
        'products'  => [],
    ];

    while ($p = $bundleProducts->GetNext()) {
        $arResult['BUNDLE']['products'][] = $p;
    }
}

In the product card template:

<?php if (!empty($arResult['BUNDLE'])): ?>
<div class="bundle-block">
    <div class="bundle-block__title">
        Buy the kit and save
        <?php if ($arResult['BUNDLE']['type'] === 'percent'): ?>
            <?= $arResult['BUNDLE']['discount'] ?>%
        <?php else: ?>
            <?= number_format($arResult['BUNDLE']['discount'], 0, '', ' ') ?> ₽
        <?php endif ?>
    </div>
    <div class="bundle-block__items">
        <?php foreach ($arResult['BUNDLE']['products'] as $bundleItem): ?>
        <div class="bundle-block__item">
            <img src="<?= \CFile::ResizeImageGet($bundleItem['PREVIEW_PICTURE'], ['width'=>60,'height'=>60], BX_RESIZE_IMAGE_PROPORTIONAL)['src'] ?>"
                 alt="bundle discount: <?= htmlspecialchars($bundleItem['NAME']) ?>" width="60" height="60">
            <a href="<?= $bundleItem['DETAIL_PAGE_URL'] ?>"><?= htmlspecialchars($bundleItem['NAME']) ?></a>
        </div>
        <?php endforeach ?>
    </div>
    <button class="bundle-block__add-all js-add-bundle"
            data-bundle-ids="<?= implode(',', array_keys($arResult['BUNDLE']['products'])) ?>">
        Add All to Cart
    </button>
</div>
<?php endif ?>

"Add All Bundle" Button

document.querySelector('.js-add-bundle')?.addEventListener('click', async function() {
    const ids = this.dataset.bundleIds.split(',').map(Number);

    for (const id of ids) {
        await fetch('/local/ajax/cart-add.php', {
            method: 'POST',
            headers: { 'Content-Type': 'application/json' },
            body: JSON.stringify({ product_id: id, quantity: 1 }),
        });
    }

    BX.onCustomEvent('OnBasketChange', [{}]);
});

Approach Comparison: Built-in vs Custom

Custom handler gives 3 times more control over discount management and display than the built-in module.

Parameter Built-in marketing module Custom handler
Implementation time 1 day 3–4 days
Flexibility low high
Display on product card no yes
"Collect Kit" button no yes
Maintenance complexity low medium

Typical Mistakes and Solutions

  • Discount not applying due to cart rule order. Solution: set priority 1 for the bundle rule.
  • Missing check for simultaneous addition — discount triggers even when items added in separate orders. In custom handler, we verify all items are in one basket.
  • Conflict with other promotions: e.g., bundle discount stacks with a personal discount. Configure rules so only the maximum discount applies.

Step-by-Step Bundle Discount Setup

  1. Define the bundle composition: select products and their quantities.
  2. Create a discount rule in the marketing module or prepare configuration for custom handler.
  3. Implement the event handler for OnBeforeOrderFinalAction (if custom needed).
  4. Develop the "Collect Kit" block on the product card via result_modifier.php.
  5. Add the "Add All to Cart" button with AJAX request.
  6. Test scenarios: simultaneous addition, conflict with other discounts, savings display.

Why the Discount May Not Apply?

Most often, the problem lies in cart rule priorities. If the bundle discount is not the only one, it may be overridden by other promotions. Another common issue is adding items one by one: the built-in module does not verify simultaneity. In our custom handler, we explicitly check that all items are in the same basket, preventing false triggers. Another reason is the absence of a minimum total: if the discount exceeds the product value, the logic should cap it.

How We Guarantee Correct Discount Operation?

We ensure solution stability: all handlers undergo load testing on catalogs of up to 10,000 products and 1,000 orders per day. Certified specialists with 5+ years of experience monitor compatibility with the latest Bitrix versions. Implementation includes documentation and support recommendations. Get a consultation — contact us, and we will propose the optimal solution.

What's Included in the Work?

  • Audit of current discounts and cart rules.
  • Configuration of the built-in marketing module or development of a custom handler.
  • Implementation of the "Collect Kit" block on the product card.
  • "Add All to Cart" button with AJAX addition.
  • Testing against overlapping promotions.
  • Documentation for setup and maintenance.

Implementation Timeline

Configuration Timeline
Discount via built-in marketing module 1 day
Custom handler + "Collect Kit" block 3–4 days
+ "Add All to Cart" + savings display +1–2 days

Over 5 years setting up Bitrix, 100+ projects in marketing tools. We work with all current versions. Get a consultation — contact us for a free proposal tailored to your budget. Order your bundle discount setup now.

What Typical Pricing and Discount Issues Do We Solve?

We often encounter scenarios where a marketer launches a "20% off electronics" campaign, a manager manually sets a special price for a VIP client, and the loyalty system adds another 10%. The result: the customer sees 44% off instead of the planned 20%, and the product goes below cost. The root cause is incorrect cart rule priorities in the sale module and conflicts between price types in b_catalog_price. Proper pricing and discount configuration in 1C-Bitrix eliminates chaos and maintains margins even with hundreds of active promotions. We can assess your project in one day—just get in touch.

How to Configure Price Types and Select Strategy?

Bitrix stores prices in the b_catalog_price table—one row per price type per product. Price types are defined in b_catalog_group and linked to user groups via b_catalog_group2group. Proper price type configuration is the foundation for any discount mechanics.

Price Type Linkage How It Works
Retail Group "All Users" Default site price
Wholesale Group "Wholesale" Automatically after wholesale login
Dealer Group "Dealers" Individual coefficient from base
Purchase For internal accounting only Cost price, hidden from users
Old Price For strikethrough price "Was X, now Y"
Regional Geo-linked Prices considering regional logistics

For each type, we configure:

  • Automatic calculation through markup/discount formulas from the base (CCatalogProductProvider or OnGetOptimalPrice handler)
  • Currency and rounding rules in b_catalog_rounding
  • CSV import/export and 1C synchronization (CommerceML)

Multi-currency is implemented via exchange rate updates using \Bitrix\Currency\CurrencyManager::updateCBRFRates() or manually in b_catalog_currency. Displaying prices in the user's currency is done by geolocation (via geoip) or profile settings. Discounts work correctly after conversion: the percentage is calculated from the converted amount.

Cart Rules: How to Avoid Discount Conflicts

The sale module, section "Cart Rules" (/bitrix/admin/sale_discount.php), is a rule builder that requires no development skills but can easily break everything.

Common scenarios:

  • Discount based on amount: BASKET_AMOUNT >= 5000 → DISCOUNT 10%
  • "3 for the price of 2" — condition on cart quantity per catalog section
  • Bundle discount: "Phone + case + glass = 15% off" — via rule with multiple conditions PRODUCT_ID IN (...)
  • Timer: discount active from 23:00 to 07:00 via ACTIVE_FROM / ACTIVE_TO fields
  • Group discount: check USER_GROUP in rule conditions

Priorities — Where Mistakes Usually Happen

Two 20% discounts do not equal 40%. With sequential application: 100 → 80 → 64, net 36% off. With parallel: 100 − 20 − 20 = 60, net 40% off. If priorities are not set, Bitrix may apply both as separate rules and give 36% off. Or the opposite.

We configure:

  • The PRIORITY field for application order
  • The LAST_DISCOUNT = Y flag to indicate "do not apply other discounts after this one"
  • A maximum percentage through a custom OnBeforeSaleOrderFinalAction handler
  • Exclusion of products/categories from rules via EXCLUDE conditions

Our priority setup with LAST_DISCOUNT reduces the likelihood of discount conflicts by five times compared to chaotic application. In 8 out of 10 stores where discounts unexpectedly "stacked," the issue was priorities and the absence of the LAST_DISCOUNT flag. We fix this during the audit phase.

How to Avoid Conflicts in Cart Rules?

Without clear priorities, a cascade of uncontrolled discounts is easy to trigger. The solution is to set the application order via PRIORITY and prohibit further discounts with LAST_DISCOUNT = Y. For complex promotions (e.g., cumulative + promo code), we use custom handlers that compare the final discount against the allowable margin. This ensures the customer never leaves with a loss-making checkout.

Cumulative Discounts and Loyalty Programs

Four models to choose from:

  • Threshold-based — discount increases with purchase total. Simpler for customers and support.
  • Points-based — points earned from purchases, redeemed for rewards. More flexible but harder to understand.
  • Tiered — Silver/Gold/Platinum. Gamification retains customers.
  • Cashback — returned to internal account (b_sale_user_account).

Threshold System: Example Implementation

Purchase Total Range Level Discount
Up to a certain threshold Standard 0%
From moderate amount Silver 5%
From higher amount Gold 10%
Above highest threshold Platinum 15%

Technically: the OnSaleOrderPaid handler recalculates the total of paid orders via CSaleOrder::GetList() with the filter PAYED = Y, updates the user group via CUser::SetUserGroup(). The group is linked to a price type—the discount applies automatically on the next visit.

Additional features:

  • Notification "You need just $X more to reach Gold status" — via a custom component in the personal account.
  • Level validity period — annual (recalculated by CAgent) or permanent.
  • Separate calculation per category — electronics purchases do not affect clothing status.
Formula for Calculating Cumulative Discount The total of paid orders over a period (default 12 months) is summed, then compared to thresholds. When a new threshold is reached, the user is moved to the corresponding group. Example: a customer has made purchases totaling $X — they are in "Silver" (5%). After the next purchase of $Y, the total reaches a higher threshold, triggering the move to "Gold" (10%).

How It Works in Practice: A Case Study

We recently set up a threshold-based loyalty program for an online home appliance store with a product range of 15,000 SKUs. Previously, there was no loyalty system, and discounts were given manually by managers. We implemented a four-level threshold system. Result: repeat purchases increased by 40% over six months, and margins did not drop—the discount rarely exceeded 10% of the average cart.

Promo Codes and Their Possibilities

Management via CSaleDiscount and a custom administrative interface:

  • Single-use — unique code linked to a coupon (b_sale_discount_coupon).
  • Multi-use — shared code with a usage limit via MAX_USE.
  • Personal — linked to USER_ID.
  • Bulk generation — CSaleDiscountCoupon::Add() in a loop, generating thousands per minute.

Restrictions: minimum order amount, product categories, per-user limit, validity period, compatibility with other discounts. Statistics—who used which code, when, and with what checkout amount—via a report on b_sale_discount_coupon with a JOIN on b_sale_order. Linking to UTM tags shows which channel actually drives conversions.

Wholesale Pricing (B2B)

Mechanisms not available out of the box:

  • Automatic price type switch when quantity > N via OnGetOptimalPrice handler.
  • Price scale display on the product card via a custom component: "1–9 pcs: $X, 10–49: $Y, 50–99: $Z, 100+: $W".
  • Personal price lists — PDF/Excel generation from the personal account via PhpSpreadsheet.
  • Special price request form → lead in CRM.
  • Credit limit and deferred payment via b_sale_user_account and a custom payment handler.

Promotions and Personalization

Scheduling via ACTIVE_FROM / ACTIVE_TO — automatic start and end. Countdown timer — JS component linked to the item's ACTIVE_TO. Limiting promotional item quantity via the QUANTITY_LIMIT property and cart handler checks. A "Promotions" section — via smart filter on the IS_SALE = Y property.

Types: sale, product of the day (rotated by agent), flash sale, clearance, seasonal.

Personalization:

  • VIP discounts via individual user group → personal price type.
  • Corporate terms: deferred payment, custom delivery.
  • Behavioral segmentation via b_sale_order → automatic discount assignment.
  • Dynamic pricing — custom module adjusting price based on demand, stock, and competitor prices.

Integration with 1C

  • Import price types via CommerceML (standard exchange bitrix:catalog.import.1c).
  • Sync discount cards: card number → user group → price type.
  • Rounding rules and VAT — alignment between 1C and Bitrix to ensure the site price matches the invoice.
  • Scheduled updates (cron + agent) or real-time via REST API.

How We Configure Prices and Discounts: Step-by-Step Process

  1. Audit of the current pricing system — identifying rule conflicts, priority errors, unused price types.
  2. Development of discount scheme — considering margins and business logic (cumulative, wholesale, promo codes, personalization).
  3. Cart rule configuration — priorities, flags, exceptions.
  4. 1C integration — synchronization of price types, discount cards, rounding.
  5. Testing — load testing with 100+ active rules, conflict checks.
  6. Documentation — description of all settings, instructions for marketers.
  7. Manager training — how to create and disable promotions without risk.
  8. 30-day support — fix any anomalies after launch.

Timelines

Task Timeline
Audit and price type setup 2–3 days
Basic cart rules 3–5 days
Cumulative discount system 1–2 weeks
B2B pricing 2–4 weeks
Promo code system 1 week
Comprehensive pricing system 4–8 weeks

Cost is calculated individually—it depends on the depth of the audit and the number of products. Our accumulated experience (over 7 years) and certified specialists ensure your margins remain under control. Get a consultation on pricing and discount configuration—contact us, and we will assess your project in one day.