Setting up scheduled exchange in 1C-Bitrix: where it breaks
Setting up scheduled exchange in 1C-Bitrix goes smoothly on a test environment and falls apart in the second week of operation. The task is listed as active, but in fact manual exchange launch works — "when the manager remembers".
No one notices the missed window: the storefront sells at old prices, and this comes to light from a customer's call.
A scheduled catalog export with photos and properties takes longer than the pause between runs. The next session starts on top of an unfinished one: two sessions write to the same information blocks, duplicates of items and broken trade offer links appear.
This is fixed not by increasing the interval, but by batch export and preventing re-entry via a lock flag.
A separate point of failure is desynchronization of stock levels and prices.
Prices come by one rule, warehouse quantities by another, and the storefront shows a combination that does not exist in accounting: a product with a price and zero stock or available for order with the warehouse disabled.
The customer places an order, the manager cancels it — trust in the catalog falls faster than it can update.
A silent failure is more dangerous than an explicit error: the 1C exchange with the site does not crash, it simply stops delivering data.
Next we'll look at how this is closed — an exchange log with timestamps for each object, repeatable batches, and rollback to the last consistent state.
What regular synchronization of site and accounting data gives
Regular catalog synchronization removes a class of failures that is almost invisible in reports but costs more than the others: current prices on the site cease to be a guarantee.
While exchange is launched manually, a gap of hours accumulates between export from accounting and publication on the storefront, and the customer places an order at a price that no longer exists, while the manager sorts out the discrepancy manually.
The schedule removes the human factor. The exchange agent in 1C-Bitrix is launched by the scheduler, not on request, and each run goes in portions — by item sections, with a timestamp of the last successful synchronization.
Therefore, the completeness of product export does not depend on whether the operator waited for the task to finish.
Overlapping launches are a quiet source of desynchronization. If the scheduler starts a new exchange while the previous one is still writing sections, some items remain without prices, and duplicates appear in the catalog.
The lock flag and queue guarantee that the second launch waits for the first or is skipped, rather than starting on top.
The exchange log makes failures analyzable: for each record you can see the error code and text, time, direction, and export object. Only failed items are re-run, not the entire catalog, so the next cycle does not stretch overnight.
At the same time, the storefront maintains response speed — synchronization proceeds incrementally, and a full re-export remains an emergency tool, not a daily procedure.
Options for automatic launch: comparison of approaches
Automatic exchange launch can be assembled in three ways, and the choice between them is not by convenience, but by who owns the schedule and what happens on failure.
The internal timer runs within the site's environment, the external scheduler runs on the server side, and the job queue separates scheduling from execution.
| Option | When it fits | Limitations |
|---|---|---|
| Timer-based launch inside the system | Small catalog, exchange every 15–60 minutes, no access to the system scheduler | The interval is tied to traffic: at night runs shift, a long exchange competes with page delivery |
| Exchange job queue | Regular exports of items, prices, and stock levels, retries and error analysis are needed | Requires monitoring queue depth: when it lags, jobs accumulate, and exchange starts catching up with itself |
| External scheduler | Strict schedule and a fixed exchange window independent of site load | The schedule lives outside the system: changes are not visible in the site interface, return codes need monitoring |
In practice, a hybrid works more often: the external scheduler creates a job, the queue executes it, and the timer inside remains as a safety net if the regulation did not run.
Separately, we compare the synchronization interval with scheduled tasks on the accounting system side — overlapping two exchanges produces item duplicates and lock conflicts.
Setting up scheduled exchange in 1C-Bitrix: work order
The work order is the same for both sides of the exchange and does not depend on how many catalogs, prices, and warehouses are involved.
First we capture the current state, then we fix the data mapping, and only after that we set the schedule — otherwise the schedule starts exchange with unverified logic, and discrepancies surface on the live site.
- Audit of 1C exports. We look at what goes to the site now: reference books, volume, launch frequency, where the exchange fails or runs partially. We record bottlenecks — heavy sections, duplicates, items without stock.
- Field mapping map. We match 1C attributes with catalog fields: sections, properties, trade offers, prices, warehouses. The table is agreed with the client — every export is later checked against it.
- Setting up the exchange schedule. We split the cycle into independent steps (items, prices, stock levels), set intervals and windows, protect against overlapping launches, and allocate a separate exchange user with minimal permissions.
- Test exchange environment. We deploy a copy of the site and database, run a full cycle and a repeated launch: data is not duplicated, a partial failure does not break the catalog.
- Handover of the schedule. We provide instructions — schedule, control points, procedure for an error, and rollback of a failed export. Here we also set up failure notifications so the problem does not live until a manager's call.
After the schedule is handed over, exchange proceeds without manual launches, and any deviation is visible in the log and notifications.
Export profiles, logs, and documentation: what we hand over
The result of setup is not only a working exchange, but also a set of artifacts by which it can be maintained, extended, and handed to another team.
Everything is recorded in the project repository and tied to specific nodes and configuration, so that after a change in items or price types, the logic does not have to be restored from memory.
- Export profiles for products and trade offers: which catalog sections, properties, and warehouses go into the exchange, with which filters by activity and stock levels.
- Price recalculation rules: priority of price types, order of markups, rounding, and behavior at zero stock — with calculation examples on real items.
- Data flow diagram: which objects go from 1C to the site, what comes back (orders, payment statuses, stock levels), exchange nodes, and points where data changes.
- Exchange schedule: launch intervals, windows for full export, order of additional loading after downtime, retry settings when the service is unavailable.
- Exchange logs: unified record format, separation by importance levels, retention period, and quick access to the last failed batch.
- On-duty shift regulations: what is checked in the morning, by what signs a stuck exchange is identified, and what actions are allowed without a developer.
- Instructions: manual export launch, batch reprocessing, disabling exchange during catalog edits, recovery after failure.
- Acceptance checklist: reference items by which the client independently verifies prices, stock levels, and order statuses after each revision.
Case: how price and stock desynchronization on the storefront was eliminated
The catalog on the storefront diverged from the accounting system: prices and stock levels were updated only when exchange was launched manually.
Managers launched it several times a day — up to 40 launches per week — and still some items sold at a price that no longer existed in the item list, while a product with zero stock continued to accept orders.
We analyzed the exchange on the 1C-Bitrix side: the full cycle took 55 minutes and ran entirely, even if three items had changed. We switched to a delta by hash sums and set a scheduled task with a 10-minute step, while leaving the full export for a night window.
Dynamics across three metrics
| Metric | Before | After |
|---|---|---|
| Share of price and stock discrepancies | 7% of items | 0.3% |
| Full export time | 55 minutes | 12 minutes |
| Manual exchange launches per week | up to 40 | 0 |
The delta calculates the hash of each item and transmits only changed ones — hence the multiple reduction in synchronization time. Each step is written to the log with the number of updated items, so data quality control no longer depends on who launched it and when.
A failure on one item does not bring down the entire exchange: the batch is marked and repeated by the next launch, and a timeout retry picks up what did not manage to pass within the window. A price conflict is visible in the report before publication on the storefront.
How a timer-based task differs from an external scheduler
Both mechanisms launch the same exchange script, but they differ in behavior when something breaks. A timer-based task in 1C-Bitrix is tied to a request to the site: no visitors — no launch, and during a traffic spike several requests can start the same exchange in parallel.
An external job scheduler starts by system schedule regardless of attendance, so the night export goes out on time even on empty traffic.
Overlapping launches are the second point of divergence. The timer does not know that the previous run is still in progress: until the catalog export finishes, the next one starts on top and adds load on the database and repeated writes.
The external scheduler takes a lock — a flag file or a row in a service table — and the second process simply does not start.
Exchange incident analysis rests on the log. For a timer-based task, events are spread across a common feed and lose their connection to a specific run, so the question "how many rows arrived and what did it fail on" turns into archaeology.
The external scheduler writes a separate log and return code, and a repeated launch after failure is configured explicitly: delay, attempt limit, notification to the responsible person.
In practice, scheduled exchange with 1C is kept on an external schedule, while the timer is left for light service tasks. If exchange already works on a timer, migration comes down to moving the launch and adding a lock — the script itself does not need to be changed.
Common doubts: failures, retries, and data duplicates
Most "exchange broke" requests describe not a failure but an unfinished batch: part of the item list updated, part remained at previous prices.
Exchange proceeds by external identifiers and is written to the log, so the state is restored by a repeated run, not by manually rebuilding the catalog.
What happens if the export is interrupted midway?
The batch is not considered applied: the next scheduled session continues from the last processed identifier, not from the beginning. The retry is idempotent — records are updated by item code, no new ones appear.
Why do product duplicates appear on the site during exchange?
The cause is almost always the same: the item in 1C has no external code filled in, and the exchange cannot match it with an existing card — it creates a second one.
This is fixed by setting up matching and a one-time reconciliation, after which duplicates collapse into one product.
How can you see that only part was exported?
By the exchange log and reconciliation report: we compare the number of active items, catch zero prices, negative stock levels, and records without an identifier.
Discrepancies go into a resolution queue with the object specified, rather than being looked for by eye across the catalog.
Who is responsible for the correctness of prices and stock levels on the site?
The source of truth is the accounting system; the site only displays its state within the exchange schedule. We fix areas of responsibility in a document: what is corrected in 1C, what may be changed in the card on the site side, what is synchronized in one direction.
Can a failed exchange be rolled back?
Yes: before major changes we take a catalog snapshot, so returning to the previous state is restoring the snapshot plus a repeated run. We correct point errors with a scheduled export of the required groups, without touching the rest of the catalog.
Let's discuss the task: we'll assemble the scheme and come back with an estimate
To make the conversation substantive and the estimate accurate, it is worth gathering several inputs for the discussion. Nothing rare is needed: all of this is usually already available from the site administrator or from the specialist who maintains the accounting system.
- List of platforms. A list of sites and 1C databases involved in the exchange: one storefront or several, a separate database for wholesale and retail, a test environment for verification.
- Data map. What is transferred and in which direction: items, prices, stock levels — to the site; orders and payment statuses — back; plus fields that are changed manually.
- Accesses. An account for exchange with permissions to read exports and write to the catalog, access to the site admin panel, to the application server, and to the job schedule.
- Person responsible for reference data. The person who resolves issues with duplicates, codes, units of measurement, and groups. Without them, discrepancies in the item list will surface after launch.
- Work window. The period when the scheme can be changed and exchange restarted: night hours, weekends, a pause in order acceptance.
- Current mode and frequency. How exchange runs now — manually, by button, by event — and how quickly changes should reach the site.
With this set, we will remove uncertainty in one conversation: verify the scheme, propose a schedule, estimate the scope and order of work, and name the risks for each node. Describe the task — we will come back with an estimate and a plan.