Mastering Unit Export from 1C to Bitrix: Step-by-Step Configuration

Imagine: a building materials catalog with 5,000 products, each with a unique unit type. The exchange with 1C is set up, but on the site units appear only as pieces, although in 1C they are specified in meters and packages. Result: customers get confused in orders, managers recalculate manually, errors increase. A typical situation we solve in 2-3 days, saving approximately $2,500 annually by eliminating manual corrections.

At first glance, everything is simple: there is OKEI, there is a standard CommerceML data exchange. But when the nomenclature runs into thousands of items, and a product can be sold in meters, square meters, 50-meter rolls, or 6-piece packages—fine-tuning is essential. As integrators, we face this regularly. Over 8+ years, we have configured measurement unit export for hundreds of catalogs, from building materials to cable products.

How Measurement Units are Transferred from 1C to Bitrix

In 1C:UT, units are stored in the Classifier of Units of Measurement (OKEI) directory. Each unit has an OKEI code (796 = piece, 006 = meter, 055 = kg), a short and full name. Nomenclature can have multiple units:

• Base unit — for warehouse accounting.
• Sales unit — for customer display.
• Additional units with conversion factors.

Example: cable is accounted in meters (base), sold in 100-meter coils. Customer orders '2 coils' → warehouse receives an order for 200 meters.

According to CommerceML 2.08, the unit is transmitted in the BaseUnit tag:

<Item> <Id>product-guid</Id> <Name>Cable NYM 3x2.5</Name> <BaseUnit CodeOKEI="006" FullName="Meter">m</BaseUnit> </Item> 

Bitrix saves the unit in the MEASURE field of the information block and in the b_catalog_measure table. Additional units with factors are transmitted via UnitsOfMeasurement:

<UnitsOfMeasurement> <UnitOfMeasurement> <Code>coil</Code> <FullName>Coil</FullName> <ShortName>coil</ShortName> <Factor>100</Factor> <PriceInclTax>false</PriceInclTax> </UnitOfMeasurement> </UnitsOfMeasurement> 

The standard exchange module creates unit records in b_catalog_unit with factors. But if a product has a packaging ratio (e.g., sold only in whole coils), this needs to be handled separately.

Why Packaging Multiplicity Matters

You cannot buy 'half a box' of nails or half a roll of wallpaper. In Bitrix, the field MEASURE_RATIO handles this—the quantity multiple. By default it equals 1 (pieces), but can be fractional for weight-based products (0.001 for grams).

During exchange with 1C, packaging ratio is often transferred in additional attributes. In the import handler we capture this:

if (isset($arXML['PACKAGE_RATIO'])) { CCatalogProduct::Update($elementId, [ 'MEASURE_RATIO' => floatval($arXML['PACKAGE_RATIO']), ]); } 

Automated configuration reduces catalog update time by 5 times compared to manual entry. This is 3× faster than using standard exchange without custom handlers.

Weight-Based Products: Nuances

For weight-based products (cement, cereals), accuracy down to 0.001 kg is needed. Bitrix allows setting MEASURE_RATIO < 1, and in the cart—a step field. The price is tied to the base unit (1 kg), total = price × entered quantity. This standard is often overlooked. Time savings on catalog updates—up to 60%.

Building Materials: Multi-Unit Catalog

A construction supply store is a classic example. One product can have multiple sales units:

Each row is a separate configuration. Manual processing of such catalogs takes weeks. We automate the transfer through CommerceML, including all factors. Our approach is 4× more efficient than manual entry.