Setting up the export of additional details from 1C to 1C-Bitrix

Configuring Additional Attribute Export from 1C to 1C-Bitrix

Additional nomenclature attributes in 1C are extensions of the product card: technical specifications, certificates, application parameters. On the site they become filters, tabular data in the product card, and keywords for search. Configuring their correct transfer and display takes up a significant portion of integration work.

Types of Additional Attributes in 1C

In 1C:UT 11, additional attributes and details are stored in two places:

Object attributes (AdditionalAttributes) — stored directly in the directory element. Exported with every exchange.

Object details (AdditionalDetails) — stored in a separate information register linked to the object. Exported similarly, but require separate enablement in the exchange node settings.

Attribute value types:

• String, Number, Date, Boolean
• Reference to a directory (the value is the GUID of the directory element)
• String with variants (enumeration)

The last type — reference — causes the most problems during exchange (details below).

How Attributes Are Transferred in XML

Additional attributes appear in the XML inside <Product>:

<AttributeValues>
  <AttributeValue>
    <Name>Power</Name>
    <Value>2500</Value>
  </AttributeValue>
  <AttributeValue>
    <Name>PowerUnit</Name>
    <Value>W</Value>
  </AttributeValue>
  <AttributeValue>
    <Name>WarrantyPeriod</Name>
    <Value>24</Value>
  </AttributeValue>
</AttributeValues>

Bitrix creates infoblock properties with the same names during import and populates them with the values.

Auto-Created Properties: The Problem of Property Codes

On first import, Bitrix creates infoblock properties with codes like CML2_ATTR_001, CML2_ATTR_002. These are unreadable machine codes that are inconvenient to work with in templates.

Best practice: before the first real import, run a cycle of test imports on a copy, then manually rename property codes to readable ones (POWER_WATT, WARRANTY_MONTHS). After this, subsequent imports will not change the codes (Bitrix looks for a property by matching the name, not the code).

Alternatively — write an OnIBlockPropertyAdd handler that, when creating a property via exchange, sets the correct code based on the name (transliteration):

AddEventHandler('iblock', 'OnIBlockPropertyAdd',
    'setReadablePropertyCode');

function setReadablePropertyCode(&$arFields) {
    if (empty($arFields['CODE'])) {
        $arFields['CODE'] = CUtil::translit(
            $arFields['NAME'],
            'ru',
            ['change_case' => 'U', 'replace_space' => '_']
        );
    }
}

Reference Attributes: Substituting GUID with a Value

If an attribute in 1C is a reference to a directory, the XML will contain a GUID, not text:

<AttributeValue>
  <Name>Manufacturer</Name>
  <Value>f3a2b1c0-1234-5678-abcd-ef0123456789</Value>
</AttributeValue>

The product card on the site will display the GUID instead of "Bosch." This must be corrected either:

1. On the 1C side: before generating the XML, replace the GUID with the string value (the name of the directory element). This is the correct approach — no additional logic on the Bitrix side is needed.

2. On the Bitrix side: in the import handler, maintain a mapping table "GUID → value" (formed from the initial exchange or a separate directory export) and substitute the value when writing the property.

Multiple Values for One Attribute

In 1C, an attribute can have multiple values (if configured to allow multiple values). In XML they are transferred as multiple tags with the same name.

On the Bitrix side, the property must be configured as "Multiple." The import handler must collect all values into an array:

// During import, collect multiple values
$multiValues = [];
foreach ($arXML['ADDITIONAL_REQUISITES'] as $req) {
    if ($req['NAME'] === 'Applicability') {
        $multiValues[] = $req['VALUE'];
    }
}
$arProps['APPLICABILITY'] = $multiValues;

Case Study: Industrial Catalog with 60+ Attributes

A pump equipment manufacturer: each product is described by 60–80 technical parameters (working pressure, temperature range, housing material, protection class, etc.). All of these are stored as additional attributes in 1C.

On first import into Bitrix, 78 infoblock properties were created with unreadable codes. A full day was spent renaming codes and configuring types (numeric — as "Number" with units of measure; string — as "List" for filtering).

After configuration: the Bitrix smart filter component automatically offers filtering by all numeric and list properties. Buyers filter pumps by pressure, temperature, and material — without additional development.

Incremental attribute updates (when values change in 1C) — 4 minutes for the entire catalog of 2,300 items.