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

Configuring Product Characteristic Export from 1C to 1C-Bitrix

In the context of 1C-Bitrix integration, "characteristics" and "properties" are often confused. In 1C:Trade Management and 1C:ERP, there is a separate entity — Product Characteristics (characteristic type + value). These are variants of a single product with different parameters: color, size, material. In Bitrix, they correspond to trading offers (SKU) in the infoblock with CATALOG_TYPE = 2.

How 1C characteristics become trading offers

In offers.xml, each characteristic is transmitted as a separate trading offer:

<Offer>
  <ID>GUID-characteristic</ID>
  <ProductID>GUID-product</ProductID>
  <Name>T-shirt, blue, XL</Name>
  <ProductCharacteristics>
    <ProductCharacteristic>
      <Name>Color</Name>
      <Value>Blue</Value>
    </ProductCharacteristic>
    <ProductCharacteristic>
      <Name>Size</Name>
      <Value>XL</Value>
    </ProductCharacteristic>
  </ProductCharacteristics>
  <Prices>...</Prices>
  <Quantity>15</Quantity>
</Offer>

Bitrix creates a trading offer in the SKU infoblock, linked to the parent product via the CML2_LINK field.

Configuring the trading offers infoblock

In Bitrix: Catalog → Catalog Types — the parent infoblock must have the type Catalog with trading offers. The trading offers infoblock is created separately and linked to the catalog.

In the SKU infoblock, create properties for each characteristic from 1C:

• XML_ID of the property = characteristic name from 1C (or GUID, if 1C transmits them with identifiers)
• Property type — "List" for enumerable values (color, size)

Filtering by characteristics on the website

When characteristics are correctly loaded into the SKU infoblock properties, they are automatically available in Bitrix's smart filter. The catalog.smart.filter component can filter by trading offer properties — just specify that filtering is by CATALOG_TYPE = 2.

GUID characteristics: identification problem

In 1C:UT, characteristics have their own GUID, different from the product GUID. During exchange, the <ID> of the offer is formed as {GUID-product}#{GUID-characteristic}. Bitrix stores it in b_iblock_element.XML_ID of the trading offer.

During incremental exchanges, Bitrix looks for an existing trading offer by XML_ID — if found, it updates; if not, creates a new one. A problem arises if the characteristic GUID in 1C changes (for example, deleted and recreated) — duplicates will appear in Bitrix. Solution: periodically check for duplicates in the SKU infoblock by product code.

Using characteristics without SKU

If the store doesn't need trading offers (no product variants), but characteristics still need to be transmitted as properties — disable characteristic export as offers in 1C and transmit them as <ProductProperties> in import.xml. Then they go to the main infoblock properties without creating SKUs.

Verifying the exchange result

After configuration and the first exchange, verify:

• Trading offers appeared in the SKU infoblock, linked to products
• Each offer has properties filled with characteristic values
• Product card on the website displays characteristic selection (via catalog.element component with SKU switcher)
• Smart filter sees characteristic values and filters correctly

If SKUs are created but the website switcher doesn't work — check the component template: you need result_modifier.php with logic for forming the SKU matrix.