Setting up the export of product characteristics from 1C:UT to 1C-Bitrix

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.
Our competencies:
Development stages
Latest works
  • image_website-b2b-advance_0.png
    B2B ADVANCE company website development
    1177
  • image_bitrix-bitrix-24-1c_fixper_448_0.png
    Website development for FIXPER company
    811
  • 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
    564
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Development based on 1C Enterprise for MIRSANBEL
    747
  • image_crm_dolbimby_434_0.webp
    Website development on CRM Bitrix24 for DOLBIMBY
    655
  • image_crm_technotorgcomplex_453_0.webp
    Development based on Bitrix24 for the company TECHNOTORGKOMPLEKS
    976

Configuring Item Characteristics Export from 1C:UT to 1C-Bitrix

Item characteristics in UT are the mechanism for tracking variants of the same product. A T-shirt in three colors and five sizes is one item with 15 characteristics (3×5). In Bitrix, these are trade offers (SKUs). Correctly transferring this structure is one of the most technically demanding tasks in integration.

Characteristics in UT: Internal Structure

In 1C:UT 11, characteristics are stored in the ItemCharacteristics directory. Each characteristic is a set of property values: color = "Blue," size = "M," material = "Cotton." A characteristic has its own GUID, which is used for identification in Bitrix.

The ItemPrices register and the WarehouseGoods register track records at the characteristic level. This means: different characteristics of the same item can have different prices and different stock levels.

How Characteristics Are Transmitted in XML

When exported, characteristics are transmitted in two ways:

Method 1: Via the classifier — in the Classifier → ProductCharacteristics section, available properties (Color, Size) and their values are described. This is the "schema." Then in Catalog → Product → ProductCharacteristics, each characteristic references values from the classifier.

Method 2: Inline — characteristic values are transmitted directly inside <Offer>, without a separate classifier. This method is simpler to parse but loses relationships between values.

Bitrix supports both methods. The standard UT exchange uses Method 1.

Mapping: UT Characteristics → Bitrix SKUs

After import, the structure in Bitrix looks as follows:

  • Product infoblock (e.g., ID=5) — parent elements (T-shirts)
  • Offers infoblock (linked to the products IB) — SKUs (specific characteristics)

Each trade offer (SKU) in Bitrix corresponds to one characteristic in UT. The XML_ID of the offer = {product GUID}#{characteristic GUID}.

Product XML_ID:        a1b2c3d4-...
Characteristic XML_ID: e5f6g7h8-...
Offer XML_ID:          a1b2c3d4-...#e5f6g7h8-...

This GUID pair is the identification key. When a characteristic's price or stock level is updated in UT — Bitrix finds the correct offer by this key.

Common Issues When Importing Characteristics

Duplicate trade offers. If a characteristic's GUID in UT has changed (database recreation, database merging) — Bitrix will create a new offer instead of updating the existing one. The old offer will remain as a "dead" entry. Periodically clean b_iblock_element of offers infoblock elements with no link to current GUIDs.

Lost property values. If a property value in UT is not a text string but a reference to a directory element (e.g., a color from a "Colors" directory with a GUID), Bitrix receives the GUID, not the name. The template will display "{8f3a...}" instead of "Blue." A handler is needed that substitutes the string value during import.

Dependent characteristics. UT has no built-in mechanism for dependent characteristics (if size = XL, then available colors = Blue and Black only). In Bitrix, this is implemented via JavaScript on the frontend or through a compatibility value table. During import, either all possible combinations must be created as SKUs (including unrealistic ones), or the matrix of available combinations must be transmitted via a separate mechanism.

Large Numbers of Characteristics: Optimization

Items with many characteristics — for example, 500 products with 100 characteristics each = 50,000 SKUs — create a heavy load during import.

Recommendations:

  • Enable SITE_CHARSET = utf-8 in Bitrix settings (Cyrillic in GUIDs does not cause issues)
  • During the first import, disable full-text indexing (CSearch::Index is not called when SKIP_REINDEX = Y in agent options)
  • After the first import — run re-indexing manually
  • Batch updates of SKU prices/stock levels via CCatalogProduct::Update in a transaction, not one by one

Case Study: Clothing with a Size×Color Matrix

A clothing brand: 800 models, each in 5–8 colors and 6 sizes = up to 2,400 SKUs per group. Total approximately 180,000 SKUs in Bitrix.

First full import with characteristics: 3 hours 40 minutes. After optimization (disabling indexing during import, batch SKU creation, zip compression of XML): 55 minutes.

Incremental exchange (only changed SKUs): 3–8 minutes every 30 minutes.

Additional task: in the catalog template, when selecting a color — automatically hide unavailable sizes (no stock). Implemented via a JS matrix generated by Bitrix from the SKU table with stock levels.