Why 1C and Bitrix order statuses diverge
An order is stuck in processing: the customer sees “Paid” and waits for shipment, the manager in the accounting system sees “Awaiting confirmation,” and the warehouse never received the task at all.
A day later it turns out the customer was twice told “we’ll ship tomorrow,” and the conversation has to start over.
There are usually three causes of divergence. An exchange break: the event queue stalled in the middle of a batch, the repeated upload started from the wrong point — and some orders remained in the old state.
Manual edits: a manager changes the status directly in the 1C-Bitrix admin panel without touching the accounting system, and the next order status synchronization overwrites the change or creates a version conflict.
The third cause is different state dictionaries. In accounting, a status is a stage of the document’s business process; on the website, it is a short order flag.
There is no one-to-one correspondence: one state “in production” on the website corresponds to several stages in accounting, and the reverse conversion loses data.
That is why 1C and website exchange is built on an explicit state mapping table and idempotent event processing — without this, any delivery failure again puts the parties into different statuses. We explain how this is closed.
What changes after configuring the exchange: the effect in numbers
After enabling end-to-end state exchange, the first thing that drops is the share of orders that someone edits manually. Previously, a manager reconciled payment and shipment using uploads — now the status comes from the accounting system and is set automatically.
On a typical flow of several hundred orders per month, the share of manual edits goes from tens of percent to single digits, and the edit itself stops being a mandatory step in processing.
The second measurable result is the time until the current state appears.
The exchange runs by events, not on an hourly schedule: a change in the accounting system initiates transmission, and in the customer interface the status updates within seconds to minutes, not by the next cycle.
This directly shortens order processing time — the customer learns earlier about readiness for shipment, payment, or cancellation and does not call to clarify.
The third metric is support requests on the topic “what is my status?” When the state is pulled through the entire chain and backed by order change history, the customer and manager see the same picture: who and when moved the order, from which state and on what basis. The argument “you said it was paid” stops reaching the first line.
The fourth result is the classes of failures that disappear. Divergences due to lost messages during a communication break, duplicate statuses during retransmission, and “stuck” orders that do not move because of an error in one dictionary go away.
The reduction in manual reconciliations is a direct consequence: there is nothing to reconcile because divergence has nowhere to arise.
The fifth is manageability. Every failure is recorded in the exchange log, and instead of investigating “what went wrong,” the team sees which event did not arrive and why. Then comes diagnostics from logs and reprocessing, without manual recalculation.
Data exchange methods: comparison of approaches and limitations
While an order in 1C has been moved to “Shipped,” in the customer account the buyer sees “Processing”: the manager gets a call, the warehouse gets a repeat request, support finds out who is right.
The cause is usually not a code error but the chosen exchange method — each has its own delay, its own class of failures, and its own access requirements.
Comparison of options
| Option | When it fits | Limitations |
|---|---|---|
| Batch exchange | Order flow is even, a delay of tens of minutes is acceptable | Delay equals the launch interval; on failure the window is lost, and during peaks processing time grows |
| Event-driven upload | The status is needed by the buyer immediately after a change in 1C | Handlers on the 1C side and a queue with retries are required: if the receiver is unavailable, events must not be lost |
| Direct database access | Own system, configuration updates under control | Reading someone else's schema breaks on update, and writing bypassing business logic and locks is dangerous |
| Intermediary service | Multiple sales channels and systems, a single status log is needed | Another component appears: without control it becomes a point of failure itself |
| Manual upload import | One-time reconciliations and rare orders | Depends on a person, does not scale, statuses become outdated between uploads |
The choice is determined by three questions: how many statuses change per day, what delay is critical for the business, and what access between systems are you ready to open.
In practice, order statuses are handled by event-driven upload, while reconciliation of stock and closing documents is handled by batch exchange on a schedule.
Implementation stages: from exchange audit to handover to support
Status exchange breaks not in the code but in the agreements: in the accounting system an order lives in one state, on the website in another, and no one remembers who moves it and when.
That is why we work sequentially and record the result after each step — this way, at acceptance it is clear what exactly was checked and on what data.
- Exchange audit. We review current scenarios, exchange logs, and failure frequency: which documents already go to the website and which are only planned.
- Status mapping. We bring the accounting system states and 1C-Bitrix into one table: which code transitions to which order status, which transitions are prohibited.
- Exchange scheme and rollback regulations. We fix the direction and frequency of upload, behavior when a party is unavailable — queue, retry, manual review — and the procedure for returning to the previous state.
- Configuration and debugging. We implement the exchange and write logs with the order identifier: on failure it is clear at which step it stopped.
- Testing on a test environment. We run scenarios on a copy: payment, partial shipment, cancellation, return, repeated sending of one document. We compare statuses on the website and in the accounting system.
- Acceptance of work. We go through the list of scenarios together with your specialist and measure the time it takes for a status to go from the document to the website.
- Handover to support. We provide the status map, exchange scheme, manual review instructions, and an entry point for requests.
What the customer receives: schemes, rules, regulations
After the exchange is launched, the customer is left not with a set of settings in the admin panel but with a set of artifacts by which the work can be handed over to another team without digging into code.
Each document covers its own class of questions: how 1C and Bitrix order statuses are mapped, who has access to the exchange, how to check that the transfer worked, and where to look during a failure. Below is the list of what is included in the handover.
- Status mapping — a table “order state in the accounting system → status in Bitrix,” including states without a direct equivalent: partial payment, cancellation after shipment, return. For disputed pairs, a conflict resolution rule is specified.
- Exchange settings — which entities are synchronized (orders, items, payments, shipments), at what frequency, how divergences are resolved, and how to manually pull missing records.
- Access policies — under which accounts the exchange runs, what rights they are granted, what to do when the service user or password changes.
- Exchange log — where events are written, what is recorded (direction, entity, result), how long it is stored, how to export a slice for a period for review.
- Exchange documentation — integration points, formats and frequency of transfer, responsible parties on the accounting system side and on the website side.
- First-line support instructions — typical situations (“order stuck,” “status did not arrive,” “a duplicate appeared”), the procedure, and the boundary beyond which engineers are involved.
- Change regulations — what to do when adding a new status: who approves it, where the mapping is edited, how the result is checked before rollout to the production environment.
Case study: how a store stopped losing payment confirmations
Before the project, the store on 1C-Bitrix reconciled payments with the accounting system manually: a manager exported a register and set order statuses.
The upload ran on a schedule once every few hours, so payment confirmation reached the order with a delay — the warehouse managed to ship goods against an unconfirmed payment.
The share of orders edited manually reached one third, and divergences were found during reconciliation, after the fact.
The exchange was moved to an event-driven model: a change in a document status in 1C sends an event to the queue, the handler matches it to the order and updates the state.
Each event carries an idempotency key — repeated delivery does not double transitions, and a break in the middle does not leave the order in an intermediate state.
A backup scheduled pass every 15 minutes picks up what did not arrive and puts divergences into a separate review log.
The status map is described explicitly: for states without a direct match, transition rules and a ban on shipment before payment confirmation were introduced. Input errors decreased for a specific reason — the manager no longer selects the status manually.
Metrics before and after
Status divergences — from 9% of orders to 0.3%, share of orders with manual edits — from 34% to 4%, time to state actualization — from 3–4 hours to tens of seconds.
The failure class “shipment without confirmed payment” is fully closed, and support requests about statuses decreased sixfold.
What to do if the exchange is already configured but data diverges
The divergence is almost never in the exchange itself — it reliably delivers what it was given. The event is lost earlier: a document was posted without a status change, a manager corrected an order in 1C with batch processing, and the handler did not pick up the event.
Therefore, we start diagnostics not with the exchange code but with the log: what was actually uploaded, what was received on the website side, and which records exist in one system but are absent in the other.
Next we check the delivery method. Exchange through a queue survives a failure and provides reprocessing with a clear log, but it requires reviewing stuck messages.
Direct database writes are faster and simpler at the start, but they bypass business logic: the status in the card changes, while the email to the customer, delivery recalculation, and other triggers remain silent. During the next session such a value is overwritten — and the divergence returns.
Duplicates are the second most frequent cause.
Reprocessing one message after a communication break or a manual upload restart applies the status twice, and the order rolls back: the customer sees “assembling” after “handed to courier.” It is treated with idempotent operations — each transition has a key made of the order number, status code, and record version, and the receiver applies it only if the version is newer than the current one.
The support for both problems is transition history instead of a single current value. It shows at which step the event was lost, and only the missing segment needs to be restored, not the entire chain.
Partial reprocessing without stopping the process looks like this: the exchange continues to run, missed events are uploaded pointwise from the log, then a one-time reconciliation of totals.
A full reload of history on a live environment almost always means repeated emails to customers and new divergences. Describe your exchange scheme — we will come back with an assessment of where exactly the event is lost and how to close this without downtime.
Common concerns: duplicates, rollbacks, access, communication failures
Status exchange is not a single “synchronize” button but an event queue with a log and retries.
That is why we resolve technical concerns before the start: the answers determine which fields will become the key for matching orders and how the system will behave in an emergency scenario.
Will duplicate orders appear?
No: each exchange record is marked with a key made of the order number and state version, so repeated delivery of the same event is recognized and discarded. If an order changed several times in a row, the latest version is applied — intermediate ones do not create copies.
What happens during a communication failure?
Events are not lost: they remain in the queue and are applied as soon as the channel returns. Processing continues from the last confirmed log position, so the exchange does not start over and does not rewrite already applied order statuses.
What is dangerous about partial synchronization?
The log shows which orders were updated and which were not, and the rerun goes only through unclosed positions. The divergence does not grow: the next exchange cycle closes the remainder if it is already recorded in the accounting system.
What access is needed to the accounting system?
A separate service user with minimal rights: reading orders and writing statuses, without access to settings and restricted sections. New order states are added to the mapping dictionary — matching rules are extended without rewriting the exchange.
Let's discuss the task: we'll analyze the exchange scheme and propose a plan
For the conversation to be to the point, we need a snapshot of the current exchange. Send the status map from 1C and their mapping to order states on the website, the list of objects involved in the upload, and the settings by which the exchange is launched.
Separately clarify which side is considered the master in case of divergence: if the status changes from two sides, the order easily moves into an incorrect state.
The exchange log for the period when divergences were noticeable is also useful — it shows whether events are lost or arrive with a delay, and how partial shipments, cancellations, and returns are processed. This is enough to estimate the scope of work and not overplan.
In response you receive:
- an analysis of the current scheme: at which step the event is lost and why the status on the website arrives later than in the accounting system;
- a list of clarifications on disputed points — the master system, cancellation and return rules, manual operator edits;
- an estimate of the scope of work broken down by stages and launch order;
- an implementation plan: what we close first, what can be postponed without risk to orders;
- an exchange support regulation: how errors are tracked and what we do during desynchronization;
- documentation on the final scheme and instructions for operators.
Describe the task — we will come back with an estimate, an implementation plan, and a proposal for exchange support.