Bitrix integration audit: where data exchange with 1C breaks
The exchange is configured, the scheduled job runs without errors — yet the storefront shows yesterday's stock levels, and you learn about the discrepancy from a customer, not from the system.
The failure is almost never in the exchange itself: it is in the junctions where data goes from the accounting system into the catalog and returns from an order into a document.
It is precisely these transitions that a Bitrix integration audit checks: the exchange log, item matching by external code, and the actual state of stock levels and statuses.
The cost of mismatch is made up of three classes of failures. Stock discrepancies sell items that are not in the warehouse while simultaneously keeping in reserve what has already been shipped.
Stuck orders do not reach assembly until a person notices them manually — and they notice neither the first nor the second. Double write-offs quietly corrupt warehouse accounting and surface only during inventory, when the history of item movement can no longer be restored.
The causes repeat. The catalog is edited manually in the 1C-Bitrix panel, and the external code stops matching the accounting item — positions start duplicating or disappearing.
The catalog export breaks on a timeout and restarts from the middle without idempotency, so prices and stock levels arrive in parts. Order statuses are not matched to sales documents, and the order remains in an intermediate state forever.
Next we break down how this is closed: which exchange points are checked first, what is considered normal for discrepancy, and how to set up the exchange so that a failure is visible before the buyer notices it.
Results of integration optimization: time, stability, control
We measure integration optimization with four metrics before and after: catalog export speed, exchange stability, recovery time after a failure, and the share of stock discrepancies.
We take measurements at the diagnostics stage and repeat them after each change — the effect is visible in numbers, not in a description of the work performed.
Catalog export is the heaviest operation.
Batch transfer in chunks with revision tracking instead of line-by-line iteration removes the main bottleneck: a full run no longer takes hours and blocks other exchanges, and incremental updates reach the site in minutes instead of on a nightly interval.
Exchange stability rests on repeatability of the result: reprocessing the same batch does not create duplicates and does not corrupt prices.
A failure in one chunk does not bring down the entire exchange — it continues, the problematic batch goes into a queue for investigation, and the catalog does not remain in a half-updated state.
Recovery time after a failure is determined by how safely the process can be restarted. Exchange checkpoints and batch-level logging allow continuation from the last successful revision instead of reconciling the catalog manually — downtime is reduced from hours to minutes.
The share of stock discrepancies is the final metric of trust in the integration. After cleanup, it drops to fractions of a percent, and regular reconciliation produces specific items for targeted investigation instead of a general list of problematic products.
Monitoring becomes background: the exchange itself signals a failure before the customer notices it.
Options for organizing the exchange: comparison of approaches
The data exchange scheme between the site and the accounting system determines how quickly changes reach the storefront and how many manual operations remain for the manager.
During the audit, we first record which option is already in use and check whether it matches the real load: with a stream of orders and frequent price changes, scheduled export begins to lag and generates discrepancies.
How the approaches compare
| Option | When it fits | Limitations |
|---|---|---|
| Scheduled exchange | Catalog changes rarely, prices and stock levels can tolerate delay | Data becomes stale between runs; a failure skips an entire interval |
| Event-driven exchange | Need a reaction to an order, payment, or status change at the moment of action | Requires a reliable queue and retries: a lost event silently loses data |
| Intermediate exchange layer | Multiple sites or systems, different formats, high load | More expensive to support; requires monitoring of accumulation and error investigation |
| Direct query to the accounting database | One-time transfer or reconciliation of discrepancies | Load on the production system; no resilience to connection breaks |
The choice is determined not by developer convenience but by data freshness requirements.
During the audit, we compare the actual delay between systems with the one the client considers acceptable, and we check that when the connection breaks, the exchange recovers without duplicates or lost records.
Stages of work on the exchange: from scheme to handover
Work begins not with configuration edits but with a data flow diagram: until it is recorded which entities move in which direction between the site and the accounting system, any change is guesswork.
Below is the order in which a Bitrix integration audit proceeds, so that the result is reproducible and does not depend on who was on duty yesterday.
- Inventory of exchanges. We collect all flows: catalog, stock levels, prices, discounts, order statuses, registration and authorization, document export. For each one — source, destination, format, schedule, volume per run.
- Mapping data flows. We record which system owns the reference data and which only reads it; where data is transformed; at which step intermediate tables and manual modifications appear.
- Finding exchange failure points. We examine logs and run history: unfinished sessions, partially applied chunks, duplicate items, stock discrepancies, "stuck" orders, item matching errors, timeouts due to exceeding the waiting time.
- Fixes. Rerunning the job becomes safe (reapplication does not create duplicates), responsibility for reference data is delineated, a chunk size limit is introduced, errors are written to the log with a clear reason instead of a generic "failed".
- Testing the exchange on real data. A run on a copy of the production database: before/after reconciliation by number of items and amounts, separate scenarios — new product, removal from sale, return, status change, order from multiple warehouses.
- Acceptance of work. A list of checks with expected results, metrics: full exchange time, share of discrepancies, number of manual interventions per month. We hand over the operation regulations and instructions for troubleshooting a failure.
After handover, the client sees the exchange as a manageable process: it is clear what broke, how soon it will be restored, and what actions will return the systems to a consistent state.
What we hand over based on the results: configurations, schemes, regulations
After the audit, the client's team is left not with a fifty-page report but with a working set: configurations, schemes, and regulations by which the exchange between a 1C-Bitrix site and the accounting system can be maintained and developed without us.
- Data flow scheme — which nodes participate in the exchange, in which direction entities travel, where intermediate queues are located, and what happens when the connection breaks.
- Exchange documentation — a list of objects and fields with mapping types, item matching rules, frequency and trigger conditions, behavior during version conflicts.
- Data access rules — which accounts have rights to what, where read-only keys are used, how personal data exports are restricted, and who is responsible for rotation.
- Exchange settings as exportable configurations — rule templates, connection profiles, job schedules; everything is versioned so rollback takes minutes, not hours.
- Monitoring regulations — which events are considered emergencies, where notifications go, within what time the on-duty engineer must see a discrepancy, and by what sign to understand that the exchange has stopped.
- Failure map and recovery procedure — step-by-step scenarios for typical failures: node unavailability, duplicate items, broken links, stock discrepancies.
From then on, the artifacts live as part of the project: releasing a new version, adding a node, or investigating an incident relies on the document, not on the engineer's memory.
Case study: exchange with 1C stopped losing orders and stock levels
Retail division: orders from the site went to the accounting system, stock levels went back to the storefront.
Six months after launch, managers began catching stock discrepancies — a customer placed an order for an item that was physically not in the warehouse, and two or three identical orders from the same buyer surfaced in the accounting system.
What we found during the audit
The exchange with 1C on 1C-Bitrix ran on a schedule once an hour and exported the entire catalog rather than changed items.
Orders were sent without a unique key: when the connection broke and transmission was repeated, a second record was created, while the original remained with the old status.
There was no exchange log — the failure was learned about from a customer call, and the lost order was found manually by reconciling lists.
What we changed
We switched the exchange to incremental export: only new and changed items are transferred, not the entire catalog. Each order received a unique identifier, by which a repeated send updates the existing record and does not create a duplicate.
The schedule was shortened to short intervals, control of the success of each pass was added, and a nightly stock reconciliation was added, which automatically marks discrepancies for investigation.
Metrics before and after
| Metric | Before | After |
|---|---|---|
| Duplicate orders | up to 40 per month | isolated, investigated the same day |
| Stock discrepancies | 3-5% of items daily | fractions of a percent, reconciled by morning |
| Catalog export time | about an hour, regular breaks | several times faster, without breaks |
We separately configured notifications to the engineer when the exchange deviates — now the problem is visible before the buyer notices it.
What to do if the exchange is already configured but works unstably?
A configured exchange rarely fails entirely — it "drifts" in parts: items do not reach the catalog, order statuses diverge, the export stops halfway and is forced through manually.
Each such case is closed manually: matching is corrected, stock levels are transferred, and the stuck queue is restarted.
That is how a legacy exchange scheme appears: it grew out of iterations where each exception was patched for a specific case.
Matching rules and export conditions live directly in the handler code and are tied to individual warehouses and item groups — as long as nothing changes, it works.
We start diagnostics not with an individual failure but with the exchange log as a whole: where the export break recurs regularly, which objects bypass the exchange, and how many operations are closed manually.
An unstable exchange usually rests on two or three areas rather than being spread across the entire scheme.
Then we map the actual scheme: which entities participate, by what attribute they are matched, how conflict and retry after failure are handled. Settings hardcoded in code are moved into configuration — a new product group is connected by a manager, not a developer. Integrity control and automatic retry close stock and status discrepancies.
As a result, the exchange stops requiring manual modifications with every change, and an export break is handled on its own instead of accumulating until reconciliation.
Common technical concerns about data exchange
An exchange audit begins with access to the accounting system — this step most often delays the start. Full rights are not needed: a separate account with read access to the registers and reference data involved in the exchange is enough.
Every access goes into the log, access is time-limited, and it is revoked after the work is completed.
A channel break does not mean data loss: the exchange runs in chunks and remembers the last confirmed one. After the connection is restored, transmission continues from the stopping point, and duplicates are filtered out by identifiers.
We run the check on a copy of the environment, so the site and accounting system continue to operate normally.
Is full access to the accounting system needed?
No. An account with read-only access to the registers involved in the exchange is enough. Rights are issued for the duration of the work, are not distributed across the whole team, and are revoked immediately after completion.
What happens if the connection breaks during export?
The exchange records the last confirmed chunk and does not overwrite documents already received. After the channel is restored, transmission goes from the stopping point, duplicate records are filtered out by identifiers — manual reconciliation is not needed.
Can the exchange be checked without stopping operations?
Yes. We take measurements on a copy of the environment or during a low-load window: order placement and the storefront are not blocked. If a run on production data is needed, we choose a nightly window and prepare a rollback point in advance.
Let's discuss the task: we will return with an estimate and work plan
To come back with an estimate and work plan rather than clarifying questions a week later, we need a snapshot of how the exchange is currently set up.
Below is the minimum set of source data: if something is not at hand, send what you have, and we will collect the rest ourselves on a call with your engineers and 1C administrator.
The review timeline depends on the number of environments and the volume of reference data and is usually stated immediately after reviewing the materials.
- List of integrations: what exchanges with what — site, 1C configuration, warehouse, POS, marketplaces, external services; for each one — flow direction and purpose.
- Current exchange scenarios: catalog export, stock levels, prices, orders, statuses, document registration; scheduled or event-driven, and at what frequency.
- Exchange journals and error logs for the latest period: which items fail, whether items are duplicated, whether stock differs between the site and the accounting system.
- Data volume: number of product items, trade offers, counterparties, orders per day — these are used to calculate load and full run time.
- Map of fields and matching rules: how items, properties, warehouses, order statuses, and prices are linked; where rules are set manually.
- Access and environment: test environment or database copy, rights to read logs and exchange settings, contact engineer on the 1C side.
- Constraints: scheduled windows, downtime requirements, specifics of modifications that must not be broken.
Describe the task and attach what you already have — we will return with an estimate, priorities, and a work plan, including the order of checks and rollback points for each exchange scenario.