Why 1C and Bitrix data exchange breaks at peak order volume
1C and Bitrix data exchange rarely breaks “by itself” — it breaks where the configuration’s margin of safety runs out. While there are few orders, the exchange agent keeps up with the queue: a batch of data goes out, confirmation comes back, statuses match.
During a sale, the flow grows several times over, the queue grows faster than it is processed, and the first thing to appear are stuck exports — an exchange session cuts off midway, and the next one starts on top of the unfinished one.
The second point of failure is item mapping. If the link between items rests on SKU, barcode, or name, any renaming, change of unit of measure, or recreation of a product card breaks it silently.
Then the catalogs diverge: the warehouse writes off one item, the website sells another, and stock desynchronization surfaces at shipment — the customer has paid for something that is not physically there.
The third problem is the lack of protection against reprocessing the same batch.
If the exchange does not mark successfully received portions of data, resending after a failure creates duplicate orders: two sales postings arrive in the accounting system for one payment, and lost payment and delivery statuses settle in the customer account. Resolving such incidents manually during high season takes up managers’ time and leads to returns.
None of these failures is fixed by restarting the exchange. It is fixed by configuration: change registration rules, a stable item link key, and marking already processed batches. Below we look at how this is addressed in practice.
What changes after setup: stock, prices, order statuses
After the exchange is enabled, stock and prices stop being a “morning snapshot.” The catalog is updated in batches by changed items: each export carries only what has changed since the previous pass, so a full recalculation does not block the storefront or slow down managers’ work in 1C.
The share of successful exchange sessions reaches stable values. The exchange does not “lose” a failed session; it repeats it while preserving record order — duplicate orders and double reservations do not appear.
Previously, such a break was closed manually: exports were reconciled and the transfer was rerun, losing hours on it.
Now this class of failures disappears along with manual reconciliation: the exchange log shows what passed and when, and a discrepancy is visible before the customer notices it.
The time from order receipt to reservation is reduced from tens of minutes to seconds.
The order enters the accounting system, the item is immediately reserved, and the current status returns to the website — the manager confirms the order already seeing real availability, not “we’ll check with the warehouse.” Hence the increase in confirmation speed: the customer gets a response at checkout, not after the next scheduled run.
The reduction in manual operations is visible in the share of orders that go through without intervention: standard scenarios — a new order, change of contents, cancellation, status change — are processed automatically, and an employee gets involved only in non-standard cases.
Reservations, prices, and statuses stop diverging between the website and accounting, so reconciliation moves from a daily duty to an occasional log check.
Exchange modes: scheduled, event-driven, on demand
The choice of mode is determined by how the data changes. The catalog, prices, and stock are updated in batches — it makes sense to pull them in whole sections and a single exchange format.
Orders, payment statuses, and shipment statuses appear one by one and require a response within minutes. Therefore, in one project all three modes usually coexist: scheduled exchange, event-driven, and on demand.
| Mode | When it fits | Limitations |
|---|---|---|
| Scheduled | Catalog, prices, stock — data changes in batches | Delay equals the interval: infrequent runs accumulate discrepancies, frequent runs load both systems |
| Event-driven | Orders, statuses, stock write-off after a sale | A queue and retries are needed: without a log, an event is lost when the receiver is unavailable |
| On demand | Reconciliation, discrepancy investigation, loading a specific item or order | Does not replace regular exchange: mass operations through it create peak load |
How export frequency is calculated
Frequency is based on the allowable discrepancy, not “by eye.” If a manager confirms an order within half an hour, the order exchange interval is minutes, while the catalog can be updated at night, when edits in the accounting system are finished.
In practice, a mixed scheme is used: catalog — scheduled, orders and stock — event-driven, and on-demand exchange is left for reconciliation and recovery after a failure. Such a set covers both speed and integrity: a discrepancy becomes visible instead of accumulating for months.
Implementation stages: from item audit to handover to support
Exchange breaks not on code but on discrepancies in catalogs: in 1C an item has one key, on the website another; a warehouse is not mapped; some products have an empty barcode.
That is why we do the work in stages, and each ends with a verifiable result — this way a discrepancy is visible in the test environment, not on the first day of sales.
Work procedure
- Catalog audit. We export items, offers, warehouses, counterparties, and units of measure, reconcile keys, look for duplicates, empty attributes, and discrepancies by SKU and barcode.
- Flow scheme. We define what goes from 1C to the website (prices, stock, attributes), what comes back (orders, payment statuses, reservations), and at what frequency.
- Mapping rules. We define the linking fields for products, properties, warehouses, price types, and statuses; we separately describe behavior when an item exists in only one system.
- Setup and test environment. We assemble a copy of the database and website, configure exchange nodes, the schedule, and export of only changes instead of full synchronization, and run scenarios: new product, price change, order cancellation, return.
- Testing on real orders. We enable the exchange for part of the catalog, reconcile totals across both systems, review logs, and adjust rules before full enablement.
- Handover to support. We hand over the regulation, field descriptions, employee instructions, and a failure notification scheme.
The result is that exchange follows a predictable scenario, and manual edits are reduced to individual exceptions. Describe the task — we will come back with an estimate and work plan.
Scope of work: export rules, access rights, regulations
The document package here is not an appendix to the work but its result: using it, a new administrator can bring up the exchange without us. Everything we configure in 1C and on the website side, we record in writing.
- Export rules. A list of entities with direction and frequency: items, prices, stock, orders, statuses. For each — the trigger event, conflict priority, and behavior for items that are not in the receiving catalog.
- Data flow scheme. Where the export goes, where it is queued, which node receives the data, and what happens to an order if an intermediate link is unavailable.
- Exchange access rights. A separate service account with minimally sufficient rights and address restrictions; roles are separated — a manager works with orders but does not change export settings.
- Mapping map. Mapping of warehouses, price types, statuses, and units of measure so that a new item does not create a duplicate catalog entry.
- Instructions for managers. What to do if an order did not appear, a status did not change, or an item was sold without stock; whom to escalate to and which actions are prohibited — for example, simultaneous editing in two systems.
- Recovery regulation. The point of the last successful exchange, re-export for the period, reconciliation of discrepancies after recovery.
- Control. A run log with history, error and discrepancy notifications, regular reconciliation of item counts and totals.
We hand over the package together with training: a session for managers and a separate one for the administrator who will continue to support the exchange.
Case: eliminated duplicate orders and stock desynchronization
The client is a wholesale and retail company: a catalog of about 12,000 items, three warehouses, orders coming from the website and from managers.
Exchange between 1C and the website ran on a schedule once an hour — the entire change package was exported in full, and discrepancies were investigated manually using exports from the admin panel.
Before: batch export and manual reconciliation
Exchange sessions failed on timeouts: about 70% completed successfully. Orders that fell into the failure window remained in the accounting system and did not reach the website — several lost items accumulated per day.
Re-exporting the same orders created duplicates, and stock diverged across dozens of items: a manager sold a product that was no longer in the warehouse.
After: event-driven exchange and duplicate protection
The exchange was split into short event-driven sessions — a new order, a status change, a warehouse movement. Each record was assigned a key: resending does not create a second order, while failed sessions go into a queue and are retried with increasing delay.
The exchange log is moved to a separate table — the session time, batch contents, and error cause are visible, so a failure is investigated from logs, not customer complaints.
The share of successful exchange sessions grew to 99.8%; lost items — zero over a quarter of observation.
Duplicates were eliminated by the retry key, stock discrepancies were reduced from hours to minutes, and manual reconciliation was replaced by a report: it arrives only when discrepancies actually exist.
What to do if synchronization is already set up but fails
A failure in an already running exchange is almost never total — one area falls apart: item mapping, order statuses, or stock.
The cause is usually accumulated discrepancy: items with new attributes appeared in the catalog, a warehouse was renamed in 1C:Enterprise, some products changed their active flag.
The exchange silently swallows such changes, and the desynchronization surfaces a few days later as a batch of duplicates or zero stock.
Exchange diagnostics begins with the log, not with restarting the session. We look at which batch the process stopped on, which items did not receive confirmation, and whether the error reproduces during a manual export of the same portion.
By dividing the flow into “did not arrive” and “arrived twice,” we get an exact list of discrepancies instead of guesses.
Log recovery proceeds from this data: missing batches are resent, and order receipt is made retry-safe — the same order does not create a second record when resent. Duplicates are searched by a combination of identifiers, not by name; otherwise only the symptom is treated.
Rebuilding the rules is a separate stage that does not require stopping sales. The new rule set for the current catalog and warehouse structure is run on a copy of the database, then swapped into production, while the old one remains available for rollback.
Control reconciliations for stock and order statuses show that the discrepancy is closed, not masked temporarily.
Common technical doubts before starting work
Exchange setup affects the production environment: the catalog, prices, and orders must remain available while the scheme switches to the new one.
Therefore, work is done on a copy and in the test environment, and production exchange is moved in a short window — downtime is reduced to changing the data receiving point, not stopping the website.
Partial exchange is a normal situation, not a failure: if one branch did not go through, the others continue.
We separate flows by entity type, mark each batch with a pass label, and keep a log with the time of the last successful update — it shows which items are behind and by how much.
Will there be downtime during setup?
We switch production exchange in an agreed window, the website continues to accept orders, and data is caught up by the first full pass. If a stop is unacceptable, we set up parallel operation of two schemes and decommission the old one after reconciliation.
What happens when the connection is lost?
Exchange resumes from the break point, not from the beginning: unsent batches remain in the queue and go out after the channel is restored. Duplicates are filtered out by batch label, so resending does not create second order items.
How are discrepancies handled during partial exchange?
Reconciliation is done by keys: we compare contents, quantity, and prices, and output discrepancies as a separate list indicating the source and time of change. We fix the source priority rule at the start so that items are not edited manually in two systems at once.
Let’s discuss the synchronization task and come back with a work plan
To come back with an accurate estimate of the scope of work rather than a “from and to” range, we need to see the 1C and Bitrix exchange from the inside: which objects are already exported, what is configured on the accounting system side, and which events have broken synchronization before.
Describe the task in free form — that is enough for the first review; we will gather the rest ourselves from access and logs.
What helps start faster:
- Current exchange scheme: what is already synchronized — products, prices, warehouses, orders, statuses, counterparties — and at what frequency.
- Scheduled jobs on the 1C side: which exchanges are launched, on a schedule or by event, and who is responsible for their operation.
- Logs and errors over recent weeks: exports from logs, failure texts, cases of duplicates and stock discrepancies.
- Access: a test website environment and a copy of the 1C database, a separate environment for debugging exchange rules without risk to production.
- Business constraints and rules: which fields must not be overwritten, how to handle discontinued items, and what to do with manual catalog edits.
- Contact of an engineer on the customer side who knows the accounting system and can confirm agreements on the data structure.
Based on the review, we send a stage plan: diagnostics of the current exchange, design of mapping rules, debugging on a copy, transfer of settings to production with reconciliation of control totals for stock and orders, a maintenance regulation, and instructions for your team.
In the scope estimate, we will separately show which nodes are most heavily loaded and where there is a risk of data growth; we will coordinate the start order with your delivery schedule and season.
Describe the task — we will come back with an estimate and a stage plan.