A retail chain faces three simultaneous order streams: the Bitrix online store, POS terminals in physical stores, and phone orders. Without synchronization, stock is reserved multiple times in parallel—leading to up to 15% of orders being canceled due to insufficient goods. We, engineers with 10+ years of production experience, ensure two-way exchange of orders and stock between Bitrix and 1C in real time. This means: online payment instantly reserves goods in the warehouse, POS sales immediately reduce online stock, and conflicts are eliminated. Turnkey—from architecture selection to staff training.
Why three isolated order streams destroy inventory accounting?
Typical scenario: a customer pays online for a product that was already sold via POS 10 minutes ago. Bitrix deducts stock only after order creation, while the POS sale already reduced the physical stock. The online order is accepted but cannot be fulfilled. Implementing synchronization reduces double-selling losses by 15–20%.
How to choose the master of synchronization?
| Criterion | 1C as master | Bitrix as master | Hybrid (not recommended) |
|---|---|---|---|
| Source of truth | 1C | Bitrix | None |
| Online orders | Transmitted to 1C | Processed in Bitrix | Duplicated |
| Offline sales | Recorded in 1C | Created in Bitrix via API | Lost orders |
| Stock | Synced to Bitrix | Synced to 1C | Overwritten |
| Parallel sales conflicts | Resolved in 1C | Resolved in Bitrix | Occur in both |
80% of conflicts disappear if the master is chosen before development starts. Consult our experts during the audit phase.
Synchronization architecture: protocols and schemes
1C as master
1C is the source of truth for orders and stock. Bitrix transmits online orders to 1C, offline sales are recorded there, and stock is synchronized back.
Bitrix as master
All orders (online and offline via POS) are collected in Bitrix; 1C receives data for accounting.
Synchronization via CommerceML
The standard 1C-Bitrix exchange (/bitrix/admin/1c_exchange.php) covers the basic scenario. Configuration is in the sale module. As stated in 1C-Bitrix documentation, standard exchange via CommerceML is suitable for batch exchange of orders and stock. Limitation: batch every N minutes. For real-time, webhooks or queues are needed.
REST API and message queue
| Protocol | Speed | Implementation complexity | Suitable for |
|---|---|---|---|
| CommerceML | Batch (every N minutes) | Medium | Basic 1C exchange |
| REST API | Real-time | High | Non-standard POS, webhooks |
| Message queue (RabbitMQ) | Milliseconds | Very high | Large chains, high load |
For large chains and high load, a RabbitMQ queue with less than 2-second latency is recommended.
Implementation: reservation and conflicts
Offline orders from POS
When a cashier completes a sale via POS, should we create an order in Bitrix via API or only deduct stock?
Example of creating an offline order via REST API:
// Creating an offline order in Bitrix \Bitrix\Main\Loader::includeModule('sale'); \Bitrix\Main\Loader::includeModule('catalog'); $order = \Bitrix\Sale\Order::create(SITE_ID, $userId); $order->setField('CURRENCY', 'RUB'); $order->setField('USER_DESCRIPTION', 'In-store sale: ' . $storeName); $basket = \Bitrix\Sale\Basket::create(SITE_ID); foreach ($items as $item) { $basketItem = $basket->createItem('catalog', $item['PRODUCT_ID']); $basketItem->setFields([ 'QUANTITY' => $item['QUANTITY'], 'CURRENCY' => 'RUB', 'LID' => SITE_ID, 'PRODUCT_PROVIDER_CLASS' => '\CCatalogProductProvider', ]); } $order->setBasket($basket); // Mark order source $order->setField('STATUS_ID', 'F'); // Completed — offline sale finished $order->setField('ADDITIONAL_INFO', json_encode([ 'source' => 'offline', 'store' => $storeId, 'pos_transaction_id' => $transactionId, ])); $result = $order->save(); Stock reservation on online order
Critical point is reservation timing. Bitrix manages reservations via b_catalog_store_product and b_sale_product_reserve. For Click & Collect, reserve at a specific warehouse.
Real-time stock sync
Stock changes on either side must be instantly reflected. Use an event queue:
// On stock change — add to queue \Bitrix\Main\EventManager::getInstance()->addEventHandler( 'catalog', 'OnProductUpdate', function (\Bitrix\Main\Event $event) { $productId = $event->getParameter('ID'); $fields = $event->getParameter('FIELDS'); if (isset($fields['QUANTITY'])) { // Push to sync queue with 1C \Local\Queue\InventorySync::push([ 'product_id' => $productId, 'quantity' => $fields['QUANTITY'], 'timestamp' => time(), ]); } } ); Parallel sales conflicts
Solution — atomic stock deduction at DB level:
-- Atomic deduction with check UPDATE b_catalog_store_product SET QUANTITY = QUANTITY - 1 WHERE PRODUCT_ID = ? AND STORE_ID = ? AND QUANTITY >= 1; -- If affected_rows = 0 — no stock, reject order Implemented in Bitrix via CCatalogProductProvider.
How we do it: a case of a chain with 10,000 SKUs
Our client — a 12-store chain with 3 online streams and offline sales via 1C:Retail. Standard CommerceML caused a 15-minute delay. Solution: a RabbitMQ queue + custom agent with less than 2-second latency. Conflicts resolved by the first-to-commit principle. Outcome — 99.9% stock accuracy. Paid back in 2 months.
What is included in the work and process
- Audit of current architecture
- Master system and protocol selection
- Setup of order, status, and stock exchange
- Custom agent development
- Load testing
- Documentation and training
- 1 month support
Process: analysis (1–2 days) → design (1–2) → implementation (3–5) → testing (2–3) → deployment (1). Timeline: 5 to 10 working days.
Guarantee: work is performed using official Bitrix and 1C documentation. Asynchronous processing is used to minimize losses.
Contact us for a free audit of your setup. Get a synchronization plan for your business. Order integration and forget about stock problems.