The Day 42,000 Plumbing Parts Duplicated: Why Your 1C-Bitrix CommerceML Sync is Broken

It was 3:14 AM on a Tuesday when my phone started vibrating itself off the nightstand. The client was a major industrial plumbing distributor. They had just pushed a routine catalog update from their 1C ERP to their 1C-Bitrix e-commerce site. Instead of updating prices on their 42,000 SKUs, the sync had duplicated almost every single one of them.

The site now showed "Ball Valve 1/2 inch" and "Ball Valve 1/2 inch (1)". Customers were buying phantom stock. The marketing team was watching Yandex and Google Ads burn through a 180,000-ruble daily budget, driving traffic to broken 404 pages or duplicate ghost listings. The client's database was bloated, slow, and crying for mercy.

I spent the next fourteen hours manually cleaning the database and tracing the XML payloads. That was the day I truly learned to respect the fragile, unforgiving nature of the CommerceML 2.05 protocol.

The Anatomy of a Failed Sync

Most people treat CommerceML like a simple file transfer. It isn't. It is a highly opinionated state-synchronization protocol. When you run an exchange, 1C generates two primary files: import.xml (which defines the product structure and properties) and offers.xml (which contains the prices, warehouse stocks, and SKUs).

If these two files do not speak to each other with perfect grammatical precision, Bitrix panics. And when Bitrix panics, it doesn't throw a clean error. It just silently creates duplicate database entries.

The root of almost every duplication issue lies in the <Ид> (ID) tag. In a standard 1C CommerceML setup, a product has a unique GUID. An SKU (trade offer) has a compound ID: the product's GUID, a hash symbol, and the SKU's specific GUID. It looks like this: de09f7a2-14b5-11e9-80c4#de09f7a3-14b5-11e9-80c4.

If your 1C programmer, or some generic 1C CommerceML exchange module, changes the logic of how these IDs are generated even slightly—say, by appending a unit ID or switching to article numbers—the Bitrix parser loses its bearings. It looks at the incoming XML, doesn't find a matching ID in the b_iblock_element table, and decides to create a brand new product. Congratulations, you now have duplicates.

Why Standard Modules and Cheap Freelance Fixes Fail

When this happens, the natural instinct is to hire a quick fix. You search for a bitrix commerceml freelance specialist on a cheap portal. They usually run a database cleaning script to delete the duplicates. They might tweak the Bitrix infoblock settings to "Unique by code."

This is a band-aid on a broken leg. The next time the 1C scheduler runs its nightly sync, the identical XML file is sent, and the duplicates return.

The problem is rarely in Bitrix itself. The problem is that the generated XML files do not maintain stable, immutable IDs across sessions. If your ERP system assigns a new ID to a product because it was moved to a different folder in the 1C catalog tree, the system breaks. You must force 1C to generate stable, predictable IDs that match the existing Bitrix catalog structure.

How to Verify Your XML Structure Right Now

If you suspect your sync is broken, do not wait for the next database crash. Open your import.xml and offers.xml in a text editor and check three things:

First, verify the ID matching. Find a product in import.xml. Copy its <Ид> tag. Search for that exact value in offers.xml. If the offers file uses a completely different naming convention or lacks the product ID prefix, your prices and stocks will never map correctly to your SKUs.

Second, inspect the catalog metadata. The <Классификатор> block must be identical in both files. If the category IDs in the classifier don't match the group IDs in the catalog structure, Bitrix will create duplicate categories in your information blocks, fracturing your SEO-optimized URLs.

Third, look at the SKU property definitions. Bitrix expects a specific property (usually CML2_LINK) to bind the trade offer back to the parent product. If this property is missing or malformed in the XML, the offers will import as standalone products without any connection to their parent items.

Get It Done Right, Permanently

You can spend weeks wrestling with PHP memory limits, XML parsers, and 1C settings. Or you can have it built correctly by engineers who have spent years in the trenches of e-commerce database management.

At GuardLabs, we build clean, bulletproof, and highly optimized exchange systems. We don't do quick database cleanups that break on the next sync. We analyze your ERP data, refactor the XML generation logic, and deliver a rock-solid integration that handles tens of thousands of items without a single duplicate. If you want to stop losing sales to sync errors and broken databases, let’s talk about a professional solution: Обмен каталогом 1С-Битрикс через CommerceML.