1С and Bitrix document exchange: where synchronization breaks
The document exchange between 1С and Bitrix rarely breaks entirely — it tears at specific points.
The typical picture: the catalog is exported on a schedule, while stock and prices travel in separate packets, and in the interval the site manages to sell an item that no longer exists in 1С.
The exchange is often configured one-way, while the reverse export of orders runs on its own schedule.
Stock discrepancies accumulate toward the evening peak, and price desynchronization surfaces after a discount recalculation or a change of the price base: the customer sees one amount, the manager in 1С sees another.
Duplicate products in the catalog are the second most frequent breaking point. A SKU or a matching rule changes, and the exchange creates a new item instead of updating the old one: the former is left without stock and prices, the new one arrives with zero sales history.
After a repeated full export without reconciliation by external identifier, hundreds of such clones accumulate — the catalog bloats, filters and search return junk.
Lost orders are the most expensive point. At peak, the exchange queue fails to process the packet, the export to 1С is interrupted by a timeout and is not retried: the order hangs "in processing", the invoice is not generated, the warehouse does not see the shipment. A day later this means a call from the customer and a manual search across two systems.
We break down step by step exactly where the packet is lost and how that is closed.
The result of well-tuned synchronization: speed, accuracy, order
Three metrics show that the document exchange between 1С and 1С-Bitrix actually works: the share of items with discrepancies, order turnaround time, and the volume of manual edits made by a manager per shift. We take them before launch and after — on the same product list and the same warehouse.
Accuracy of stock and prices
- Discrepancies between the warehouse and the catalog are isolated items instead of regular ones: the cause of each is investigated down to zero.
- Prices and discounts are recalculated on every export, not by the start of the next day.
- Stock reserved for an order goes to the catalog together with the changes — the customer does not order what is not there.
Catalog update speed
- New items appear on the site in the same exchange cycle as the edit in the accounting system.
- The exchange runs over changed objects, not the entire database: processing time does not grow with the catalog.
- A change to a single document does not wait for the nightly export — the catalog is updated in the same cycle.
Order processing time
- An order from the cart goes to the accounting system without manual transfer, statuses come back to the site.
- A discrepancy on an item is visible before the order is confirmed, not at the picking stage.
- The class of errors with duplicated orders and stock written off incorrectly is eliminated.
These metrics are part of acceptance: we reconcile a sample of documents, measure the exchange cycle, and count manual operations per shift. If the share of discrepancies and the number of edits do not fall, the work is not accepted.
Ways to synchronize accounting and the site: comparing approaches
There are several ways to connect the accounting system to the site, and the choice between them is determined not by the size of the product list but by two parameters: how often stock, prices, and orders change, and how much delay the business is willing to tolerate.
Scheduled synchronization, real-time exchange, an intermediate database, and manual export by files solve different tasks and provide different resilience to failures.
| Option | When it fits | Limitations |
|---|---|---|
| Export on a schedule | The catalog and stock change moderately, a 10–15 minute delay is acceptable | Peak orders see outdated stock; the load on the database grows at the moment of launch |
| Exchange at the moment the order is placed | Products with limited stock, reservations, payment statuses | Requires fast response from the accounting system; if it is unavailable, the cart cannot be checked out |
| Intermediate database | The site runs around the clock, the accounting base is unavailable at night or during maintenance | A second point appears that must be maintained and reconciled with the source |
| Direct connection | One small catalog, a single environment, low request frequency | Any overload of the accounting base immediately affects the site |
| Manual export by files | One-off promotions, seasonal price lists, test environments | Input errors are not tracked, discrepancies accumulate until reconciliation |
Why a schedule and real time do not replace each other
The schedule covers reference data: items, prices, warehouses, counterparties — they can be updated in batches. Real-time exchange is needed where the cost of an error is higher than the delay: reserving goods for an order, payment, shipment. In practice these modes are combined within a single environment.
When an intermediate database is justified
It removes the main limitation of exporting — the site's dependence on the availability of the accounting system. Data goes into a buffer, from there to the site, and if the connection drops, the queue catches up without losing documents. The price is reconciling the buffer with the source and controlling repeated sends.
We fix the choice of integration method after reviewing the scenarios: what changes and how often, which operations must not be lost.
Setup stages: from data audit to handover to support
Document exchange between 1С and Bitrix is not about "turning on a module" but first agreeing on a data model: what is considered the source of truth, by which identifier a record is recognized on a repeated export, how discrepancies are resolved.
The order of work does not change because of this — the scope does. Below is the sequence we follow when setting this up.
- Audit of reference data and flows. We look at which reference books live in the accounting system (items, counterparties, contracts, warehouses), which ones are needed on the site, where there are duplicates and records with no activity. For each entity we fix the data owner — the accounting system or the site.
- Field mapping scheme. We describe the correspondence of attributes, types, required fields, normalization rules: units of measure, tax rates, document statuses. Separately — synchronization keys and the behavior when the same record is exported again.
- Assembling the exchange. We set the direction and frequency, the packet size, conflict handling rules: the priority of the accounting system, manual edits on the site, records marked for deletion. The exchange gets a log — it shows what went out and when.
- Test environment. A copy of the database and a site staging instance with depersonalized data. We run the full cycle: creation, modification, reversal of posting, deletion, re-synchronization after a failure.
- Validation on production data. We enable it in stages — first reference data, then documents. We reconcile checksums and record counts before and after each run, and keep a rollback point to the previous state.
- Handover to support. Exchange regulations, log interpretation, instructions for restarting and actions on discrepancy, a responsible person on the customer's side.
This order removes the main risk — "the exchange is configured, but the data drifts apart": each stage ends with a verifiable result.
What stays with you: configurations, schemes, regulations
We hand over not server access but a complete set that your team can use to run the document exchange between 1С and 1С-Bitrix without us.
We verify every artifact in the test environment: we deploy the exchange from scratch according to the instructions and reconcile the result with production.
- Handed-over configurations: exchange node settings, export rules, mapping of attributes for items, counterparties, and warehouses.
- Integration scheme: which objects go in which direction, what event triggers them, what happens to modified and deletion-marked records.
- Exchange regulations: the window and frequency of sessions, the priority side in a conflict of versions of the same document.
- Administrator instructions: manual launch, reading the log, actions for a hung session and a locked record.
- Failure procedure: a diagnostic checklist, rollback points, a repeated run without creating duplicates.
- A map of fields and reference books — so a new developer can find the needed attribute without digging through code.
Documentation
We maintain instructions and regulations as living documents: they live in your repository, are updated along with exchange changes, and do not diverge from the actual behavior of the system. Separately we fix roles and permissions — who changes the export rules and who only reads the log.
Failure procedure
It is described in advance how to distinguish a failed exchange from a partial one and how to repeat the session so that documents are not duplicated.
If the cause is on our side, response times are fixed in the agreement; if it is in the infrastructure, you still have a checklist and a clear escalation point.
Case study: synchronizing the catalog and orders without manual edits
The project is an online store on 1С-Bitrix with a catalog of about 40,000 items and a scheduled exchange with the accounting system.
Before the rework, the export ran as a nightly full exchange: the catalog and stock arrived, while orders, statuses, and payments were reconciled manually by operators — up to two hours of work a day and availability discrepancies on the storefront right during the working day.
| Metric | Before | After |
|---|---|---|
| Manual edits after the exchange | ~120 operations per week | 0 |
| Full exchange time | 50–70 minutes | 8–12 minutes |
| Stock discrepancies vs. accounting | several times a day | none recorded in a quarter |
| Exchanges requiring intervention | almost every run | isolated cases |
Failure points that were closed
The exchange was moved to an event-driven scheme: item changes go out in portions rather than as a full array, so a failed export no longer blocks the storefront — an unfinished packet is retried from the same point.
For orders we built an exchange log with idempotent recording: a repeated run does not create duplicates and does not reset a status already confirmed in the accounting system. Items and documents that could not be accepted go into a separate error log with the reason indicated.
Monitoring watches three scenarios: exchange silence longer than the set interval, a growing share of erroneous records in a packet, and queue lag. A notification reaches us and the customer before the buyer sees the discrepancy.
How does scheduled exchange differ from synchronization at the moment of order?
The exchange mode determines where the current state of accounting is at the moment the order is placed.
With scheduled exchange, the site works with a copy of the data from the last export; with synchronization at the moment of order, it queries the accounting system for a specific item.
The difference shows in data latency, the load on the accounting system, and the acceptable stock margin of error.
A schedule is a batch export of changes: items, prices, stock, characteristics.
The catalog remains available because reads come from its own database, and the data latency equals the period between runs: with an export every 10-15 minutes, the stock on the storefront lags by that same interval.
The load on the accounting system is predictable and does not fall on the peak of customer activity.
Synchronization at the moment of order removes the delay — stock and price are queried before the document is created.
The price is a growing number of requests to the accounting system precisely during peak hours and a hard dependency of the storefront on its availability: if the database is busy posting documents, checkout stalls.
Stock freshness is the key selection criterion. For fast-moving items with a piece-level stock, a 10-minute discrepancy means selling a product that is already gone and cancelling the order. For a long catalog with rare sales, the same delay is harmless, and point queries only add load.
The export frequency is chosen based on item turnover and traffic profile, not on the principle of "the more often, the better": too frequent an exchange keeps the accounting system under constant load.
The working option is a hybrid: the catalog, prices, and the bulk of stock go on a schedule, while critical items are checked at the moment of checkout.
Technical concerns: duplicates, conflicts, connection breaks
Duplicates and conflicts are not an "exchange glitch" but a consequence of how record matching and data source priority are configured. We address the situations most often raised before work starts.
The exchange between 1С and 1С-Bitrix rests on two rules: every entity has an immutable identifier for matching, and there is a master system whose value is considered correct in case of a discrepancy. Everything else is a discrepancy log, packet retry, and targeted rollback.
Who is master in a conflict of edits?
The priority of the data source is fixed at the setup stage: for items, 1С is usually declared the master, while for some cards and content it is the site.
A discrepancy is not silently overwritten: a change from the slave side goes into the log with the fields and time indicated, and it is visible in the report.
Where do duplicates come from during export?
Duplicates appear where matching is done by name or SKU — editing the string breaks the link and creates a second card. We link records by an immutable identifier, so renaming and price changes do not create a new item.
What happens if the connection drops in the middle of a packet?
The exchange runs in packets with confirmation: an unprocessed packet is marked and retried after the channel is restored.
Operations are idempotent — a repeated pass updates an already created record instead of spawning a second one, and the exchange log allows rolling back a specific batch without stopping the other flows.
Let's discuss your accounting and site synchronization task
The more specific the source data, the fewer clarifying rounds before the start. Below is what is worth preparing before the conversation: with this we will immediately describe the exchange scheme and specify the scope of work and timelines.
- Access. Test and production environments of the accounting system and the site, accounts with read permissions for reference books and documents, access to the task scheduler. Without a test environment, setup would have to be done on live data.
- List of documents and reference books. What participates in the exchange: sales, invoices, items, counterparties, stock, prices — and in which direction the data goes: from accounting to the site, from the site back, or both ways.
- Data priority rules. Whose source is master in case of a discrepancy — the accounting system or the site. Separately: how to process orders placed on the site and by what attribute counterparties are matched.
- Exchange volume and frequency. How many documents per day pass through the exchange and how quickly they must appear on the other side. This determines whether a periodic run is enough or an event-driven exchange is needed.
- Work window. When it is acceptable to pause the exchange and for how long: night hours, weekends, or a low-load period. Plus the rollback procedure if the first run reveals discrepancies.
- Responsible people on both sides. Who on the accounting side and who on the site side resolves disputed cases and confirms the correctness of the transferred data.
Describe the task — we will come back with an estimate and a work plan: we will review the source data, propose an exchange scheme, and specify timelines. You can discuss the integration task even before all the points are collected: we will suggest what to clarify first.