When 1C-Bitrix exchange setup breaks in production
Setting up the 1C-Bitrix exchange between "1C:Comprehensive Automation" and the website almost always goes smoothly in a test environment and breaks in production — under load, with live orders and managers working in parallel.
The first thing to surface is stock desynchronization: an item is sold in the store, but on the website it is still available to order, or vice versa — the item is in the warehouse, but the customer sees "out of stock." The reason is usually that exchange sessions run less frequently than the data changes, and part of the nomenclature drops out of the product export due to incomplete attributes.
The second class of failures is nomenclature duplicates.
If an item was renamed or recreated in 1C, and on the website it is matched by name rather than by a stable identifier, catalog synchronization spawns twins: two products with the same SKU, different stock levels and different prices.
The catalog grows, search and filters start returning garbage, and managers reconcile the cards manually.
The third is stuck order exchange queues. A session crashes midway, some orders remain in an intermediate status, and a re-run either duplicates them or loses them.
Separately, lost orders come to light: the customer paid, but the document never reached 1C — the discrepancy is only discovered during reconciliation.
All these failures share one thing: the exchange works as a black box, with no log and no integrity control. Let's break down how this is closed through configuration rather than heroic manual fixes.
What a well-tuned data exchange delivers
Export speed instead of nightly windows
The exchange is built on batched export of changes: only those catalog items, prices, and stock levels that have changed since the previous session are transferred, rather than the entire catalog.
A full catalog synchronization of tens of thousands of items fits into minutes instead of hours, and regular exchange runs in short sessions and does not block managers working in the accounting system.
Peak load on the website falls during business hours, so the session schedule is aligned so that heavy exports do not coincide with customer activity.
Up-to-date stock without discrepancies
The key cause of desynchronization is concurrent edits: a manager changes a price in the accounting system while a content editor simultaneously touches the card on the website.
We assign a single source of truth to each entity: prices, stock levels, and warehouse inventory come only from the accounting system, while descriptions and media remain on the website side and are not overwritten during exchange.
Items are matched by stable identifiers rather than by name, so renaming a product does not create a duplicate and does not break the link.
Less manual work
Once configured, manual retyping of prices and stock levels, unpublishing items when stock is zero, and reconciling catalogs at the end of the day all fall away.
Exchange rules describe these scenarios explicitly: an item goes to the archive when out of stock, returns to sale when restocked, and disputed cases end up in a discrepancy report rather than in a manager's inbox.
Resilience to failures
An exchange session is idempotent: re-running it after a connection drop does not duplicate items and does not corrupt already transferred data.
Errors on specific records do not stop the entire exchange — problematic items go to the log with a reason, while the rest synchronizes normally. We'll work through how this is handled for your catalog and accounting system.
Exchange options: from scheduled to event-driven
The choice of scheme determines not only the delay before a product appears on the site, but also how the system behaves during a failure: a standard scheduled exchange survives a channel break calmly, while an event-driven one requires a queue and redelivery. Below are three working options that we configure, and their real limitations.
Standard scheduled exchange
The built-in mechanism for configuring 1C-Bitrix exchange: the export generates packages and transmits them on a schedule — once an hour, once a day, or in a nightly window. It is suitable when the catalog changes infrequently and prices and stock are not critical to the minute.
The limitation is the desynchronization window: until the next run, the site shows yesterday's stock, and a customer may place an order for a product that is already unavailable.
Event-driven exchange
Here the export is triggered by an event — a card change, a document posting, an order status change. The delay is reduced to minutes, but a dependency on the availability of the exchange service appears: without a queue and retries, some events are lost during a network failure.
We always add a delivery log and a catch-up of lost packages — otherwise the discrepancy accumulates unnoticed.
Hybrid scheme
In practice, a combination is most often optimal: critical data (stock, prices, order statuses) is sent event-driven, while heavy entities — descriptions, images, characteristics — are exported on a schedule in a nightly window.
This way we relieve the load on the database during peak hours and do not push the full catalog on every change.
| Option | When it fits | Limitations |
|---|---|---|
| Standard scheduled | Stable catalog, non-critical stock | Delay until the next run, risk of selling an unavailable product |
| Event-driven | Frequent price and stock changes, active sales | Requires a queue and redelivery, sensitive to channel failures |
| Hybrid | Large catalog with varying change frequency | More complex to configure and maintain, requires splitting entities into streams |
We select the synchronization frequency based on the actual load: we look at how many changes per hour the accounting system produces, and from that we choose the interval or triggers.
How we set up the exchange: stages of work
We start with an audit: we look at which entities are already being exported, by what attribute a change to an object is determined, how the mapping of reference books is configured, and what happens to items that don't exist on the website side.
At this stage, duplicates of nomenclature, discrepancies in units of measurement, and "stuck" stock balances usually surface — eliminating them before work begins saves weeks of rework later.
Next, we design the exchange scheme for your process, not for a standard template: we determine what is transferred and in which direction, at what frequency, and what is considered the source of truth for price and stock.
Separately, we fix the rules of behavior in case of a conflict — for example, when a product is changed simultaneously in the accounting system and in the catalog on the website.
- Audit of the current exchange. We map the data flows, find bottlenecks in speed and logic, and assess the volume of reference books and documents.
- Integration design. We agree on the composition of exported objects, the direction of the exchange, the launch schedule, and the rules for resolving conflicts.
- Export setup. We configure exchange nodes, mappings of requisites and reference books, and filters by trade offers, warehouses, and price types.
- Test run. We run the exchange on a copy of production data: we check the correctness of prices, stock, characteristics, and product images.
- Load testing. We look at how the exchange behaves on the full volume of the catalog and during parallel work of managers in the accounting system.
- Handover and schedule. We set up automatic launch by schedule, logging and error notifications, and hand over instructions to your team.
After handover, the exchange runs on schedule without manual intervention, and failures are visible in the log rather than through customer complaints about the wrong price.
Describe your accounting and catalog scheme — we'll come back with an estimate and a work plan for setting up the exchange.
What you keep after setup
Setting up integration is not just a working channel between the accounting system and the website, but also a set of artifacts your team can use to operate, diagnose, and develop this integration without us. Below is what exactly we hand over upon project completion.
- Integration schema — a map of data flows: which entities (product catalog, prices, stock levels, orders, counterparties) go in which direction, at what frequency, what serves as the matching key, and how record version conflicts are resolved.
- Integration configurations — exported profiles and field mapping rules on both sides, including node settings, queues, and service user access rights. Deploys on a clean environment without manual assembly.
- Launch regulations — exchange schedules, procedures for handling stock discrepancies, control points, and escalation rules: what the administrator resolves independently and what requires developer intervention.
- Administrator guide — step-by-step scenarios for typical operations: manual integration restart, re-uploading an item, checking the log, rolling back a failed synchronization to the last correct point.
- Integration documentation — data structure description, error code reference with causes and remediation methods, list of dependencies on configuration and module versions.
- Logging and monitoring — configured exchange logs and failure alerts: the administrator learns about a problem from a notification, not from a client who couldn't see a product on the website.
- Acceptance checklist — test environment verification scenarios: full upload, incremental synchronization, discrepancy handling, behavior when one of the parties is unavailable.
All of this remains with you as working documentation, not verbal agreements. Describe your task — we'll come back with an estimate and a plan that clearly shows which artifacts you receive as a result.
Case: eliminating desync between catalog and orders
What it was before
An online store on 1C-Bitrix came to us with a catalog of several tens of thousands of items and scheduled exchange with 1С:Комплексная автоматизация.
The exchange ran once an hour, went as a full package, and often did not reach the end: the script hit the execution time limit, broke off midway, and left some products with outdated stock.
Managers saw availability on the site that was no longer in the warehouse, and orders placed during the exchange did not always reach 1С — they had to be reconciled manually against the log.
The cost of the desync turned out to be higher than it seemed: some orders were lost between the site and the accounting system, and manual reconciliation of stock and re-entry of documents took several hours a day.
What we changed
We broke the exchange into stages and switched it from a full package to batched export with checkpointing: each batch of the catalog and orders is confirmed, and on failure the exchange continues from the last successful item rather than from the beginning.
Orders got a separate priority queue — a new order goes to 1С outside the general schedule, so it does not wait for the next cycle.
We added an exchange log with clear statuses and alerts on deviation: if an item fails, the responsible person sees it immediately, not a day later after a customer complaint.
What it became
The exchange stopped breaking off: batches fit within the limits, and the resume point covers failures without data loss. Stock discrepancies dropped from regular to isolated cases, and lost orders are gone as a category — every order is confirmed in 1С and visible in the log.
Manual operations for reconciliation and re-entry dropped by roughly threefold: managers focus on orders rather than sorting out discrepancies.
This result comes not from the exchange itself but from its architecture — batching, order priority, and a transparent log. Describe your configuration and current exchange scenario — we will come back with an assessment and a work plan.
How does scheduled exchange differ from event-driven exchange?
Scheduled exchange runs on a timetable: a scheduled job at a set interval polls the source, picks up changes, and applies them on the receiver.
The key point here is that the exchange runs in "batches" and does not know what exactly changed since the last run: it reads out everything that fell into the selection by modification date or by information register.
Hence its characteristic properties — predictable load, a clear log, simple recovery after a failure: the exchange went down, you waited for the next cycle, and it caught up on what was missed. The price of this reliability is latency.
Between an edit to a catalog item in the accounting system and its appearance on the site, an interval passes, and for the catalog, stock, or prices this can be critical.
Event-driven exchange is built the opposite way: a change is recorded at the moment the object is written and is immediately queued for export.
We do not wait for the schedule tick — the reaction happens as the event occurs, so the data on the site and in the accounting system converge almost instantly. But the approach has its own engineering cost.
You need a reliable queue with delivery confirmation: if the receiver is unavailable, the event must not be lost, otherwise we get a discrepancy that no one will notice.
You need protection against an avalanche — mass re-posting of documents generates thousands of events, and without batching they will bring down both the site and the accounting system. You also need idempotency: re-delivery of the same event must not create a duplicate.
In practice, the choice is not binary.
Different entities require different modes: stock and prices make sense to push event-driven, because sales depend on their being up to date, while reference data, contractors, or order history — via scheduled exchange on a timetable, where a delay of a few minutes bothers no one.
Often the working scheme is a hybrid: an event-driven channel for what is critical and a scheduled one as a safety net that catches up on everything that for some reason did not go through as an event.
Separately, there is the question of what counts as a "change." In the accounting system, the same object can be re-posted dozens of times a day, and if every posting is broadcast, the event-driven channel will choke on noise.
That is why, before setting up the exchange, we work out which fields and which operations are actually important for the site, and only those are turned into events — the rest goes into scheduled exchange. This analysis is what determines which mode to set for each entity.
Common technical questions about exchange
Exchange between the accounting system and the website breaks down predictably — and almost always for three reasons: module versions have diverged, the catalog has outgrown the default settings, or the exchange ran partially and left data in an intermediate state.
Below is a breakdown of each case, how we close it, and what remains with the client after the work.
What should be done in case of a conflict between exchange module versions?
A conflict arises when the module on the website side and the handler on the accounting system side are built for different versions of the protocol: some fields stop being transmitted, the exchange completes without an explicit error, and discrepancies accumulate silently.
We lock in a working pair of versions, disable auto-updating of the exchange components, and move the settings into a configuration that is not overwritten during updates.
Before any update, we run a test exchange on a copy — if reference data or product properties diverge, we roll back before updating production.
How do you set up exchange if the catalog has tens of thousands of items?
A full exchange of such a volume hits execution time and memory limits: the process breaks off in the middle, and some items remain out of date.
We split the upload into batches, enable paginated transfer, and configure the exchange only for objects that have changed since the previous run.
Heavy sections — prices, stock, properties — are moved into separate short sessions on a schedule so that each cycle fits within the allotted window.
How do you roll back a failed exchange?
Before launching, we take a snapshot of the affected tables and save an operations log — this is enough to return the catalog and orders to their state before the exchange without losing data accumulated on the website.
The rollback is performed in a targeted way: only the entities that the exchange modified are restored, while user orders and requests remain untouched. After the rollback, we verify checksums for the key sections and only then relaunch the exchange with corrected settings.
Is it possible to exchange without taking the website down?
Yes, the exchange runs in the background and does not block the storefront: the customer continues placing orders while prices and stock are being synchronized.
We configure the queue and priorities so that critical data — availability and cost — is updated first, while descriptions and images catch up afterward. If an exchange session fails, it restarts from the last successful point rather than from scratch.
Let's discuss your exchange task
Exchange between 1C and a website almost never breaks "out of nowhere" — there are specific reasons behind it: product catalogs diverge, orders get duplicated, stock on the storefront doesn't match the warehouse.
To come back with an estimate and a plan rather than generalities, we need to see your current setup in full.
Describe how the exchange is set up now: what schedule it runs on, which objects are involved, where the bottleneck is. That's enough to understand the scope of work and avoid reinventing what already works for you.
What's useful to include with the task description:
- the exchange diagram: which entities (products, prices, stock, orders, contractors) are synchronized and in which direction;
- the 1C configuration and Bitrix edition — "Comprehensive Automation," "Trade Management," or another;
- how the exchange is launched now: on a schedule, manually, via web services, or through files;
- what you've already tried and why the result wasn't satisfactory;
- data volume: the approximate number of products, orders per day, websites, or retail locations;
- speed requirements: how quickly an order and stock should appear on the website;
- who on the 1C side and on the website side will accept the work and provide access.
Based on this description, we'll come back with a work estimate and an implementation plan: what we do on the 1C side, what on the website side, in what order, and how we verify that the data matches.
If the exchange is already partially configured, the plan will start with diagnostics rather than rewriting everything.
Describe the task — we'll discuss it concretely and come back with an estimate and a plan.