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-8in Bitrix settings (Cyrillic in GUIDs does not cause issues) - During the first import, disable full-text indexing (
CSearch::Indexis not called whenSKIP_REINDEX = Yin agent options) - After the first import — run re-indexing manually
- Batch updates of SKU prices/stock levels via
CCatalogProduct::Updatein 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.







