// /local/ajax/pos-sale-callback.php $data = json_decode(file_get_contents('php://input'), true); foreach ($data['items'] as $item) { $product = \CCatalogProduct::GetByID($item['sku']); if (!$product) continue; // Decrease stock on specific warehouse \Bitrix\Catalog\StoreProductTable::update( ['PRODUCT_ID' => $item['product_id'], 'STORE_ID' => $data['store_id']], ['AMOUNT' => new \Bitrix\Main\DB\SqlExpression('AMOUNT - ?', $item['quantity'])] ); // Recalculate total stock in b_catalog_product \CCatalogProduct::RecalcQuantity($item['product_id']); } 

RecalcQuantity() recalculates b_catalog_product.QUANTITY as the sum across all warehouses in b_catalog_store_product. After that, the product cache must be invalidated — via BXClearCache(false, '/catalog/') or tagged cache. We guarantee update time under 2 seconds.

How to reserve stock for online sales?

A common practice for multi-channel stores: allocate a separate 'online warehouse' in b_catalog_store, whose stock is only for the online store. Physically, goods may be in one warehouse, but logically separated.

Offline sales decrease the 'physical warehouse', while online orders are reserved from the 'online warehouse'. At night, 1C replenishes the online warehouse from the physical one according to a set proportion.

Physical warehouse: 100 units Online quota: 30% = 30 units → stored in b_catalog_store_product (STORE_ID = online_store) Offline quota: 70% = 70 units → not exposed to Bitrix 

This eliminates overselling but reduces available stock for online sales. We tailor the proportion individually based on sales statistics.

How document flow works?

In Bitrix, the catalog module supports warehouse documents: \Bitrix\Catalog\Document\DocumentTable. Document types: A — receipt, S — sale, M — transfer, R — return.

When posting a document via \Bitrix\Catalog\Document\DocumentController::conduct(), stock in b_catalog_store_product is automatically recalculated. This is the correct way to update stock — through documents, not direct UPDATE.

For offline sales: on receiving a webhook from the cash register, we create a document of type S with sale items and post it. This ensures full movement history and accurate inventory accounting.

Inventory reconciliation

Discrepancies between 1C and Bitrix are inevitable. It's crucial to detect them. Once a day we run a reconciliation agent:

// Get stock from 1C via REST API $bx1cItems = get1cQuantities(); // Compare with b_catalog_store_product foreach ($bx1cItems as $sku => $qty) { $bitrixQty = StoreProductTable::getList([ 'filter' => ['PRODUCT.XML_ID' => $sku], 'select' => ['AMOUNT'], ])->fetch()['AMOUNT'] ?? 0; if (abs($bitrixQty - $qty) > 0) { logDiscrepancy($sku, $bitrixQty, $qty); } } 

The discrepancy log allows you to decide: correct Bitrix to match 1C (1C as master) or flag an integration issue. After implementation, the client saves up to $4.5k–6.5k per year by eliminating overselling and manual reconciliation. Annual savings average $2.7k–3.9k.

What's included in the turnkey 1C-Bitrix setup

In each project we provide:

• Audit of current inventory accounting scheme and integration points
• Selection of optimal synchronization protocol (CommerceML or webhooks)
• Endpoint development for cash register and POS terminal webhooks
• Document flow setup: receipt, sale, transfer, return
• Implementation of stock reconciliation agent with discrepancy logging
• Staff training on the updated system
• Detailed documentation on integration and settings
• Technical support for one month after launch

Investment starts from $1.4k–1.9k.

Stages and timelines

Timelines — from 2 to 4 weeks. Investment calculated individually based on complexity. Payback — 4–6 months. We are certified 1C-Bitrix specialists with over 10 years of experience. We guarantee that after setup, stock discrepancies will not exceed 0.1% provided stable communication channels.

If you notice stock discrepancies in your store, order an audit and get a synchronization plan. Contact us for a consultation.