Fast price exchange between 1C:UT and 1C-Bitrix: quick export with price type mapping
When product nomenclature syncs once a day but prices need updating every 15–30 minutes, a separate engineering task arises. Discount campaigns, seasonal adjustments, purchase price changes — any of these factors requires a fast and accurate export. We solve this by configuring a separate exchange stream optimized for volume and speed. With over 5 years of integrations, we have encountered dozens of 1C:UT and Bitrix configurations and developed reliable synchronization schemes. According to 1C-Bitrix documentation (helpdesk.bitrix24.ru), for effective exchange it is recommended to separate product and price exports.
The need to separate price and nomenclature export
A full product exchange (with images, properties, descriptions) can take hours and block the database. If prices are updated within the same stream, a simple discount change triggers a re-export of the entire catalog. A separate XML file for prices — offers — weights 10 times less and processes in minutes even for a catalog of 50,000 items.
Price types in UT and mapping to Bitrix
In 1C:UT 11, prices are stored in the information register ЦеныНоменклатуры. Each price has a type (kind). Typical types: retail (for individuals), wholesale (for dealers with volume thresholds), purchase (cost price — usually not exported to the site), and promotional (temporary prices).
In Bitrix, each UT price type corresponds to a price type in the trade catalog (b_catalog_price). The mapping is configured in Settings → Trade Catalog → Price Types.
| UT price type | Bitrix price type | Who sees it |
|---|---|---|
| Retail | BASE | All (anonymous) |
| Wholesale | WHOLESALE | Group "Wholesale" |
| Promotional | SALE | All (overrides BASE) |
Permissions for viewing price types are managed via Settings → Trade Catalog → Price Types → Access groups.
Configuring a separate XML file for prices
For fast price exchange, UT can generate a separate XML file containing only prices without nomenclature. In the CommerceML protocol, this is implemented via the exchange type "Offers" (offers.xml) — it contains only prices and stock balances without the full product card.
Structure of the offers file:
<КоммерческаяИнформация ВерсияСхемы="2.08"> <ПакетПредложений> <Предложения> <Предложение> <Ид>product-guid#characteristic-guid</Ид> <Цены> <Цена> <ИдТипаЦены>retail-guid</ИдТипаЦены> <ЦенаЗаЕдиницу>1250.00</ЦенаЗаЕдиницу> <Валюта>RUB</Валюта> </Цена> </Цены> </Предложение> </Предложения> </ПакетПредложений> </КоммерческаяИнформация> When Bitrix receives this file, it updates only prices — it does not touch texts, images, or properties. The operation is fast even for large catalogs.
Comparison of approaches: full exchange vs. separate XML for prices
| Parameter | Full exchange | Separate XML for prices |
|---|---|---|
| Processing time (50,000 items) | Hours | 2-5 minutes |
| Server load | High | Low |
| Possibility of frequent updates | Once a day | Every 15-30 minutes |
| Risk of database blocking | High | Minimal |
Segmented prices by counterparties
In UT 11, there is a mechanism for counterparty segments and personal prices. A single client can have an individual price different from the price list. On the site, this is implemented via a personal account: an authorized user sees "their" price.
Technically: during export from UT, several price types are formed — base plus per-segment. For each segment on the Bitrix side, a separate price type is created, linked to a user group. A user from segment "VIP" enters the Bitrix group "VIP", the group has price type "VIP" — and they automatically see the correct prices.
Syncing segments (which user is in which segment) is a separate task — either through counterparty exchange (counterparty in UT enters the corresponding Bitrix group) or through Bitrix24 CRM with deal mapping.
Promotional prices with validity dates
In UT, promotional prices have start and end dates. CommerceML 2.08 supports passing price validity dates:
<Цена> <ИдТипаЦены>promotional-guid</ИдТипаЦены> <ЦенаЗаЕдиницу>990.00</ЦенаЗаЕдиницу> <НачалоДействия>YYYY-MM-DDT00:00:00</НачалоДействия> <ОкончаниеДействия>YYYY-MM-DDT23:59:59</ОкончаниеДействия> </Цена> Bitrix imports and saves the dates in b_catalog_price. The catalog component automatically shows the promotional price only during its validity period. For this to work, Bitrix must have the bitrix:catalog.price.expire agent configured — an agent that clears expired prices.
Case: online store of building materials with promotions
One of our clients — a building materials store with a catalog of 25,000 items. Weekly promotions on product groups (discounts up to 30%). Promotions were planned in UT, but the manager manually edited prices in Bitrix before each promotion (40–60 items). Often forgot to reset the price after expiration.
We configured a separate XML file for prices with promotion validity dates. Exchange interval — 30 minutes. Promotions start and end automatically; the manager only needs to create a promotional price list in UT. Additionally, we configured the transfer of the "old price" via the "Recommended Retail" price type — on the site a strikethrough price is displayed as COMPARE_PRICE. Manager time savings: 80%.
Common mistakes when setting up price exchange
- Mismatch of price type GUIDs in UT and Bitrix. - Lack of write permissions for price types for the agent user. - Incorrect frequency of import agents (too often -> load, rarely -> outdated prices). - Ignoring the "Update only prices" flag in import settings.Process and what is included
- Analysis — study the 1C:UT configuration, exchange scheme, current Bitrix settings.
- Design — define price types, mapping, frequency, XML format.
- Implementation — configure export from UT, create price types in Bitrix, write import agents.
- Testing — verify prices for all scenarios (segments, promotions, overlaps).
- Deployment — launch in production, train managers on working with promotions in UT.
The result includes:
- working exchange scheme with separate XML for prices;
- configured mapping of all price types;
- update agents with required frequency;
- testing report and regulation for managers.
Timeline: from 3 to 7 working days depending on complexity. We will assess your project for free — contact us to get a consultation. We guarantee correct exchange operation even under high load — over 150 implemented integrations confirm the reliability of the approach.