Order statuses in 1C and Bitrix diverge: where the exchange breaks
Status divergence almost never starts with a major breakdown — it is triggered by a manual edit.
A manager in the accounting system changes the order status directly, bypassing the standard transition, and the order does not get into the export selection: the change flag is not set, and only marked items are sent on schedule.
On the site, the order remains in its previous state; the customer sees “in processing” where the goods have already been picked and are waiting to be shipped.
Second source — broken exchange. A session breaks in the middle of a package, some orders make it through, some do not, and the exchange queue hangs: jobs accumulate but are not processed.
If a repeat export does not match records by order number, it creates duplicate orders — two identical requests appear on the site, the warehouse reserves goods twice, and the warehouse operator picks items from two different lists.
Third layer — unprocessed events. Handlers on the site side are not subscribed to all transitions: payment, partial shipment, item cancellation, warehouse change.
Such a transition does not fire on the site and does not go to the accounting system — statuses diverge silently, without an order exchange error in the log.
A reverse manual status edit on the site also breaks the inbound flow: the next exchange overwrites it with the previous value.
For business, this is not cosmetic. The customer gets an incorrect order state and calls support, the warehouse works with outdated data, and shipment misses deadlines.
Below we break down how this is closed: by reconciling divergences, re-exporting without duplicates, and an error log with processing of stuck jobs.
What end-to-end exchange with the accounting system gives: measurable effect
While order status travels from the accounting system to the storefront manually — by reconciling exports, emailing the warehouse, a manager calling — the customer sees “in processing” already after shipment.
The first half of the day goes to reconciliation instead of sales, and the denser the order flow, the more expensive the desynchronization.
End-to-end exchange is built on an event model. A status change in the accounting system publishes an event; a handler in 1C-Bitrix receives it, checks the order number and idempotency key, and applies status, payment, shipment, and reserve to the order.
Repeat and catch-up events go to a queue with a backoff interval — a connection break or node restart does not lose data, and the exchange restores state itself.
The effect is measured by three values. The share of orders passing through the status chain without manual intervention is 90–97%; the rest are exceptions: manager edits, partial shipments.
The time from a status change in accounting to customer notification and customer account update is seconds; under peak load, rarely more than a minute.
Support requests asking “where is my order” drop by 2–4 times: the customer sees the actual state, not an evening replica, and does not call.
To keep this in place, an exchange log lives alongside: what went through, what was rejected, and for what reason. Divergences are investigated by records, not by hearsay — this is how end-to-end exchange differs from a one-off integration.
Exchange methods: online events, queue, batch export
Order status lives in two circuits: in the accounting system it changes upon posting, in 1C-Bitrix — upon writing to the site database. There is always a gap between these moments, and its size is set by the chosen exchange mode.
The mode is chosen by two parameters: the acceptable delay between an event in accounting and its display in the customer account, and the volume of changes during peak hours.
| Mode | When it fits | Limitations |
|---|---|---|
| Event-based exchange | Seconds-level freshness is needed: payment, cancellation, warehouse change | Maintains a permanent channel, depends on availability of both sides |
| Intermediate queue | Peak load, unstable connection, retry after failure needed | Adds processing delay and a separate service to maintain |
| Batch synchronization | Mass reconciliations, large item flow, scheduled routine | Site status lags by the interval between exports |
Mixing modes is normal practice: critical transitions go by events, while stock and archived order reconciliation goes in batches.
For any mode, we configure an exchange log, retries with increasing delay, and duplicate protection so that re-delivery of the same status does not create a second record. We catch divergences with a separate reconciliation report; otherwise they surface in a customer complaint.
Implementation order for synchronization: from audit to handover
Before changing anything in code, we record the actual state of the exchange: which statuses already travel between systems, where managers edit orders manually, and how many such edits occur per shift.
Without this picture, implementing order synchronization turns into guessing hypotheses — formally the exchange works, but divergences accumulate and surface in reports.
- Survey of the current exchange. We map the scheme: which documents and reference data are involved, how often the export runs, which fields are changed manually on both sides. The output is a list of bottlenecks and the daily order volume that the exchange must withstand.
- Design of the status mapping. We bring 1C and Bitrix statuses into an explicit table, define the source of truth for each transition and the behavior on reverse update. Here we also fix which status is considered final and by which key orders are matched.
- Exchange setup. We implement a handler on the 1C side and an event receiver in Bitrix, add logging of each transition with the order identifier. Delivery errors are not lost but are queued for retry.
- Test exchange circuit. We deploy a copy of the production database and run real orders: mass changes, cancellation, return from status, connection break in the middle of a package. The goal is to see divergences before customers do.
- Integration acceptance. We run scenarios agreed with the customer and reconcile the result line by line: what is in 1C, what is in Bitrix, what is in the log. A divergence is not a “peculiarity” but an unresolved task.
- Handover to operation. We provide the exchange regulations, instructions for managers, and alarm configuration for failures, and agree on a support period. After that, status changes proceed without manual reconciliations.
Documentation and artifacts: regulations, diagrams, access rights
After the work is handed over, the customer must have a set of documents by which order status exchange between 1C and the site on 1C-Bitrix is maintained without the integration author.
The materials cover four questions: how data travels, how states correspond, what to do in case of divergence, and who has which rights.
- Data flow diagram: which events the accounting system sends to the site, in what order, where the queue sits, and how the exchange behaves when one of the sides is unavailable.
- Status map: a table of order state correspondence in the accounting system and on the site, including service and intermediate ones, with explicit marking of those that must not be changed.
- Divergence handling regulations: analysis of typical cases — status did not arrive, arrived twice, rolled back — indicating which logs to check for the cause and what may be corrected manually.
- Operator instructions: how to check the current order state, how to submit a request for investigation, and which field edits are prohibited because they break the exchange.
- Access rights to the exchange: separate roles for the service account, administrator, and operator, and the procedure for granting and revoking access.
- Integration documentation: extension points, message formats, and log composition — so a new enhancement can be assessed without reading all the code.
- Acceptance checklist: what is checked when the responsible person or contractor changes, and which settings are moved to a separate configuration file.
Regulations are written for real roles, not “for show”: the operator will not dig into code, the developer will not reconstruct exchange logic from chat history.
Such a set reduces incident investigation time from an hour of searching to a few minutes and allows changing the executor without losing manageability.
Case: how manual document reconciliation left daily work
How it was
The customer is a wholesale supplier with several warehouses: orders were assembled in the accounting system, while statuses on the site were set manually.
Every morning the operator exported the register, reconciled it with 1C-Bitrix, and corrected statuses one by one — up to two hours a day, and by noon some data diverged again.
Cancellations and returns behaved worst: the order on the site remained “in processing” even after the goods had returned to the warehouse, and the manager learned about it from the customer.
What was changed
Roles were separated: the accounting system became the single source of truth for status, and the site became the receiver. Changes go as events per order, not as a full register export, so the exchange runs quickly and does not depend on database size.
Cancellation and return were described as a separate branch: on cancellation the reserve is released, on return a reverse movement is created and the order is closed — without manual involvement.
Unavailability of one of the sides is absorbed by a retry queue, so a connection break does not lead to lost updates.
What was achieved
- Daily reconciliation disappeared entirely: two hours of operator work per day were freed up.
- The delay between a status change in accounting and on the site was reduced from hours to minutes.
- The share of orders with status divergence decreased from about 6% to zero in the monthly sample.
- Cancellations and returns stopped “hanging”: the customer sees the correct state immediately, and disputed status inquiries dropped to zero.
How does event-based exchange differ from scheduled exchange?
The difference between the modes is not in “modernity” but in who initiates data transfer. With event-based exchange, a document change in the accounting system is immediately recorded in the queue and sent to the site — status update delay is measured in seconds.
With scheduled exchange, the site polls the accounting system itself, and the delay equals the polling interval, not the channel speed.
Instant reaction costs coupling: the event handler runs inside the write operation, so it is moved to a queue with retries — otherwise site unavailability slows the manager’s work with the document.
Scheduled polling survives a connection break on its own: the next pass will pick up the same changes.
But the load on the accounting system grows with polling frequency, and the order of change processing must be restored by timestamp or document version — otherwise an outdated status settles on the site.
| Criterion | Event-based exchange | Scheduled exchange |
|---|---|---|
| Status update delay | seconds | equals polling interval |
| Load on accounting system | only at the moment of change | constant, grows with frequency |
| Failure tolerance | queue and retries needed | recovers on the next pass |
| Order of change processing | set by the queue | by timestamp or version |
| When to choose | status is needed by the customer immediately | delay is non-critical, accounting peace matters |
In practice, a combination is more often used: events for statuses that the customer sees in the customer account, schedule for reconciling divergences and reference data.
Common technical questions: duplicates, stuck queues, divergences
Two operators — a manager in the site panel and an employee in the accounting system — can change the same order at the same time.
We resolve the simultaneous edit conflict with a seniority rule: the accounting system is considered the source of truth for order composition and amount, the site for contact data and comments.
Each change is marked with a revision, and the exchange applies only versions newer than the one already saved, so an outdated edit does not overwrite the current one.
An exchange package is never considered fully delivered.
Status is transferred as a separate record: if eighteen out of twenty orders went through, two divergences are recorded in the link between 1C-Bitrix and the accounting system in the queue, and the exchange returns to them pointwise without overwriting already synchronized ones.
Partial status synchronization remains visible and manageable rather than turning into a silent divergence that surfaces during reconciliation.
What happens when the accounting system is unavailable?
Exchange events are not lost: they accumulate in the queue and are processed after access is restored. Orders on the site continue to be accepted as usual, and the customer does not see a pause. Processing order is preserved so that the status does not roll back due to an older event.
How are order cancellations and returns handled?
Cancellation and return arrive as separate events with a reason flag. If the order has already been shipped, the system does not roll it back silently — the record goes to a manual review list.
After a return, repeat synchronization for the order stops so that new statuses do not override the final one.
How are exchange errors investigated?
The log stores, for each event, the order identifier, sent data, system response, and error code. Divergences are grouped in a report: you can see exactly what did not go through and at which step. A repeat send can be launched for a separate order without restarting the entire exchange.
Let’s discuss your exchange scheme: what to clarify before starting
To come back with an estimate for integration work, rather than general wording, we need inputs on the accounting system and an understanding of how the order lives today. The minimum set for calculation and an exchange implementation plan is below.
- Status map. A complete list of order states in the accounting system and on the site, including service and intermediate ones, and an unambiguous correspondence between them. Separately, we mark statuses that must not reach the site.
- Exchange direction and source of truth. Which transitions are initiated by the accounting system, which by the site, and which side decides in case of divergence.
- Inputs on the accounting system. Configuration and edition, presence of customizations, readiness to allocate a test circuit, and the procedure for issuing access.
- Volume and acceptable delay. How many orders per day and at peak, how quickly the status must appear on the site: scheduled exchange or event sending.
- Actions by status. Which emails and notifications are tied to transitions and what to do when one of the sides is unavailable — queue and retries.
- Approval of the status map. Who approves the correspondence on the business and accounting side: this is fixed before start so that edits do not surface in the middle of implementation.
This set is enough to fix the exchange scheme and rollout order — and come back with an estimate and implementation plan.