Setting up 1C:UT 11 and Bitrix exchange: where synchronization breaks
While exchange between 1C:UT 11 and Bitrix is configured correctly, it is not one button but a stream of packets: the accounting system sends items, prices, warehouses, and stock, while the site returns orders and their statuses.
Entity matching relies on unique identifiers and the product code, and the session itself runs on a schedule or by event.
As soon as one step is missed or interrupted, 1C and Bitrix exchange errors begin: managers fix them manually, while discrepancies accumulate with every export.
The most common point of failure is stock desynchronization: an item is sold on the sales floor, but the site keeps offering the last units because the packet stopped midway.
The second most frequent failure is duplicate products: an item is created again if matching keys diverge or the card was edited directly in the admin panel. The catalog swells, prices diverge, site search returns two identical cards, and the customer chooses the wrong one.
A stuck export usually means an interrupted session, a lock on the accounting side, or a timeout on a large packet without retries.
While the task hangs, lost orders do not reach accounting: the customer paid, but there is not a single line in the system — and this surfaces only during reconciliation.
Add manual edits of prices and availability in both systems at once — and the next synchronization will overwrite them. We analyze exactly where the exchange breaks and how these failure points are closed by configuration.
What changes after exchange debugging: effect in numbers
The first measurable shift is the publication cycle.
If previously the catalog export ran on a schedule once an hour and had to be started manually, then after debugging changes reach the storefront within minutes, and stock is recalculated on the change event, not by the next run.
The cost of changes in items or price decreases: the operator no longer waits for an exchange window to see the result.
The second effect is how many manual operations are eliminated. Item matching, price transfer, warehouse linking, and discrepancy resolution stop being daily work: matching rules and auto-completion of reference data cover typical cases, and a person remains only for exceptions.
Instead of dozens of edits per day, only a few resolutions remain — and those for specific items, not the entire array.
The third and most expensive point is up-to-date stock.
The failure class of "sold something that is not in stock" and "item is in stock but hidden from the customer" is closed by reservations and accounting for expected receipts at the time of order, not during reconciliation.
This is no longer storefront cosmetics: a discrepancy between warehouse and site directly hits returns and reputation.
The fourth is synchronization stability. The exchange gets a session log, retries on communication failures, and protection against duplicates: a repeated run does not create second cards or double movements.
Night exchanges run without an operator on duty, and morning reconciliation comes down to viewing a report rather than manually searching for discrepancies.
At acceptance, this is checked with numbers: the share of successful exchange sessions, the time from a change in the accounting system to its appearance on the site, the number of manual edits per week, and the number of items with stock discrepancies.
If at least one indicator does not match the plan, the exchange is not yet debugged — we analyze the cause and bring it to target values.
Methods for synchronizing catalog, stock, and orders
Exchange of catalog, stock, and orders is not one scenario but a set of modes for different change frequencies.
A full product export passes through the entire tree of sections and trade offers, so it is kept for initial filling, structure changes, and bulk edits, not for daily runs.
Then change-based exchange and scheduled exchange work: the first transfers only affected items and quickly covers prices and stock, the second insures against missed events and discrepancies after a node failure. Order exchange runs in the opposite stream — composition, status, reservation flag.
A separate risk area is matching rules, the key place in setting up exchange between 1C:UT 11 and Bitrix.
If the article number is used as the key, and the supplier changes it when rebuilding items, the catalog begins to duplicate; stable matching by external identifier removes this class of errors.
| Option | When it fits | Limitations |
|---|---|---|
| Full product export | Initial filling, changing section structure, bulk edits | Slow on a large catalog, loads the server, not suitable for frequent runs |
| Change-based exchange | Stock, prices, short descriptions — change constantly | Requires reliable change markers and catch-up after failure |
| Scheduled exchange | Regular background: nightly runs, control reconciliations | Between runs, price and stock diverge for hours |
| Event-based exchange | Orders, item receipt, status change | Harder to debug: redelivery of an event must not duplicate an order |
Stages of setting up 1C:UT 11 and Bitrix exchange
The order of work is structured so that each stage ends with a verifiable result.
Exchange between 1C:UT 11 and Bitrix rarely breaks when synchronization is enabled: discrepancies accumulate in reference data matching and export rules and surface on the live catalog when prices and stock diverge from the accounting system.
- Exchange audit. We review current export rules, matching of items, trade offers, warehouses, and counterparties, the exchange log, and typical failures: duplicate items, zeroed stock, "stuck" properties and characteristics.
- Schema design. We determine which data goes out and at what frequency — stock, prices, discounts, characteristics, images — and which system remains master for each entity.
- Setting up export rules. We configure exchange rules, mapping of properties and catalog sections, exception filters for services, sets, and made-to-order items.
- Test synchronization. A full run on a copy of the production database: we compare the number of transferred items, exchange time, and the list of discrepancies before anything reaches the working site.
- Exchange acceptance. We verify control samples for prices, stock, and properties, and check a repeated run — it must not create duplicates or double stock.
- Synchronization support. We configure failure notifications, review logs, and update rules when the catalog changes and new platform releases are issued.
Exchange schemes, export rules, and regulations
Exchange between the accounting system and the site is not a one-time setup but a living circuit: items change, warehouses are added, someone edits attributes manually.
Therefore, along with a working exchange, the customer receives a set of documents that allows it to be supported without us.
- Exchange scheme — a map of flows: which entities go from the accounting system to the site, in which direction, and at what frequency.
- Matching settings — an attribute mapping table and export rules: properties, trade offers, units of measurement, tax rates.
- Synchronization regulations — exchange windows, actions for stock discrepancies, and signs that the export must be stopped.
- Access rules — a separate service user with the minimum required rights, address restrictions, and key rotation procedure.
- Exchange log — where to view session history, how to read typical errors, and how to distinguish an export failure from a problem on the site side.
- Administrator instructions — scenarios for common cases: export failed, prices diverged, order stuck, rollback to previous state.
With such a set, diagnostics take minutes: the administrator opens the log, finds the session, and sees exactly what failed. A new employee learns the exchange from the instructions, not from correspondence with the developer.
Case: catalog and stock on the site without manual edits
Before: exchange "as it happened" and manual reconciliation
A wholesale company with about 12,000 items in the catalog.
The exchange was configured on a leftover basis: item matching was done by name, so any edit in spelling — an extra space, an abbreviation, a case change — produced a duplicate card or an item with zero stock on the storefront.
Catalog reconciliation took the product specialist 3–4 hours per week, not counting the developer's time spent handling complaints that "the site has an old price".
After: matching by code and separated streams
We rebuilt the exchange rules in 1C:UT 11: matching is done by item code and internal identifier, not by name, and stock, prices, and properties are exported in separate streams with different frequencies — the storefront no longer waits for a full packet to update availability.
Every discrepancy goes into the log: an unposted document, an unmatched item, zero stock with an active card.
Metrics before and after: discrepancies decreased from 40–60 items per week to 2–4, accumulated duplicate cards from 180 to zero, manual catalog reconciliation from 3–4 hours to 10 minutes per week.
Two failure classes disappeared: an item is in orders but falls out of the catalog, and the price on the site lives a separate life from the accounting system.
What to do if the exchange is already configured and produces errors?
If the exchange already works but "drifts", the cause is usually not the module itself but a divergence of states: some objects went to the site, some got stuck in the queue, some were overwritten by a counter-change.
Therefore, exchange diagnostics begins not with a full catalog export, but with the change registration log on the 1C:UT side and reception logs on the store side.
The procedure is: find the first packet after which the data diverged, and look at what happened to it — rejected by validation, lost during writing, or processed twice. Then we compare the node settings: entity composition, comparison attributes, deletion handling. "Exchange completed without errors" and "data matched" are not the same thing.
A separate case is a data version conflict: an item, price, or stock changed both in the accounting system and on the site. Here a priority rule and object version storage are needed; otherwise repeated synchronization overwrites content edits with an outdated value.
This is treated by analyzing specific discrepancies and fetching only affected entities, not by "restarting the exchange".
If the storefront must not wait, event-based exchange helps: changes go into the queue immediately after writing, not on a schedule, and an unstable session stops blocking sales.
In this case, a full resynchronization is launched once — when the cause of the discrepancy has already been eliminated.
We start by narrowing the scope: capture queue states, compare reference data, prices, and stock, and only then change settings. Describe the task — we will come back with a diagnostic plan and estimate.
Technical doubts before starting work
The exchange is not designed as "exporting the entire database once a day": 1C:UT 11 sends changed objects in portions, the site confirms receipt, and the next packet leaves only after that.
Most fears are removed by configuration, not by custom development — let's go through four typical doubts.
Will the exchange bring the site down during export?
Portions plus a schedule outside peak hours — response time stays normal, and growth is noticeable only in short windows. We move reindexing and cache reset to a night window, and writing to the catalog goes through a queue.
What about unmatched items?
We match by code and unique identifier, not by name: renaming no longer creates a duplicate card. For new items, we define a rule — create, update, or collect in a report for manual review.
What if communication breaks mid-session?
An unconfirmed packet is not considered accepted and is resent in full. Writing on the site is idempotent: a repeat updates the card rather than creating a second one. By the packet number in the exchange log, the break point is determined precisely.
How to monitor export errors?
To the exchange log we add external monitoring: if a session did not complete within the allotted window or errors come in a row, a notification arrives. Causes are typical — access rights, data structure, required attributes in 1C.
Let's discuss your exchange task: where to start
To come back with a scope estimate rather than general words, we need a snapshot of your circuit: 1C:UT 11 edition, exchange scheme (web services, file exchange, or message queue), item volume, and number of active trade offers.
Separately important is who owns the reference data and how stock discrepancies between the accounting system and the site catalog are currently resolved.
- composition of synchronization entities: items, prices and discounts, stock by warehouse, orders and payment statuses;
- current exchange scheme and its weak points — at which step and how often it breaks;
- export regulations in the accounting system: what runs on a schedule and what runs manually;
- data volume: number of items, share with characteristics and offers, average monthly growth;
- development, test, and production circuits — is there a separate database for debugging and how is it filled;
- access and work window: stand addresses, accounts with minimum rights, when it is permissible to touch the production circuit;
- who on the customer side accepts the result and by what signs considers the exchange correct.
In response, you receive a scope estimate, a stage-by-stage work plan, and a procedure for checking the result: a run on the test circuit, reconciliation of checksums for stock and prices, an exchange log with error analysis, and a rollback scenario to the previous state. Describe the task in free form — we will come back with an estimate and plan.