Setting Up 1C Bitrix Exchange: Where Synchronization Breaks
Setting up 1C Bitrix exchange almost always goes smoothly on a test catalog of a hundred items — and breaks on the production one, where there are tens of thousands of products and the upload runs on a schedule.
A typical failure looks like this: the catalog synchronization completed, but the stock levels on the website diverged from the accounting system.
The cause is usually not the integration itself, but the fact that some items were left out of the selection — a manager renamed a section, a supplier changed a SKU, a new warehouse appeared in 1C that is not present in the exchange node settings.
Stock discrepancies hit sales directly: a customer places an order for a product that is physically unavailable, and the manager finds out about it a day later.
The reverse situation is no better — the website shows "out of stock" while the warehouse is full, and live orders go to competitors.
The longer a discrepancy persists, the more expensive it is to sort out: you have to reconcile the item list manually and rebuild customer trust.
A stuck upload is the second most frequent failure. The exchange session breaks off midway, some products were updated, some remained in their old state, and the next scheduled run starts on top of the unfinished one.
Meanwhile the logs are clean: the process formally completed, and the error never surfaced anywhere.
Duplicate products appear in the same place — when matching is done by name rather than by a stable identifier, and the catalog gradually becomes overgrown with copies at different prices.
A separate category is "silent" failures that don't bring down the exchange but corrupt the data: prices arrive without discounts, product properties are overwritten with empty values, images get unlinked from items.
All of this becomes visible not immediately, but through a drop in conversion or complaints from the sales department.
Let's break down how this gets closed: where to put integrity checks, how to set up matching by external code, and what to log so that a failure is found in minutes rather than weeks.
What a correct exchange delivers: speed, accuracy, fault tolerance
A properly configured exchange stops being a "background process that sometimes crashes" and becomes a predictable part of the loop: catalog, prices, stock, and orders are synchronized on schedule, not on a phone call asking "why is the old price still on the site." The export time for a catalog of 20,000–50,000 items fits into minutes instead of hours — by exporting only changed objects rather than the full tree on every run.
Data accuracy rests on reference mapping: a single key for a product, warehouse, counterparty, and price type, rules for new items, and correct handling of deleted ones.
The share of discrepancies between the accounting system and the site drops to isolated cases, and each one is investigated through the exchange log rather than by searching blindly.
Prices and stock are updated at a defined interval, so the buyer sees current availability, and the manager doesn't confirm an order for an item that's already gone.
Fault tolerance is a separate layer of work. A dropped connection, an unavailable accounting system or site, or a stuck exchange session must not lead to duplicate orders or lost items: we configure retries, split the export into batches, and verify integrity after each one.
The failure class of "the exchange crashed at night, we found out in the morning" goes away — the system signals the problem immediately, and the next run delivers what's missing without manual fixes.
Together, this delivers what the exchange is built for: export speed at which the catalog updates without downtime windows, accuracy at which the data on the site matches the accounting records, and fault tolerance at which a failure doesn't turn into lost orders. Next, we break down how this works at the configuration level.
Ways to organize exchange: comparison of approaches
Exchange between 1C and a website is almost never built "head-on." In practice, one of three modes is chosen — scheduled, event-driven, or via an intermediate layer — and each imposes its own constraints on the architecture of the catalog and orders.
Scheduled exchange runs on a schedule: 1C exports changes into a CommerceML package, the website picks it up and applies it.
Predictable load, easy rollback — but the data on the storefront lags by the run interval, and a full export on a large catalog grows linearly and hits limits.
Event-driven exchange triggers at the moment an object changes: a price or stock edit goes to the website immediately. Latency is minimal, but coupling appears — website or queue unavailability blocks export to 1C, and bursts of edits produce unpredictable load.
An intermediate layer (a queue or a separate database) decouples the systems: 1C writes events, the website processes them at its own pace. This removes rigid coupling and survives the unavailability of either side, but adds a component that must be maintained.
| Approach | When it fits | Constraints |
|---|---|---|
| Scheduled exchange | Catalog changes rarely, orders come in batches | Storefront lag, full export grows with the catalog |
| Event-driven exchange | Up-to-date prices and stock in real time are needed | System coupling, load bursts, risk of blocking |
| Intermediate layer | High frequency of changes, multiple data consumers | A separate service and its maintenance are needed |
In practice, modes are combined: catalog and prices — on a schedule, orders and statuses — event-driven. The choice is fixed in the exchange regulations: what is synchronized, how often, and in which direction.
Implementation stages of exchange: from audit to handover
Exchange between 1C and a website is not "turning on a module" but designing a data flow: what is synchronized and in which direction, how conflicts are resolved, what happens when the connection breaks.
Below is how we run such projects so that after launch the exchange works without manual intervention.
- Exchange audit. We review the current scheme: which catalogs and documents are involved, by which attributes items and counterparties are matched, how often the upload runs, where positions are lost. We identify bottlenecks — duplicates, stock discrepancies, stuck packages.
- Schema design. We determine the direction and composition of flows: products, prices, stock, orders, statuses. We define matching rules, the source priority in case of a conflict, and the launch schedule — by schedule or by event.
- Configuration. We configure the upload on the 1C side and the receiving on the website side, set up exchange profiles, mapping of properties and product variants, and access rights to the catalog and orders.
- Testing on a test environment. We run the full cycle on a copy of the data: initial upload, incremental updates, changes in prices and stock, placing an order with upload back to 1C. We reconcile checksums by positions.
- Failure handling. We set up logging, retries on connection loss, and error notifications. We check the behavior when one of the sides is unavailable.
- Handover. We provide the launch schedule, the flow schema, instructions for typical failures, and control points. We train your team to read the exchange log and run synchronization manually.
Each stage ends with a verifiable result: after the audit — a flow map, after design — an agreed schema, after configuration — a working exchange on the test environment. This order eliminates launching "on live data" and allows rolling back at any step.
What the client receives: configurations, schemas, regulations
The output is not "we configured something," but a package that lets the integration live and evolve without us.
Each artifact covers its own class of tasks: configuration is responsible for how data flows now, schemas and rules — for how to change them, documentation and regulations — for what happens during a failure or a change of responsible person.
- Exchange profiles — exported node configurations for the catalog, quotes, orders, stock, and prices. Each profile fixes the direction, set of entities, schedule, and behavior on version conflicts, so starting and stopping the exchange requires no code changes.
- Data flow schemas — a map of where each entity goes from and to: which node is the source, which is the destination, what happens to an order after confirmation, where counter-flows meet, and how discrepancies are resolved.
- Mapping rules — correspondence tables for nomenclature, properties, warehouses, price types, counterparties, and order statuses. Separately described is what to do with items that are not in the catalog: create them, link them to a group, or put them in a queue for manual review.
- Configured scenarios and schedule — scheduled jobs with intervals, queue processing, retries when a node is unavailable, and logging of every session with protocol retention.
- Documentation — an operations manual: how to start a full exchange, how to check for discrepancies, how to roll back a failed synchronization, and where to look in the logs for typical errors.
- Support regulations — who and when checks the log, how changes are made to mapping rules, and the procedure for approving edits before uploading to the production environment.
- Rollback schema — backups before a session, restore points, and the procedure to follow if prices or stock are off after an exchange.
All of this is delivered in your environment, with access for your team, and is updated when the catalog structure or accounting rules change. Describe the task — we will come back with an estimate and a plan.
Case study: how we eliminated stock discrepancies and sped up the export
The client — a retail chain with several thousand SKUs — complained about stock discrepancies between the warehouse system and the website.
The catalog export ran on a schedule and took about two hours; if a manager changed a price or stock level manually in the panel, the next export overwrote the edit, and the item went back on sale with the wrong quantity.
Customers placed orders for items that were not physically in stock — managers handled such orders manually.
What we changed
We analyzed the exchange at the structural level: some properties and trade offers were being exported to the wrong catalog sections, and some changes never made it into the package at all due to differing identifier formats.
We switched the exchange to incremental export — the system transmits only the items that have changed since the previous session, rather than the entire catalog.
Manual edits in the panel were protected from being overwritten: the exchange updates prices and stock levels but does not touch what the manager changed deliberately.
The result in numbers
| Metric | Before | After |
|---|---|---|
| Full export time | ~2 hours | 8–12 minutes |
| Share of stock discrepancies | 6–8% of items | less than 0.5% |
| Manual edits after export | 30–40 per week | isolated cases |
We also set up exchange logging separately: if a package fails, you can see which item and for what reason — troubleshooting takes minutes instead of searching blindly.
The project was handled by engineers who specialize in integrating 1C-Bitrix with accounting systems, so the exchange was designed from the start for catalog growth rather than the current volume.
How does exchange via CommerceML differ from direct integrations?
CommerceML is an exchange protocol where 1C exports data into a structured file (usually XML), and the site parses it and applies it on its side.
A direct integration works differently: code on the site accesses the 1C database directly — via an HTTP service, a web service, or an intermediary layer.
The difference is fundamental: in the first case, the systems don't know about each other and communicate through a file contract; in the second, one system pulls the other in real time.
CommerceML wins where resilience matters, not second-by-second currency. The export runs on a schedule, the file can be replayed, logged, compared with the previous one — if the site goes down or the exchange is interrupted, the data isn't lost but is applied on the next run.
A catalog with tens of thousands of items, prices, stock, characteristics, trade offers — CommerceML transfers all of this in batches, without loading the working 1C database at the moment when managers are working in it.
Direct integrations are justified in a different scenario: when a real-time response is needed.
Placing an order with instant stock verification, reserving a product, synchronizing payment and shipment statuses, exchanging documents between the site and the accounting system — here a file export lags behind, and an online request is needed.
But this approach has its own cost: any unavailability of 1C or a change in its structure breaks the link, and the load falls on the production database.
In practice, the choice is rarely either-or. The catalog, prices, and stock are more conveniently managed via CommerceML — it's a stable, predictable flow. And orders, statuses, and operations where every second counts — via direct exchange.
We usually separate these flows: heavy reference data goes in batches, while point operations go online. Such a hybrid takes the load off 1C and keeps the site operational even if the accounting system is temporarily unavailable.
If your catalog is updated rarely and orders are processed manually — CommerceML is enough. If managers work in 1C and expect an order on the site instantly — direct exchange is indispensable.
Describe how your accounting is set up and what happens to an order after it's placed — we'll come back with an estimate and a plan for each flow.
Common technical concerns about 1C and Bitrix exchange
Before starting the exchange, three questions almost always come up: whether the server can handle it, what happens when the catalog is edited from both sides simultaneously, and how to roll back if a session breaks off midway.
These are normal engineering concerns, and they are resolved not by "tuning by eye," but by specific modes and a defined procedure.
Will the exchange bring down the site — will the load increase several times over?
A full exchange reads the entire catalog, so it is launched during a low-traffic window, not in the middle of the day. After that, targeted exports do the work: changes go out in batches, not all at once.
If the catalog is large, it is split into several profiles by section — then each session is short, and the peak load on the database stays within that of a normal working day.
We separately configure pauses between steps so that the exchange does not compete with visitors for resources.
A manager edits a product in 1C, a content editor — on the site. Will there be a conflict?
Yes, if both sides write to the same fields. That is why we agree on the division in advance: prices, stock, and the product list are managed by 1C, while descriptions, photos, and properties for the cards are managed by the site.
Fields that the exchange overwrites are marked as "from 1C only" and closed for manual editing. This way conflicts do not arise by design, rather than because someone happened to be first.
The session broke off — will the catalog be left in a half-finished state?
The exchange runs in packets and records its progress: on a repeat run it continues from the last successful step rather than starting over. If a packet arrives corrupted, it is discarded entirely — no partially applied data remains.
As a safeguard, before a large export we take a snapshot of the catalog so that a rollback takes minutes rather than hours of manual reconciliation.
Describe your configuration and catalog size — we will come back with an estimate and a plan for setting up the exchange.
Let's discuss your 1C and Bitrix exchange task
Exchange between 1C and a website almost never comes down to "turning on the standard module." Everything is decided by the details: which catalogs are exported, how products and trade offers are matched, what to do with items that exist on the website but are missing from the accounting system, and how the exchange behaves when stock balances diverge.
It is these nuances that determine whether the catalog will match reality or whether managers will keep adjusting prices by hand.
To come back with an estimate and a work plan rather than generalities, we need to understand your current setup. Describe it in your own words — that is enough for an initial review.
- Which 1C configuration is used and how data is currently transferred to the website: the standard module, a third-party export, or manual file import.
- What is involved in the exchange: products, trade offers, prices, stock balances, warehouses, characteristics, images, properties.
- How often the exchange is needed and whether a delay is acceptable: once a day on a schedule or almost immediately after a change in the accounting system.
- Where the data currently diverges: prices, stock balances, duplicate items, lost properties, broken section links.
- What customizations already exist on the website and accounting system side — it is important to preserve them rather than rewrite them from scratch.
- Who is responsible for the export on the 1C side and whether there is access to a test environment for verification without risk to the production catalog.
Based on these answers, we will determine the scope: whether export rules need refinement, catalog matching setup, error handling and failure notifications, or whether it is enough to clean up the existing exchange.
In response, you will receive a phased work plan, the set of checks before launch, and a transition procedure that keeps the catalog operational.
Describe the task in whatever form is convenient — by email or a short call — and we will come back with an estimate and a work plan.