Fixing product property export from 1C to Bitrix

Problem: product properties not exported from 1C to Bitrix

When exchanging from 1C to 1C-Bitrix, product properties are one of the most common points of failure. In 1C, attributes are stored in the <СвойстваТовара> block of the import.xml file, and in Bitrix as information block properties. Automatic mapping via XML_ID does not always work: the GUID in 1C changed, the data type does not match, or the property already exists but with a different identifier. The result — products with empty characteristics, duplicate directory elements, or import errors. Recently, on a project with a catalog of 15,000 products, the "composition" and "country of origin" properties simply did not export, and the color and brand directories were created with duplicates. We solve this problem in 2–4 days, guaranteeing 100% correct data transfer. Below we discuss typical scenarios: from simple mapping to custom post-processing through events.

Reasons standard mapping fails

In import.xml, product properties look standard:

<Товар> <Ид>GUID</Ид> <ЗначенияСвойств> <ЗначениеСвойства> <ИдСвойства>GUID-свойства</ИдСвойства> <Значение>Красный</Значение> </ЗначениеСвойства> </ЗначенияСвойств> </Товар> 

The property classifier is passed at the beginning of import.xml in the <Свойства> block. During the first exchange, Bitrix automatically creates information block properties — if they do not exist. But on subsequent exchanges, discrepancies often arise.

Typical error: the GUID of a property changed in 1C, but the old one remains in Bitrix. Or in 1C the field was "String" and became "Directory" — the data type in the information block does not match. Result: the property is not filled.

According to 1C-Bitrix documentation, property mapping occurs via the XML_ID field of the information block. 1C-Bitrix Docs

How we configure export: step by step

1. Go to Catalog → 1C Exchange Settings → Property Mapping in the Bitrix admin panel.
2. For each 1C property, select the corresponding information block property. Mapping is based on XML_ID: when a property is created, the GUID from 1C is automatically written into this field.
3. If the property already exists, manually fill in XML_ID in the information block property settings (Information blocks → [desired block] → Properties → XML_ID).
4. Check data types: ensure that a string from 1C maps to a string property in Bitrix, a number to a number, and a directory to a list.
5. Perform a test import with a single product to verify mapping.

Data types and their storage

Directories (colors, brands) are a separate story. In 1C, they are stored as enumerations with a GUID. In Bitrix — b_iblock_property_enum with XML_ID. During the first exchange, items are created automatically; on subsequent ones, they are matched by XML_ID. If the GUID changed, items are duplicated. Solution: manually assign the correct XML_ID or delete duplicates via an event.

Setting up export of multiple properties

Essentially, multiple properties are configured the same way as single ones, but with the MULTIPLE = Y flag in the information block. In the exchange file, multiple values are transferred under one ИдСвойства. If the standard handler does not create a multiple record, we write a custom handler on the OnIBlockChange event. For example, for one product there might be several "size" values: handling multiple properties is solved in a couple of days, and savings on manual filling amount to up to 200,000 rubles per year.

Custom processing beyond standard mapping

If standard mapping is insufficient (for example, you need to transform a value — convert an article to uppercase, supplement a description), we use an event:

AddEventHandler('iblock', 'OnBeforeIBlockElementUpdate', function(&$arFields) { if ($arFields['IBLOCK_ID'] == CATALOG_IBLOCK_ID) { // Custom processing before saving } }); 

Custom processing via events works 10 times faster than manual database editing. This flexibility allows solving 95% of export problems. We always include this step in the project if non-standard logic is required. Requisites mapping (e.g., mapping article number to a string property) is also handled through this mechanism.

Handling SKU property export issues

SKU properties (color, size — the basis for trade offers) are transferred in offers.xml, not in import.xml. Their structure is similar; mapping is configured separately for the trade offer information block. A typical error: SKU properties are not created because the offer information block is not selected in the exchange settings. We check this first.

Typical errors and their solutions

What's included in the work (deliverables)

• Analysis of current exchange, identification of discrepancies.
• Mapping setup: matching properties by XML_ID, creating missing ones.
• Testing on a test product from 1C.
• Custom processing via events (if necessary).
• Documentation of settings and instructions for the manager.
• Training for the manager on how to maintain the mapping.
• Guarantee of correct operation — we fix bugs free of charge for one month.

Cost and timeline

The cost of setup is calculated individually depending on the complexity of the catalog and the need for custom processing. Typical projects cost from 45,000 rubles. Timeline — from 2 to 5 business days. The time saved on manual filling of characteristics pays for the work within 2–3 months, often saving up to 200,000 rubles per year. Contact us for a free preliminary assessment of your exchange. We have completed over 50 projects successfully, with a 90% first-time fix rate using CommerceML (the standard exchange format). Proper 1C directory handling and consistent XML_ID mapping are key to avoiding issues.