Why 1C UT stock export to Bitrix breaks at warehouses
Most often, 1C UT stock export to Bitrix breaks not at the "no connection" stage, but in the warehouse matching logic. In UT, a warehouse is a separate register with its own analytics, while in an online store's catalog it corresponds to one or two shipping warehouses.
If the mapping is set "by eye," the 1C and Bitrix exchange formally succeeds, but the stock discrepancy across warehouses accumulates with every document: the item is recorded at the wholesale warehouse, while the website sells it from the retail one.
The second typical failure is stuck exchange queues. A full export is launched on a schedule, but during a mass movement of documents the session does not manage to close before the next start.
A new batch of changes queues up behind the old one, and the freshness of stock on the storefront begins to lag by hours. Externally, this looks like "the item is there, but it isn't": the customer places an order, and the picker cannot find the item.
The third cause is duplicate reserves at the warehouse. A reserve released in 1C upon shipment is not always released in Bitrix, and vice versa: an order canceled on the website leaves the item in reserve in the accounting system.
The stock is "eaten up" twice, the quantity available for sale drops, even though the item is physically sitting on the shelf.
It is this class of failures that hits sales the hardest — the storefront shows zeros for fast-moving items, while the manager sees a full rack.
Separately, there is the time desynchronization: if the exchange runs only on a schedule, between sessions the website sells outdated data. We break down how this is closed — from warehouse matching and separating full and quick export to reserve release rules and queue control.
What correct exchange of stock and reserves delivers
A correct stock exchange is not about "the numbers matching" — it is about predictable storefront behavior at peak load.
When stock across warehouses reaches Bitrix with a delay, a customer places an order for an item that is already gone, and the manager only finds out during picking.
Every such cancellation means a refund, back-and-forth messages, and a lost customer who goes to a competitor that has real availability.
The speed of stock updates is determined not by how often the exchange runs, but by its architecture: incremental export of changes instead of a full catalog rebuild, an event queue, and splitting streams by warehouse.
In practice, this moves the storefront from a "data an hour old" mode into a "freshness within minutes" mode — the share of cancellations due to out-of-stock items drops severalfold, not by a few percentage points.
The accuracy of reserves matters more than the export itself: stock without accounting for what is reserved for orders and shipments produces false availability.
When the reserve from 1C:UT is synchronized with the cart and placed orders, the customer sees exactly the quantity the warehouse can actually ship, and does not get a rejection after payment.
The load on the warehouse is also a controllable parameter. If the exchange pings 1C on every card view, the database degrades during peak hours, and pickers work with outdated tasks.
Distributing the exchange across a schedule and caching availability on the site's side removes unnecessary calls and balances the load between the storefront and the accounting system.
Finally, the class of failures. A properly built exchange survives 1C or site downtime without data loss: changes accumulate in a queue and catch up when connectivity is restored, rather than being silently lost.
This is exactly what distinguishes a working integration from one that "sometimes diverges" — and this is where you can see how deeply the scenario has been thought through.
Synchronization methods: exchange by schedule, events, and request
The exchange mode determines how quickly stock on the storefront catches up with the warehouse and how much load this creates on both systems.
In practice, you choose between three schemes — by schedule, by events, and by request — and often combine them: heavy full exports at night, point changes during the day.
Comparison of modes
| Mode | When it fits | Limitations |
|---|---|---|
| By schedule | Catalog and stock change predictably; simple maintenance is needed | Update delay equals the interval: between runs the storefront shows outdated data |
| By events | Sales and receipts come in a stream; stock freshness matters | Requires a queue and failure handling; during an event storm the load on the server grows |
| By request | Rare categories, on-demand checks, manual recalculation | Each request is a synchronous call to 1C: with frequent calls the database responds slowly |
What to consider when choosing
Exchange by schedule provides a predictable load: you set the window, the batch size, and the export order, and the 1C server does not get spikes during peak hours.
Event-driven exchange reduces the update delay to seconds, but requires idempotent processing — repeated delivery of the same change must not double the stock.
Exchange by request is convenient as a supplement: it does not hold a permanent channel, but with frequent calls it becomes a bottleneck. We usually build a hybrid — events for operational warehouses, schedule for reference data, request for reconciliation. We'll walk through how this is configured for your environment.
How we set up 1C UT stock export to Bitrix
We start with an audit of the warehouse directory in 1C:UT and the catalog structure on the website side. At this step we determine which warehouses actually participate in sales, where there are duplicate names, and how sales points are currently mapped.
Without this, any exchange setup produces stock "in the air" — the item is on the books, but not at the warehouse it is going to be shipped from.
- Audit of warehouses and sales points. We reconcile the directories on both sides, flag the warehouses that should not appear on the storefront (defective goods, transit, consignment storage), and record the list of active ones.
- Warehouse mapping scheme. We build a mapping table: warehouse GUID in 1C, warehouse ID on the website, publication flag, priority for aggregation. The warehouse mapping scheme is a document that any discrepancy is later corrected against, rather than "a setting in the interface that nobody remembers".
- Exchange setup. We define the direction and frequency: a full export during the initial synchronization, then changes only. We configure filtering by organizations and warehouses so that stock belonging to other legal entities does not go to the website.
- Reserve verification. We separately work through reserves and expected receipts: what to show the customer — free stock or stock including the reserve. This is where discrepancies between "available to order" and "in stock" most often surface.
- Test run. We reconcile the export against a control sample of items: 1C → website and back, and check the behavior with zero stock and when a new warehouse appears.
- Update regulations. We set up the exchange schedule and error-handling rules: what to do if a session did not complete, how to load missed changes without manually re-uploading the catalog.
- Handover and training. We hand over the mapping scheme, the regulations, and instructions for adding a new warehouse — so that edits do not require calling in a developer.
After the handover, the exchange runs on schedule, and changes to the warehouse directory are made according to a documented rule.
What you keep after setting up the exchange
Setting up the exchange is not just a working channel between 1C:UT and Bitrix. To keep stock balances by warehouse from drifting apart a month later, after handover a set of artifacts remains, by which the system can be maintained without us.
- Export rules — which warehouses, item groups, and stock types go to the site, at what frequency, and with what priority when data conflicts. The rules are described in text, not just "configured in the module."
- Warehouse mapping — a mapping table of 1C warehouses and warehouses/availability zones on the site, including those deliberately excluded from the exchange. Separately — rules for retail locations and temporary storage warehouses.
- Exchange log — where to see what was exported and when, which items were rejected and why. With filters by warehouse and period, so that incident investigation takes minutes, not hours.
- Update regulations — session schedule, manual launch procedure, behavior when one of the systems is unavailable, and rules for reloading missed data.
- Administrator instructions — step-by-step actions for typical situations: stock balance not updated, warehouse disappeared, exchange stopped after a configuration update.
- Data flow diagram — from the receipt document in 1C to the product card on the site, with control points at each step.
- Acceptance checklist — a set of checks by which you can verify for yourself that the exchange works: control items, boundary warehouses, behavior at zero stock.
We hand over the set in your task-tracking system and as a document alongside the project. After that, the exchange is maintained by your administrator according to the instructions, and we step in when the warehouse structure or sales logic changes.
Case study: how stock balance exchange stopped slowing down sales
The client is a network of several warehouses, selling through a website on 1C-Bitrix and retail outlets.
Stock balances in 1C:UT were updated to the storefront once every few hours, and some items did not make it into the exchange at all due to discrepancies in the item master data.
Managers manually corrected availability before confirming an order, and customers were ordering items that were no longer in the warehouse.
What it was like before
The share of cancellations due to "out of stock" stayed at around 12% of confirmed orders. The delay in stock balance updates reached 3-4 hours on peak days, and warehouse workers spent 1.5-2 hours per shift on reconciliation and manual edits in product cards.
Stock balance errors accumulated: the website showed availability, but the warehouse did not confirm it.
What was changed
The exchange was rebuilt: instead of a full catalog export on a schedule, an incremental exchange by changed items was set up, the item master data was linked to a single reference catalog, and a resend queue was added for items that failed due to discrepancies.
The exchange runs on stock balance change events rather than on a timer — the storefront receives up-to-date data within a few minutes.
What the result was
The share of cancellations due to out-of-stock items dropped to 2-3%. The delay in stock balance updates was reduced from hours to minutes, and manual edits in product cards almost disappeared — warehouse workers stopped reconciling availability by hand.
The warehouse workload during peak hours leveled out: orders come in only for what is actually on the shelf, and the picking flow has become predictable.
How stock export by warehouse differs from general nomenclature exchange
General nomenclature exchange and stock export by warehouse solve different tasks and operate at different frequencies. The former synchronizes the catalog: names, SKUs, properties, prices, and assignment to catalog sections.
It changes rarely — a new item appeared, characteristics were updated — so the exchange runs on a schedule or by event and can easily tolerate a delay of hours.
Stock by warehouse is operational data: it describes how much of a product is physically sitting in a specific warehouse right now, and it goes stale within minutes.
The difference in data granularity is fundamental. General exchange operates on a product as a whole: the item is either in the catalog or it isn't.
Stock export by warehouse breaks that same item down to the warehouse level — retail floor, online warehouse, partner warehouse, in transit.
The same nomenclature can be in stock at one warehouse and at zero at another, and the site must show this honestly, otherwise the customer places an order for a product that isn't nearby.
Hence the different exchange frequency. The catalog can be pulled once a day, stock — every few minutes, and during active promotions and peak hours more often.
If you push stock through the same heavy exchange as nomenclature, the load on 1C and the site grows, and the data still arrives with a delay. That's why stock is exported in a lightweight stream: only the warehouse key, the product key, and the quantity.
The main consequence is the impact on product availability and reserves. As long as the stock on the site doesn't match the real one, the customer sees "in stock" where it's empty, or conversely loses a sale on an item that's sitting in the warehouse.
A reserve placed on the site must go to 1C and reduce the available quantity, otherwise two channels will sell the same product.
It is precisely the combination of "granularity by warehouse + frequent export + reverse reserve" that turns the catalog into a reliable source of availability rather than a decoration.
Common technical concerns about stock balance exchange
Stock balance exchange rarely breaks "for good" — more often it degrades gradually: export time grows, discrepancies across warehouses appear, and managers stop trusting the numbers on the storefront.
Below are the technical concerns that most often come up before launch, and how we address them at the level of the exchange architecture.
Will the server handle regular stock balance export across all warehouses?
The load depends not on the size of the catalog, but on the frequency and granularity of the exchange. We export not the entire array, but only the changed items for each warehouse — via delta exchange by attributes and registers.
Full synchronization runs on a schedule during night windows, while incremental synchronization proceeds in short packets. The server does not experience peaks, and the data on the storefront is updated more frequently.
Where do duplicate stock balances come from and how can they be avoided?
Duplicates appear when the same item is written by two sources: exchange from 1C and manual editing in the admin panel, or when the item matching key is misconfigured. We establish a single source of truth — 1C:UT, and on the website side we leave read-only access.
Matching is done by external code, not by name, so renaming a product does not create a second card.
How are reserves accounted for and will they diverge from the actual warehouse?
A reserve is a separate register, and it must not be mixed with free stock balance. We transmit two independent values: physical stock balance and reserved quantity, while the website calculates the available-for-sale amount itself.
This way, an order placed on the storefront immediately reduces the available number, but does not distort warehouse accounting in 1C.
What happens during an exchange failure — is data lost?
The exchange is transactional and logged: if a packet fails, it is marked as incomplete and retried rather than skipped. We configure automatic restart and notification of the responsible person, so a channel failure does not turn into a silent discrepancy. Recovery is reloading the missing packets, not manually reconciling the entire catalog.
If questions remain regarding your warehouse configuration and reservation rules — describe the task, and we will return with an estimate and an exchange plan.
Let's discuss your inventory balance exchange task
To come back with an estimate and a plan, rather than generalities, we need to understand your exchange scheme: which warehouses are involved, how products are matched between 1С:УТ and Bitrix, and how often balances should reach the website.
This determines both the exchange method and the scope of work. Below is what we clarify and what data we request for the audit.
What we clarify at the start
- How many warehouses and retail locations provide balances, and whether there is a write-off priority during sales.
- How products are linked between the databases: by code, SKU, or external identifier, and what to do with items that have no match.
- Whether you need to export only balances or also prices, characteristics, and arrival dates.
- How often to update the data: on a schedule, on an event in 1С, or on request from the website.
- What happens when there is a discrepancy: the website shows zero, but the product is in stock at the warehouse — which source is considered authoritative.
- Whether there are reservations and orders that should reduce the available balance on the storefront.
What data to send
- An export of the nomenclature from 1С:УТ and the product catalog from Bitrix — at least 20-30 items for matching verification.
- A list of warehouses with their identifiers in both systems.
- A description of the current exchange, if it is already set up: what triggers it, where it writes, how often it fails.
- Access to the test environment of 1С and Bitrix — we will build the exchange scheme on them and test it on real data without touching the production website.
How we will come back with an estimate and a plan
We will analyze your data, build an exchange scheme for your case, and show where the bottlenecks are: nomenclature matching, balance conflicts between warehouses, behavior when one of the systems is unavailable.
The response will include the work stages, setup timelines, and what you will get as a result — a working exchange, an error log, and instructions for your team. Describe your task — we will come back with an estimate and a plan.