1C and Bitrix exchange: where synchronization breaks
The 1C and Bitrix exchange on paper looks like a scheduled routine task, but in practice it is a stream where any portion of data can break off midway.
An order manages to reach the Bitrix storefront but does not get to the accounting system, and the manager learns about it from the customer. After that, stock balances, prices, and statuses already diverge.
The most common source is a hung export session. The previous exchange holds a lock or waits for a response, a new job starts over it, and the document queue begins to accumulate: some items are marked as exported, while some remain unprocessed.
The stock mismatch grows silently at this moment — the storefront shows what is not in the warehouse, and the exchange log is full of errors that no one investigates.
The second failure point is duplicate catalog items. If matching is done by name or SKU rather than by an external identifier, then a rename, a change of unit of measure, or a repeated export of the catalog creates a second card for the same product.
Stock balances are spread across duplicates, and order synchronization refers first to one item and then to the other.
Both failures share the fact that they are not visible immediately and accumulate over months. That is why we examine how this is closed: from repeatable exports and lock control to reconciliations that catch a mismatch before the customer notices it.
What managed catalog and order synchronization provides
An exchange should be evaluated not by the fact that "data moves" but by the share of operations that run without a person. The four effects below are calculated from the exchange log for a month and from the number of support requests — before and after the changes.
Order export speed no longer depends on the schedule
An order goes to the accounting system by event, not once an hour and not by a duty operator pressing a button. The share of orders reaching accounting without manual correction grows so much that a transfer queue simply does not form.
Current stock on the storefront matches accounting
An item is taken off sale at the moment of write-off, not after the next export. A whole class of failures disappears, where the customer pays for a product that is already gone, and then a refund and correspondence begin.
The reduction in manual edits is visible in support workload
The operator handles exceptions: discrepancies in units of measure, duplicate catalog items, incomplete attributes. Typical scenarios are covered by matching rules, so the number of manual edits falls and does not grow along with the product range.
Recovery time after a failure is measured in minutes
The exchange queue survives the unavailability of either side: unsent messages are saved and are sent again when connectivity returns. The break point is visible in the log — there is no need to reconcile tables manually.
Synchronization options: schedule, web services, queues
The choice of exchange mechanism is determined not by how "modern" the solution is, but by how the system behaves at peak load: how many orders pass per minute, how critical stock freshness is, and what happens when one of the sides is unavailable. Below are practical options that are actually chosen between, with honest limitations for each.
| Option | When it fits | Limitations |
|---|---|---|
| Scheduled routine exchange | Catalog items, prices, stock; dozens to hundreds of orders per day, a 5–15 minute delay is acceptable | Data arrives in a "batch"; at peak the window stretches; a missed run must be caught up with a repeat, otherwise part of the changes is lost |
| Exchange via web services | A reaction is needed at the moment of the event: stock check during checkout, payment registration, delivery status | Both systems must be available at that moment; on timeout, a repeat is mandatory, and it must not create a duplicate order |
| Message queue | Bursty event stream, multiple consumers, lossless delivery is important | A broker and its monitoring are needed; a separate area for handling "stuck" messages appears |
| Intermediate database | Systems are in different environments, there is no direct network access, exchange runs via exports | Data is duplicated, dedicated discrepancy control is needed, and a rule for "who is the master" for each field |
What is usually chosen in practice
A pure option is rare — more often they are combined: catalogs and stock are pulled on a schedule, while orders and payments are transmitted by event.
Stability is provided not by the method itself but by the wrapper around it: an exchange log with run history, reprocessing of failed packets, unambiguous matching keys, and an alert when the queue stops being processed.
Setup stages: from audit to handover to support
The 1C and Bitrix exchange breaks not at the setup stage but at the assumptions stage: if it is not determined before the start who owns the price and stock, the two systems begin to overwrite each other's data.
That is why the work follows a fixed sequence — each next step relies on the result of the previous one, not on agreements in chat.
- Integration audit. We analyze the scenarios: orders, stock, prices, statuses, returns, counterparties. For each one — direction, frequency, data owner, and acceptable delay.
- Data flow diagram. We fix which object goes where and what happens on conflict. This cuts off counter-overwrites and duplicate entities.
- Catalog item matching. Rules for linking by code and SKU, behavior of new items, units of measure, warehouses, counterparty groups — before the first catalog load.
- Exchange setup. Exchange nodes, change registration, batch export, schedule, log, and error handling — so that a failure of one packet does not stop the entire stream.
- Testing on a database copy. A run on a copy of the production environment with real volume: a series of runs, connection loss, repeated export, behavior on discrepancy.
- Integration acceptance. Control scenarios together with the customer, reconciliation of stock and amounts, log review, recording of known limitations.
- Handover to support. Run regulations, monitoring, first-line instructions, person responsible for catalogs.
After launch, the exchange lives under observation: a discrepancy is visible in the log on the day it appears, not in customer complaints.
Deliverable package: configurations, diagrams, regulations
After the exchange launch, the customer retains not only a working integration but also a set of artifacts by which it can be maintained and changed without us: configurations, a flow map, matching rules, instructions, and regulations. Below is what is included in the package and why each document is needed.
- Working exchange configurations — export profiles for catalog, prices, and stock, order import, session schedule, and handlers triggered on discrepancy.
- Data flow map — which 1C entities are connected to which site sections, in which direction data flows, and where the matching point is.
- Matching rules — by which attribute products, warehouses, and counterparties are linked, how duplicates and unpaired objects are processed.
- Integration documentation — composition of exchange fields, extension points, and the procedure for adding new properties so that an edit does not break an already working exchange.
- Administrator instructions — manual launch of a full exchange, reading the log, recognizing a hung session and correctly restarting it.
- Recovery regulations — procedure for discrepancy: reconciliation of checksums for the period, repeated export, recording of the cause.
- Typical failure log — a "symptom → cause → action" table, compiled from real cases so that the administrator can resolve them independently.
How we removed duplicate orders in a retail chain
A retail chain with several dozen locations kept orders in 1C and the storefront and customer account on Bitrix. The exchange ran on a schedule, without conflict resolution: if a transfer broke off midway, the next run created the order again.
Duplicates spread through the warehouse, managers corrected them manually, and they stopped trusting the stock on the site.
Before: manual triage instead of sales
Every day 60–80 orders had to be reconciled and merged manually — this consumed almost half of an operator's shift. Resolving one failure took an average of 40 minutes: there was no log, and from it one could not see at which step the export broke off.
The linking key was the order number, which was generated anew on every repeat, so protection against duplicate writing did not exist in principle.
After: exchange without manual edits
We rebuilt the scheme so that each record received a stable identifier on the accounting system side, and a repeated run recognized already accepted orders and skipped them.
An exchange log appeared with step-by-step status and automatic retry only of unfinished steps — instead of a full blind restart.
The share of orders with manual correction fell below 1%, failure resolution takes 5–7 minutes from the log, and duplicate stock balances do not occur.
The stability of the export stopped depending on who is on duty at the monitor. A discrepancy report arrives once a day and is most often empty — this is the criterion by which we accept the integration.
What to do if the exchange is already set up but orders are being lost
The exchange formally works: sessions close without errors, but some orders do not reach the site.
You need to check not "works or not" but where exactly the data is lost — in the registration queue on the 1C side, during transmission, or when writing the object on the site.
Loss diagnostics relies on the exchange session log: for each session you can see the volume of exported and accepted objects, the completion code, and objects that fell out of the selection.
We compare counters for the interval — how many orders were created in the accounting system and how many were accepted on the site; the discrepancy is the measure of losses.
Common causes: exchange "by change" without re-queuing after a break, conflict by external code, duplicates on repeated export.
| Option | When it fits | Limitations |
|---|---|---|
| Point-specific tuning | The environment is correct, one or two document types are lost, attribute matching is debugged | Does not remove the systemic cause: with "by change" export, the loss share will return as the order stream grows |
| Rebuilding exchange scenarios | Losses at different stages, duplicates exist, databases were edited manually | Requires an agreed downtime and catalog reconciliation — longer in terms of timeline |
| Revision of the environment and rebuilding of critical branches | The exchange runs, but there is no trust in the numbers | Requires access to both databases and a test environment for a trial run |
After the edits, we make acceptance repeatable: an order is marked with an exchange identifier, repeated export does not create a duplicate, the log stores history for the period and serves as a recovery point.
Additionally, we set up an alert about counter mismatch — we learn about lost orders from a report, not from the customer.
Describe the current exchange environment and the stage at which orders are lost — we will come back with a rebuilding plan and timelines.
Technical questions before work starts
Before work starts, doubts usually concern not the exchange itself but its behavior during failures, updates, and after handover. Below are short answers to what is asked most often; the rest we cover during the survey of your configuration.
How is it guaranteed that an order will not be lost when the connection breaks?
The order is first recorded on the site and enters the exchange queue with its own identifier; in 1C it is written only after write confirmation.
If the connection breaks, the queue is preserved, sending is repeated until a successful response, and duplicates are filtered out by identifier.
In addition, automatic reconciliation runs: the number of orders on the site and in the accounting system for the period is compared, and a discrepancy raises an alert.
Can the catalog be re-exported without stopping the site?
Yes. A full export is needed only when the catalog structure changes or after a failure; the rest of the time only changed items are transmitted — by modification date and checksum.
Items that disappeared from the export are unpublished rather than deleted: links and accumulated page history are preserved.
How does the exchange work if a product is stored in several warehouses?
Stock is exported by warehouse, and the site has a rule for selecting a warehouse for reservation: priority, closest to the customer, or with sufficient stock.
You can show total stock and assemble an order from several warehouses — then a breakdown by items and warehouses goes to 1C, and the reservation status is returned to the site.
What happens when the platform or configuration is updated?
The exchange relies on a coordinated module and event handlers, so we fix the update procedure in the regulations: first a test copy, then checking the exchange on a staging environment, and only then the production environment.
If the structure has changed, handlers are edited synchronously on both sides, with the ability to roll back preserved.
Who is responsible for the exchange after handover?
We hand over the exchange scheme, a description of matching rules, the log, and the recovery procedure in case of failure, and set up discrepancy alerts. The warranty period covers fixing exchange errors; after that, work proceeds according to the agreed support regulations.
Let's discuss the task and come back with a work plan
For the estimate to be based on facts rather than on a description, four things are enough to start: access, a test environment, a list of scenarios, and an administrator contact.
We set up the test copy on a separate database copy — the production exchange and live orders are not affected.
- Access: administrator accounts for the site and accounting system with rights only to the required sections, not full access to the entire environment.
- Test environment: a copy of the 1C database and a separate copy of the site, where catalogs and orders can be exported without risk to the production exchange.
- List of exchange scenarios: what goes in which direction — catalog items, prices, stock, orders, statuses, counterparties.
- Regulations: run schedule, export volume, behavior on data discrepancy and on connection loss.
- Administrator contact: a person on the customer side who confirms access and approves changes.
In response, we send an integration work plan: a scheme for matching catalogs and statuses, the composition of changes on the site and accounting system side, an estimate of timelines by stage, and the procedure for rollout to the production environment with a rollback point. Describe the task — we will come back with an estimate and a plan.