The first production synchronization of a catalog from 1C:Enterprise with 50,000 SKUs to 1C-Bitrix often results in timeouts and duplicates.
You seem to have enabled the e-commerce module and specified the 1c_exchange.php address — but in fact, half of the products did not load, and the rest were copied three times. CommerceML is a standard exchange protocol, but it does not guarantee unique IDs.
We are integrators with 10 years of experience and over 500 projects. Below are real schemes that solve these problems without extra costs. Annual savings on manual duplicate processing can be substantial (cost calculated after audit), and integration payback is 2–3 months.
Manual control of every order and product is a waste of time and money. Automated exchange eliminates the human factor and speeds up warehouse operations.
How the standard exchange via CommerceML works
The CommerceML protocol version 2.08 prescribes two independent flows: catalog (from 1C to the site) and orders (from the site to 1C).
Catalog upload (1C → site)
- 1C generates XML files
import*.xml(structure, products, properties) andoffers*.xml(prices, stock). - The files are sent via HTTP POST to
/bitrix/admin/1c_exchange.php. - The site parses the XML and updates the infoblock.
Order exchange (site → 1C)
- The site generates XML with orders for the period.
- 1C retrieves them and creates “Customer Orders”.
- 1C returns statuses.
Entry point — 1c_exchange.php, commands checkauth, init, file, import.
Why standard CommerceML cannot handle large catalogs?
The main limitation is monolithic XML. During every full exchange, the entire catalog is processed, which creates peak load on the server. For catalogs >10,000 SKU, a full exchange takes 5–30 minutes and consumes all resources. Conclusion: for large projects, the standard mechanism is suitable only as a foundation.
Delta updates reduce load by 5 times
Instead of a full upload every hour — a full one once a day (at night) + updating prices and stock every hour. This reduces the load during working hours by 80%. We use this approach in all projects with high stock volatility.
REST API is 3 times faster for point updates
If you need to update a single product or order status, REST API is on average 3 times faster than XML export. It is suitable for integrations with WMS or related systems.
How to avoid product duplication during exchange?
Duplicates are a consequence of identifiers (IDs) changing after restructuring the 1C database. Standard CommerceML cannot match old and new IDs. Our case: a building materials store with 80,000 SKUs on UT 11.4.
With each update, 3–5% of products received new IDs and were created anew, while the old ones were deactivated. Managers spent hours restoring them.
Solution: a middleware script that intercepts the OnIBlockElementBeforeAdd event. Before creating an element, it compares the ID from XML against a mapping table {old_id => new_id}. If the ID changed but the SKU matches, the product is updated rather than created. The duplicates disappeared.
Middleware script details
The script writes a log of all ID replacements to a separate table, which makes it possible to track the history of changes. It also checks the load of SQL queries via EXPLAIN and adds indexes if necessary.Typical first-run problems and their solutions
Timeout with large files. One XML with 50,000 products weighs 200–400 MB. On the server, parsing takes up to 30 minutes — PHP crashes. Solution: in 1C, enable "Upload in files of N products" with a threshold of 1000–5000.
Cyrillic in file names. Files with Cyrillic names do not reach the script — use transliteration in the exchange settings.
Encoding. CommerceML 2.08 requires UTF-8. Old configurations may output windows-1251. Check the header <?xml version="1.0" encoding="UTF-8"?>.
Separating access rights for the exchange account
Do not use the administrator. Create a separate user with a group that has write permissions for the catalog information block and for the exchange component.
In 1c_exchange.php there is a check: the user must belong to a group with the iblock_admin right on the target information block. This prevents accidental changes in other sections.
Exchange Frequency and Load
| Mode | Server load | Use case |
|---|---|---|
| Full export once per day | Peak, 5–30 min | Catalogs up to 10,000 SKU |
| Full + delta update | Moderate | 10,000–100,000 SKU |
| Only stock and prices every hour | Low | Highly volatile warehouses |
| REST API + 1C events | Minimal | Critical data in real time |
What our work includes
- Analysis of the current catalog structure and exchange settings
- Setup of standard or custom exchange (CommerceML / REST)
- Development of middleware to eliminate duplicates
- Implementation of delta updates and a scheduler
- Testing on test and production environments
- Manager training
- Documentation and warranty support
Integration timelines
| Task | Timeline |
|---|---|
| Standard catalog + order exchange | 1–3 days |
| + non-standard specification structure | 3–5 days |
| + resolving ID issues when migrating the database | 1–2 additional days |
| Custom exchange via REST API | 1–3 weeks |
Order an audit of your current data exchange — we will identify bottlenecks and select the optimal scheme. Get a consultation on setting up data exchange: an engineer will analyze your project and propose a solution.
Savings in managers' time — up to 40 hours per month, and the cost of errors during manual processing can be calculated after an audit.