Setting up 1C:UNF and Bitrix data exchange: where data diverges
Setting up 1C:UNF and Bitrix data exchange almost always passes a test on ten sample products — and diverges on a real order stream.
The issue is not the transmission channel: the catalog, stock, and prices are exported on schedule, while edits in both systems happen simultaneously.
The first gap is reference data matching. If the link relies on a name or SKU, any rebuild of an item in UNF loses the identifier, and a second product is exported to the catalog.
This is how duplicate items appear: two “Oak Tables,” one with live stock, the other with old prices, and the manager does not know which one to edit.
Next is divergence of stock and prices. A manager changes a price in a product card on the site, a warehouse worker writes off a batch in UNF, and both exports start on schedule.
The one that was written last wins, and the intermediate state is not saved — there is no way to restore it: the log shows the result, but not which record overwrote another.
Order export errors are the most costly. An order is placed for a product that has not yet been processed in UNF: the line does not match, the order is created empty or goes to the error list.
Re-exporting items without duplicate protection doubles the lines and writes off stock twice. We explain how this is closed by matching keys and write rules.
What managed synchronization provides: accuracy and speed
The difference between “scheduled export” and managed synchronization shows up at the data level.
The exchange does not run a full snapshot of the catalog, but a delta: 1C:UNF tracks changes to items, prices, and stock movements, and only what actually changed is exported to the site.
Items are matched by internal identifier, not by name, so renaming a product card does not turn into a duplicate, and current stock on the site matches the accounting records.
An order from the site creates a full-fledged document in accounting: composition, prices, warehouse, status, reserve.
Re-sending the same order does not create a second document — the record is tied to the order key, and this removes a class of discrepancies when the connection breaks.
The share of operations requiring manual correction is measured by the exchange log: only non-standard cases are adjusted manually — made-to-order products, special delivery terms.
Order processing time is reduced not by “printing documents faster,” but because manual transfer between order placement and accounting disappears.
The manager receives an order with a ready reserve and a price fixed at the time of placement — price control no longer depends on whether someone managed to update the price list.
Separately, the failure “we sold something that is not in stock” goes away: stock is put into reserve at placement, and scarce items are cut off on the site side before payment confirmation.
We configure exchange scenarios, access separation, and logging — so that these effects rest not on manual discipline, but on a regulation.
Synchronization methods: schedule, event, intermediate layer
The data format is secondary — stability and latency are affected primarily by the transfer method.
Scheduled export runs on a schedule and picks up only what changed since the last successful synchronization; transfer on record change sends the object immediately after posting; the intermediate layer decouples the systems and takes on the queue and retries.
We choose the scheme by three parameters: the volume of reference data and documents, the acceptable lag of the storefront, and the cost of downtime when one of the sides is unavailable.
| Option | When it fits | Limitations |
|---|---|---|
| Scheduled export | Large reference data sets, reports, order history; a lag of tens of minutes is not critical | Peak load on the database at launch time; if one of the nodes goes down, the export is moved to the next cycle |
| Transfer on record change | Stock, order statuses, prices — data awaited on the site immediately | Dependence on receiver availability: without a queue, an exchange failure loses the event; duplicates on re-send must be suppressed by key |
| Intermediate layer | Mixed profile: different systems, volumes, and latency requirements; unstable channel | An additional node to maintain and monitor; the message format is fixed and versioned |
In practice, a combination more often works: reference data is pulled on schedule, documents go by event, and the intermediate layer is enabled when the exchange outgrows a direct connection.
It also provides the main thing for failure resilience — message accumulation and redelivery without manually catching up on exports. Let’s discuss your data profile — we will come back with an estimate and a plan.
Work order: from data review to handover of regulations
We start with an inventory: we list the reference data and documents that actually participate in the exchange — items, counterparties, warehouses, prices, stock — and record the volume, change frequency, and owner of each entity.
Without this map, half of the discrepancies arise not in the channel, but because one product is created in two systems with different attributes.
- Inventory of reference data and flows. We determine what is synchronized, in which direction and how often, and who owns the master record.
- Field mapping rules. We match attributes, mark mandatory ones, and define behavior on divergence: update, skip, or send to a manual review queue. We keep the rules as a table — they can be edited without a developer.
- Exchange channel setup. Accounts with minimal permissions, schedule, batch size, retry on connection loss. We check access on both sides, not only where we configure it.
- Test environment run. A copy of the data, a full cycle, checksum reconciliation, an artificial connection break — we see how the queue behaves and whether the exchange recovers on its own.
- Launch and data transfer log. We enable the scheduled job and monitor the log: how many records passed, how many were rejected, where latency is growing. We set alerts both for errors and for exchange silence.
- Handover of regulations and transition plan. Instructions for typical failures, rollback procedure, a plan for migrating to the new scheme, and employee training.
Deliverables: mapping rules, schemes, and regulations
An exchange setup project ends not with an “everything works” report, but with a set of artifacts by which the work can be verified and then maintained independently. Below is what exactly remains with the customer in the project folder after handover.
- Integration scheme: which data flows go from the accounting system to the site, which come back, at what frequency, and how the exchange behaves when one of the sides is unavailable.
- Attribute mapping table: matching of items, counterparties, prices, warehouses, and units of measure — with notes on which fields are mandatory, which are filled automatically, and which require a manual decision.
- Access policies: which roles see prices, stock, and orders, what is available to a manager, and what is available only to the environment administrator.
- Conflict review log: typical discrepancies — duplicate items, different units of measure, duplicated orders — and the procedure for each case.
- Employee instructions: short “what to do if” scenarios, where to view exchange status, and how to launch a re-export without calling an engineer.
- Maintenance regulation: frequency of checks, monitoring log volume, updating mapping reference data, and the points where specialist intervention is needed.
- Responsibility matrix: who on the customer side accepts changes to mapping rules and approves new fields.
The package lives together with the system: when a product group is added or the price structure changes, an edit is made to it rather than building a new exchange from scratch. This is what distinguishes a maintainable integration from a one-time export.
Case study: how we eliminated stock discrepancies between the warehouse and the site
The client is a wholesale and retail company: accounting in 1C:UNF, storefront and customer portal on Bitrix24.
The exchange ran on schedule, items were matched by name, and stock was exported in full — by midday up to 60 discrepancies had accumulated, and managers reconciled the warehouse with the site manually.
What it was like before reconfiguration
The failure did not appear immediately: the site showed a product as in stock when it had already been taken at the warehouse. A customer placed an order, a manager called and canceled it — up to 14 cancellations per month, about 18% of orders required manual correction.
| Metric | Before reconfiguration | After |
|---|---|---|
| Data transfer time | 35–40 minutes, in batches once an hour | 1–3 minutes, by event |
| Share of manual order corrections | about 18% | less than 2% |
| Cancellations due to lack of stock | up to 14 per month | 1–2 per month |
What we changed
We moved item matching from name to the “SKU + code” pair, and stock began to go by event rather than in a batch once an hour. The export gained retry on connection loss without creating duplicates and an exchange log: you can see which item diverged and when. Product reservation is now set before order confirmation on the site.
After reconfiguration, stock discrepancies stopped being a daily occurrence — incidents are reviewed via the log rather than by recounting the warehouse.
This is exactly the synchronization case where the gain comes not from exchange frequency, but from order in the matching and reservation rules.
When a schedule is enough, and when an intermediate layer is needed
The “schedule or layer” debate is resolved by three measurable parameters: item volume, frequency of stock edits, and number of sales points.
While the catalog is measured in hundreds of items, stock changes several times a day, and there is a single sales channel — a schedule is enough, and it is simpler to maintain: fewer nodes that can fail.
The picture changes when edits arrive every few minutes from several registers and warehouses, and the catalog has tens of thousands of items.
Scheduled exchange begins to get in its own way: the next run starts before the previous one has finished, records overwrite each other, and some changes are lost between passes.
The load on both systems grows linearly with frequency, and during peak hours the export begins to take resources away from order placement.
The intermediate layer — a separate database or queue — decouples the environments: 1C:UNF writes only changes there, and the site picks them up in batches at its own pace.
Each side works at the speed it is designed for, a failure of one environment does not block the second, and redelivery of a package does not create duplicates. At the same time, a log appears: you can see exactly what went out, what was accepted, and where divergence occurred.
The practical sign is simple. If incremental exchange fits within the schedule interval, the queue does not grow, and there are no discrepancies between the catalog and the accounting system — the layer is not needed; it would add a point of failure.
If a growing queue, duplicate items, and complaints about outdated stock appear — this is a signal that the frequency of edits has already outgrown the schedule.
What is clarified before the start: limitations and typical mistakes
At the start, we define how the system behaves under failures: connection loss, partial export, edit conflict — these are not exceptions but standard scenarios. Below are the technical concerns that most often come up with the customer, and our answers to each.
What happens to the exchange when the connection breaks?
The exchange runs in batches, and each batch is confirmed only after being written on the receiving side. If the connection is lost midway, transferred documents are not duplicated, while undelivered ones remain in the queue and go out in the next session. A restart continues from the break point, not from the beginning of the period.
How do you notice partial synchronization, and what about the load?
Each session writes a log: how many objects went out, how many were accepted, where the discrepancy is.
The exchange runs only on changed objects, so the load on the database does not grow with the volume of reference data, and reconciliation by key items puts a discrepancy into a report rather than a manager’s complaint.
Who wins when records conflict?
The conflict resolution rule is defined by entity: orders and payments remain with 1C as the source of truth, while descriptions and content remain with the site.
A disputed document goes into quarantine and does not silently overwrite data, but is brought out for review by both sides.
What about access rights and recovery after handover?
We hand over the subsystem with a description of roles and service accounts: who can see the export, who can restart a session. Recovery after a failure is described step by step — your engineer brings the exchange back up according to the instructions, without our support.
Let’s discuss the synchronization task and come back with a work plan
For the exchange to run without discrepancies, we need to understand your configuration: which reference data is maintained in 1C:UNF, which is on the site side, and who edits it and how often.
Describe the task — we will come back with an estimate, a field mapping scheme, and a work plan where each stage has a readiness criterion.
What will be needed on your side to start:
- Access to environments: test and production 1C:UNF database, site admin panel, exchange server. We do not modify production data until the scheme is approved.
- List of exchange objects: items, prices, stock, orders, counterparties — with direction and frequency for each.
- Owner of reference data: the person who resolves issues with duplicates, groups, units of measure, and SKUs.
- Source-of-truth rules: where the master price and stock are, and how manual edits on the site are handled.
- Data priorities: what is critical first, what moves to the second stage.
- Limitations: the window when the exchange must not interfere with warehouse and operator work.
Next — a test environment run, checksum reconciliation, then production rollout. We state the implementation timeline after the review: it depends on the number of objects and the cleanliness of the reference data, not on the volume of the description.