Setting up the export of product group hierarchies from 1C 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
    1175
  • 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 Nomenclature Group Hierarchy Export from 1C to 1C-Bitrix

The catalog section hierarchy is the first thing a buyer sees on a site. An incorrectly built category structure breaks navigation and SEO. During 1C integration the task sounds simple ("transfer the folder tree"), but in practice the structure of the "Nomenclature" directory in 1C rarely matches what needs to be shown to buyers.

The Structure of Groups in 1C and Its Limitations

In 1C:UT, the "Nomenclature" directory is hierarchical. Each folder can contain subfolders of any depth. During export, this hierarchy is transferred in the Classifier → Groups XML section:

<Groups>
  <Group>
    <Id>root-guid</Id>
    <Name>Electronics</Name>
    <Groups>
      <Group>
        <Id>child-guid</Id>
        <Name>Smartphones</Name>
        <Groups>
          <Group>
            <Id>grandchild-guid</Id>
            <Name>Apple</Name>
          </Group>
        </Groups>
      </Group>
    </Groups>
  </Group>
</Groups>

Bitrix reads this tree and creates infoblock sections with the correct parent relationships (IBLOCK_SECTION.IBLOCK_SECTION_ID).

Typical problem: in 1C the tree is organized conveniently for accountants and purchasing managers — not for buyers. The "Dairy Products" folder contains subfolders "Drinking Milk," "Sour Cream," "Cottage Cheese" — all fine. But there is also a parallel "Imported Goods" folder that duplicates the same nomenclature by a different criterion. On the site, only one such structure is needed.

Filtering Groups During Export

In the 1C exchange node settings, specific groups can be selected for export. This is the primary tool for "cleaning" the structure:

  • Export only "public" groups (those needed by buyers)
  • Exclude technical groups ("Services," "Containers," "Raw Materials," "_Archive")
  • If a needed branch is nested inside an unneeded one — the child group can be specified directly

Alternative approach: in 1C, add a "Publish on site" attribute (boolean) to groups and filter the export by it. This gives fine-grained control without changing the directory structure.

Preventing Link Breakage: How Not to Destroy SEO When the Structure Changes

When a group in 1C is renamed or moved — in Bitrix the section will be updated at the next exchange: the name and/or parent section will change. But the section URL (pretty URL) will not be automatically updated — it will remain as before (if set manually) or change (if generated from the section CODE).

If the section CODE in Bitrix is generated from the name — renaming a group in 1C will change the CODE, the URL will change, broken links appear, and search ranking is lost.

Solution: disable auto-generation of CODE from the name for infoblock sections. The CODE must be set once and never change. To do this, in the OnIBlockSectionAdd / OnIBlockSectionUpdate event handler — check that CODE is not empty, and do not overwrite it when updating from 1C.

Synchronizing Sort Order

In 1C, groups are sorted alphabetically (or manually, if manual sorting is enabled). On the site, the order of sections in the menu and catalog is often set manually by an editor.

To prevent the exchange from resetting manual section sorting:

  • In the Bitrix exchange node settings, enable "Do not update section assignment"
  • Or in the section update handler (OnIBlockSectionUpdate) — preserve the SORT field unchanged if it is already populated

Multiple Section Assignment for a Product

One product from 1C belongs to one group (one parent folder). In Bitrix, a product can be assigned to multiple sections (via b_iblock_section_element). This multiple assignment must be configured manually on the site — 1C does not transfer it.

Protection against overwriting: in the exchange settings, enable "Do not update section assignment" after the first load. Otherwise every exchange will reset manual reassignments.

Case Study: Catalog Restructuring Without Losing SEO

Client — an industrial equipment manufacturer. Structure in 1C: "Equipment for Oil Refining," "Equipment for Chemical Industry," etc. — by industry. The site requires a structure by equipment type: "Pumps," "Compressors," "Heat Exchangers."

Problem: these classifications are incompatible. One pump can be both oil and chemical simultaneously.

Solution: from 1C, export the technological structure (by industry) to a hidden infoblock (not displayed in the menu). The public catalog — a separate infoblock with a manual structure by equipment type. Synchronization: when a product changes in 1C — its copy in the technological infoblock is updated; via XML_ID linkage, the data synchronizes with the public infoblock.

The SEO structure — fully under editor control, independent of changes in 1C.