Why Stock Desynchronization Occurs When Integrating with WMS
Stock desynchronization between 1C-Bitrix and WMS means direct financial losses. An order is placed on the site, a reserve is set, but WMS doesn't know. By the time of picking, the product isn't on the shelf — the customer gets a rejection. Without proper integration, you lose up to 3% of revenue due to oversell and shipping delays. Losses can reach $4.5k–6.5k per year. We integrate 1C-Bitrix with any WMS, guaranteeing atomic transfer and no "hanging" orders. The work is carried out by certified specialists using proven patterns. Contact us for an assessment of your project.
What Exactly Needs to Be Synchronized
Stock and Reserves
WMS is the source of truth for physical availability. Bitrix receives stock and updates b_catalog_product (fields QUANTITY, QUANTITY_RESERVED). Synchronization frequency is critical: with 200+ orders per day, a 15-minute delay already creates oversell. Losses can reach $1.8k–2.6k per month.
Orders
New order from Bitrix → WMS for reservation and picking. Picking statuses from WMS → Bitrix to update the order status for the customer. Atomicity is important here: the order is either accepted by WMS or not — "hanging" transfers are unacceptable.
Product Catalog
Nomenclature, barcodes, units of measurement, packages. Usually master data is maintained in ERP/1C, and WMS and Bitrix synchronize from it.
Which Integration Architecture to Choose
There is no direct API connection "Bitrix ↔ WMS" — each WMS has its own API or supports EDI/XML formats. The choice of architecture depends on reliability and latency requirements. Webhook with event queue is 3–5 times faster than polling and provides latency in seconds vs minutes. Let's compare the main approaches:
| Approach | Latency | Reliability | Complexity |
|---|---|---|---|
| Polling (scheduled checks) | Polling interval (1-15 min) | Medium (data loss on agent failure) | Low |
| Webhook + event queue | Seconds | High (queue buffers) | Medium |
| Via 1C broker | Minutes | Very high (1C control) | High |
Polling is implemented via a handler in \Bitrix\Main\EventManager or a custom agent. Webhook/event queue: WMS sends an event on every stock change. Bitrix receives via REST endpoint and queue (RabbitMQ, Redis Streams). Via 1C broker: if 1C:Enterprise is in the chain, exchange goes through it: Bitrix ↔ 1C (standard CommerceML / REST) ↔ 1C ↔ WMS.
How to Technically Implement the Integration on the Bitrix Side
Stock is updated via \Bitrix\Catalog\ProductTable::update() or low-level CCatalogProduct::Update(). When updating, it's important to invalidate the cache: \Bitrix\Catalog\Catalog::clearProductCache($productId). Without this, the site shows old stock for another 30–60 minutes. Reservation when creating an order: the \Bitrix\Sale\Order object automatically sets a reserve via \Bitrix\Sale\Basket::setField('RESERVE_QUANTITY'). If the integration updates stock directly in the DB bypassing the API — reserves break. Always work through the public API of the sale module. To transmit orders to WMS, we hook into the OnSaleOrderSaved or OnSaleStatusOrderChange event — depending on the trigger. The event is processed synchronously, so long API calls are moved to a queue.
How to Avoid Order Duplication
Duplication occurs when the network is unstable and Bitrix repeats the request on timeout. Solution: idempotent requests with ORDER_ID from Bitrix as an external key in WMS — retransmission updates the existing record, does not create a new one. We always implement this mechanism to exclude financial losses from duplicates.
Why Atomicity of Transfer Is Important
Imagine: an order is transmitted to WMS, but WMS hasn't had time to accept it, and Bitrix has already marked it as "sent". The product is physically reserved, but remains hanging in the system. Atomicity ensures that the order is either fully transmitted and accepted, or not. Achieved through transactional queues and confirmations from WMS. This is our standard.
What Typical Errors Occur
Direct database updates bypassing the sale module API — reserves break. Ignoring cache invalidation after stock updates. No handling of timeouts for bulk requests. Discrepancies in units of measurement (pieces vs pallets) — without a conversion table, stock is incorrect. Solved by a conversion directory on the integration layer. When bulk updating stock, WMS sends 10,000 items in one request; Bitrix processes in batches with set_time_limit() and \Bitrix\Main\Application::getInstance()->getDbConnection()->startTransaction().
How Long Does the Integration Take
| Scenario | Timeline |
|---|---|
| Simple integration: scheduled stock updates | 2–4 weeks |
| Two-way exchange of orders and stock | 4–8 weeks |
| Integration via 1C broker with complex logic | 2–4 months |
Cost is calculated individually — depends on the specific WMS API, volume of nomenclature, and real-time requirements. We start with an audit of current processes and WMS technical documentation. Contact us to get accurate timelines and a commercial proposal.
What Is Included in the Integration
- Audit of current warehouse processes and WMS API.
- Design of integration architecture (polling/webhook/1C broker).
- Development of exchange modules on the Bitrix side.
- Implementation of idempotency and atomicity.
- Queue setup (RabbitMQ/Redis if needed).
- Cache invalidation and tagged caching.
- Testing under production loads (oversell, timeouts).
- Documentation, team training, post-launch support.
Order a turnkey integration — we will prepare a detailed plan and timeline. Warranty on work — 12 months.