Setting up 1C-Bitrix import: where the exchange breaks
Catalog and order exchange is not a single export but several independent sessions: products, prices, stock, and orders go in different batches and at different rhythms.
Such a scheme breaks in predictable places, and almost always not at setup time but at scale — when the catalog has exceeded several thousand items and the exchange is launched on schedule on top of the previous one.
The most costly issue is duplicate products during exchange. If the link between the site and the accounting system is based not on the external ID of an item but on the name or SKU, any wording change in the accounting system creates a second product card.
Stock and prices diverge across two entities, and the customer orders something that is no longer in stock.
The second bottleneck is the catalog export timeout. The exchange proceeds step by step, and for large sections a single pass does not fit into the allotted time: some items were updated, some remained in the old version.
Externally this looks like “the catalog updated halfway,” and stock discrepancies on the site are noticed only from customer calls and manual reconciliations.
The third is parallel sessions. While stock is being exported, an order is placed; if the reserve is not taken into account, the site sells an item that has already gone.
Add load here too: exchange during working hours loads the database, slows down product cards, and drags along recalculation of sections and the index.
This is solved not by “restarting the exchange” but by configuration: linking by external code, splitting into batch steps, an export window, and correct handling of reserves. Below we explain how this is arranged in 1C-Bitrix import settings.
What a managed exchange with the accounting system provides
A managed exchange is a set of rules, not a one-time export launch: it is determined in advance which entities are synchronized, at what frequency, and what happens if the connection breaks.
In 1C-Bitrix, such an exchange is assembled from standard mechanisms, but the result rests on the mapping scheme and error handling, not on the mere fact that the 1C Bitrix import setting is enabled.
- Reduced exchange time. Instead of a full catalog run, only changed items and prices are transferred — the exchange fits into the window between exports and does not compete with visitors for site resources.
- Current stock on the site. Warehouse quantities are pulled from the accounting system on a schedule, so an out-of-stock item is not sold and does not require manual card editing.
- Order synchronization with accounting. An order from the site goes into the accounting system, and the status, invoice, and shipment fact come back — the manager does not transfer data manually and does not lose requests.
- Elimination of item duplicates. Matching is done by external ID, not by name: renaming a product no longer creates a second card or breaks sales history.
- Resilience to peak load. The exchange proceeds in batches and resumes from the last processed item — a session break does not leave the catalog in a half-finished state.
Before configuration according to such rules, typical losses look predictable: the exchange runs for hours and does not manage to complete, and after a failure some products remain with old prices.
After — the exchange finishes within the allotted window, stock discrepancies are measured in single items, and incident investigation takes minutes using the exchange log.
Exchange modes: full export, changes, events
The choice of exchange mode is determined not by setup convenience but by catalog size and frequency of edits.
A full catalog export is a continuous pass over products, trade offers, prices, and stock; it is needed for initial population, after a mass restructuring of reference books, or for recovery after a discrepancy.
As a permanent mode, full export quickly hits a limit: the pass takes hours, database load grows proportionally to catalog size, and a connection break means repeating the entire cycle.
Therefore, the working option becomes change-based exchange — selecting only items affected since the previous session — and under peak load the stream is separated through a job queue.
| Exchange scheme | When it fits | Limitations |
|---|---|---|
| Full catalog export | Initial population, changing the structure of reference books, recovery after a discrepancy | Long pass, peak database load, connection failure requires a full repeat |
| Change-based exchange | Catalog from thousands of items, regular edits of prices, stock, descriptions | Reliable timestamps required; a failure may cause a skip, reconciliation mandatory |
| Exchange via job queue | Peak publications, multiple sources, intensive order flow | Harder to support: control of duplicates and message reprocessing |
| Scheduled exchange | Stable flow, predictable load, night window | Delay until the next launch, rigid schedule dependency |
In practice, schemes are combined: full export — on a schedule once a day or week, changes — every few minutes, orders — via a queue.
Separating streams gives a different class of failures: a missed item is caught by checksum reconciliation and the session log, not by manually sorting out duplicates.
Exchange implementation stages: audit, scheme, launch, acceptance
Exchange with 1С rarely breaks in code — more often in mismatched data models: in the accounting system there is one product, in the catalog there are already three, stock is calculated by a warehouse that is not in the export.
Therefore, work proceeds sequentially — from audit to acceptance, and each stage is closed with a verifiable result.
- Audit of the current exchange. We map it out: nodes, session schedule, export volume, which catalog sections are updated, where items are lost, and how duplicates accumulate.
- Field mapping scheme. A table of attribute correspondence: products and trade offers, properties, units of measure, warehouses, prices, and discounts. Linking is by external code, not by name.
- Product export rules. We determine what is published immediately, what goes to the archive, how discontinued items and zero stock are handled — the catalog does not become overgrown with junk.
- Exchange configuration. Batch processing instead of one long session and separate profiles for catalog, prices, and stock — the session does not hit the execution time limit.
- Data integrity check. A run on a catalog copy: we compare the number of items, prices, stock, and image linking before and after the exchange, and review the error log.
- Acceptance and handover. Launch rules, procedure for failure, instructions for the content manager, and a log showing what was updated and when.
The order is fundamental: configuring the export before fixing the field mapping leads to discrepancies surfacing on the live catalog and being edited manually for each item.
What we hand over to your team after implementation
Exchange is not just a working module but the entire package by which your team can launch, check, and, if necessary, stop synchronization without our involvement. Below is a list of artifacts that remain with you after implementation.
- Exchange module in the configuration — which entities are synchronized (catalog, prices, stock, orders), in which direction and at what frequency, and where settings are changed.
- Mapping scheme — a table of field and reference correspondence: what is linked to what, where matching keys are stored, and how to add a new property without breaking existing links.
- Exchange launch rules — sequence of steps, conditions for automatic start, window, and procedure for manual launch after a failure.
- Change rollback procedure — which copy to restore, in what sequence, and what to check in the catalog and orders after returning to the previous state.
- Error troubleshooting instructions — exchange log, typical failures (timeout, code mismatch, duplicate items), and action for each.
- Exchange documentation — data flow map, control points, responsibility zones of your team and ours.
We write the package for your processes, not for an abstract scheme: sections, roles, and entity names are yours. For the first weeks after launch, we troubleshoot errors together with your team; after that, you run the exchange independently.
Case study: catalog and order exchange without interruptions and duplicates
The client is a wholesale company with a catalog of 38 thousand items.
The exchange ran as a single nightly export: 1C-Bitrix did not manage to accept the package in full, the pass broke off in the middle, and the next one started from scratch and re-created already accepted items.
Item duplicates spread across groups, trade offer links broke, and orders reached the accounting system with a delay of almost a day.
What we changed
We split the exchange into batches with a checkpoint after each step — an interrupted pass continues from where it stopped, not from the beginning.
Item matching was switched from name to external code, products and trade offers were separated into distinct passes, and orders received their own export profile and no longer wait for the catalog export to finish.
| Metric | Before | After |
|---|---|---|
| Successful exchange runs | 6 out of 10 | 10 out of 10 |
| Full export time | 4–5 hours, often with a break | 40 minutes without manual intervention |
| Item duplicates | 7% of items | 0 |
| Stable order export | once a day, with a delay | every 15 minutes |
Over a month of observation, the exchange never required a manual restart, and discrepancies between catalogs came down to zero.
How does a full export differ from change-based exchange?
A full exchange pass reads the entire catalog and gives the receiving side every item — both changed and untouched.
Change-based exchange works from a selection: the modification timestamp, an information register with a list of changed objects, or the exchange node log determines what has changed since the previous launch, so transferring only changed products, prices, and stock takes minutes instead of hours.
The cost of a full pass grows linearly with catalog size. A large export holds the connection for tens of minutes, hits the server timeout or script execution time limit, and creates prolonged read load on the accounting system side.
Therefore, a full pass is placed in a low-load window, not in a frequent cycle: running it every few minutes is both pointless and risky.
Change-based exchange has its own weakness — accumulation of data desynchronization. If a record is edited bypassing the standard mechanism, the exchange is interrupted in the middle, or an object falls out of the selection, the item simply will not get into the package.
The error is not visible from the outside: the catalog looks operational, and the discrepancy accumulates until a price or stock starts contradicting accounting.
The practice is a mixed mode. The launch frequency of change-based exchange stays within minutes, while a full pass runs on a schedule, for example once a day at night. On top — control: after each package, the number of items and checksums for the 1C-Bitrix node are compared.
If there is a discrepancy, a full pass starts automatically, and it also covers recovery after a failure.
Technical doubts before connecting exchange
Technical doubts before exchange are usually the same: how import affects site responsiveness, what happens on a break, how partial errors are caught, and who is responsible for operation after handover. Below are short answers for each point.
Does exchange bring the site down under load?
Import proceeds in batches, not as one long transaction, so between batches the site continues serving visitors. Stock and trade offer recalculation is moved to a separate queue and launched outside peak hours. No read locks on the catalog occur.
What happens if the connection breaks?
The session records the stopping point — the number of the last accepted batch. The next launch continues from it, rather than uploading the catalog anew, so duplicates do not appear. An incomplete session is marked, and a new one does not start until the previous one is processed.
How are partial errors caught?
Each batch is written separately: a failure in one element does not roll back the others but goes into the log with the object's external code and cause. Usually this is a reference mismatch, an invalid field, or a duplicate by code. Reconciliation after the exchange shows how many items diverged.
What changes after project handover?
We hand over exchange logs, the field mapping scheme, agent settings, and the procedure for actions on discrepancies — support does not begin with sorting out someone else's logic. The catalog state is checked by reconciliation and logs, without calling a developer.
What to clarify before starting: let's discuss your scheme
To come back with an estimate of the scope of work and an exchange plan, rather than with clarifying questions, we need a minimum of inputs on the catalog and accounting system.
Gather what you already know: if half the data is not at hand, that's fine — we'll figure it out together.
- Catalog size: how many items and trade offers, how deep the section hierarchy is, how many properties and images each product has.
- Matching rule: by what attribute an item on the site is linked to a product — external code, SKU, or a combination of fields.
- What already works: standard exchange module, custom handler, or manual upload, and which data exactly is transferred.
- Data composition: price types, warehouses and stock, one legal entity or several, whether characteristics and units of measure are needed.
- Frequency: full export at night, regular change-based exchange, or event-triggered launch, how many items change per day.
- Server limitations: execution time limit, available memory, low-traffic window when exchange does not interfere with customers.
- Current failures: timeouts, duplicate items, price and stock discrepancies — what exactly breaks and how often.
- Who on your side confirms the mapping rules and provides access to the test environment.
This is enough to discuss the exchange task substantively and come back with an estimate and exchange work plan: stages, sequence, checkpoints on a catalog copy.