Configuring Price Export from 1C to 1C-Bitrix

Price export from 1C to 1C-Bitrix is the most sensitive part of the exchange. Mismatched price types, duplicates, and GUID errors cause up to 30% of client issues in our practice (TrueTech's internal data). Reducing these errors by 90% is achievable through proper configuration. For years, we at TrueTech have helped companies set up seamless synchronization. In this article, we cover key aspects of configuring price export: from price categories to promotional offers and currencies. We provide a step-by-step process so you can resolve typical issues yourself or hand the task to a specialist. For example, setting up lightweight XML exchange can reduce server costs by approximately $200 per month.

How to configure price types in 1C and Bitrix?

Prices are transferred from 1C to Bitrix in the offers.xml file of the standard CommerceML exchange. Each SKU contains a <Prices> block with one or more pricing categories. In Bitrix, each price type from 1C corresponds to a price type in b_catalog_price_type and a record in b_catalog_price. For correct mapping, identifiers must be properly configured. In 1C, a price type has a unique GUID that must be passed to Bitrix. If the GUID does not match, the price will not be assigned to the product.

Example of pricing profile mapping:

Mapping is configured in Catalog → Exchange with 1C settings → Price types. We recommend using symbolic codes — they provide more accurate mapping.

Common reasons for price update failures

A frequent cause is a mismatch in the external code (XML_ID) of the product or SKU between 1C and Bitrix. If the GUID changed in 1C but was not updated in Bitrix, the price will not be written. Another cause is outdated currency rates when multicurrency prices are converted incorrectly. In one project, a handler error in 1C substituted the base price instead of the promotional price, causing an inflated cost on the site. The solution is to check the exchange log and mapping settings.

Separate price synchronization (lightweight XML)

Full catalog exchange is heavy. When prices change frequently (promotions, dynamic pricing), a lighter mechanism is needed. We use a lightweight XML file prices.xml that contains only prices. This reduces exchange time by up to 80% — from 10 minutes to 2 minutes for catalogs with 10,000 SKUs. In our experience, 95% of pricing issues are resolved by proper GUID mapping.

<КоммерческаяИнформация>
  <ПакетПредложений>
    <Предложения>
      <Предложение>
        <Ид>GUID-торгового-предложения</Ид>
        <Цены>
          <Цена>
            <ИдТипаЦены>Розничная</ИдТипаЦены>
            <ЦенаЗаЕдиницу>1250.00</ЦенаЗаЕдиницу>
            <Валюта>RUB</Валюта>
          </Цена>
        </Цены>
      </Предложение>
    </Предложения>
  </ПакетПредложений>
</КоммерческаяИнформация>

The handler on the Bitrix side parses the XML and updates b_catalog_price by the SKU's XML_ID.

Updating price in Bitrix:

$priceData = CCatalogProduct::GetByID($productId);
CCatalogProduct::SetPrice($productId, $priceTypeId, $price, $currency);
// or directly:
CCatalogPrice::Update($priceId, ['PRICE' => $price, 'CURRENCY' => 'RUB']);

Comparison of full and lightweight exchange:

Lightweight price export step-by-step configuration

Old price and promotional price

In Bitrix, there is a CATALOG_PRICE_OLD field (old price for strikethrough display). If 1C has two pricing categories — 'Base' and 'Promo' — we map:

• Promo → main price type in Bitrix (BASE)
• Base → old price field (b_iblock_element_prop with code OLD_PRICE or via a price type)

Another option is to create a dedicated price type 'Old price' in Bitrix and display it in the catalog.element component template as strikethrough.

Currencies

Bitrix supports multicurrency prices. In b_catalog_price, the CURRENCY field stores the currency code. When exchanging with 1C, prices are transferred in the currency specified in 1C. Conversion to other currencies uses rates in b_currency_rate, configured in Store → Currencies.

If 1C passes prices in USD but the site shows them in RUB, ensure the rate is current. The rate can be updated automatically via the Central Bank of Russia: the currency module has a built-in agent for updates.

Group prices and discounts

If the site has group prices (e.g., different prices for B2B clients), they are implemented in Bitrix via price type + user group: in b_catalog_group, configure which price type is available for which group. 1C passes multiple price types simultaneously, and Bitrix shows the buyer the one corresponding to their group.

What's included in the setup

As part of a synchronization setup project, we deliver:

• Detailed documentation of the current exchange configuration and price types
• Mapping of all price types between 1C and Bitrix
• Development of a lightweight price exchange handler (if required)
• Configuration of promotional and old price display
• Ensured correct multicurrency price functionality
• Comprehensive testing and error resolution
• Provision of all credentials and final documentation
• 2-hour online training session for your administrator
• 1 month of post-launch support and monitoring

Our experience spans over 5 years of 1C integrations, with more than 50 successful synchronization projects. We guarantee accurate price transfer and stable exchange operation.

Typical project cost: $1,500–$3,000, with an estimated ROI of 3 months due to reduced manual efforts (saving $500/month in labor).

If you need to configure price export from 1C to 1C-Bitrix, write to us — we will evaluate your project turnkey. Contact us for a consultation.

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.

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

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.

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

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.