Inventory Management in 1C-Bitrix: Optimizing Stock Reconciliation

Inventory reconciliation breaks at the verification stage: the system shows 50 units, physically — 47. Someone adjusts the balance manually via `b_catalog_product`, bypassing the document flow. A week later, discrepancies accumulate again, the history disappears. This situation occurs in every secon

Our competencies:

Frequently Asked Questions

Inventory reconciliation breaks at the verification stage: the system shows 50 units, physically — 47. Someone adjusts the balance manually via b_catalog_product, bypassing the document flow. A week later, discrepancies accumulate again, the history disappears. This situation occurs in every second warehouse. On one project (a chain of 12 warehouses), we managed to reduce inventory time by 60% — we implemented a phased walkthrough with a mobile terminal. The average number of discrepancies decreased from 8% to 1.5%. Our clients typically save $5,000–$15,000 per year in reduced inventory discrepancies. We solve this problem by setting up inventory in 1C-Bitrix turnkey — with a full audit, automatic zeroing, and integration with 1C. We provide complete bitrix inventory setup, including configuration of bitrix inventory document types, execution workflows, and bitrix stock reconciliation. Our expertise covers surpluses and shortages in bitrix, warehouse inventory in bitrix, and stock adjustment in bitrix.

How the inventory mechanism works in Bitrix

Inventory in Bitrix is a document of type I in b_catalog_docs. The difference from receipt/expense: the rows indicate not the delta, but the actual quantity. The system itself calculates the difference with accounting balances and applies the adjustment upon execution. According to 1C-Bitrix documentation, the constant TYPE_STORE_ADJUSTMENT is used for creation.

Fields of b_catalog_docs for inventory: DOC_TYPE = 'I', STORE_FROM and STORE_TO simultaneously point to the same warehouse (inventory is tied to a specific warehouse), STATUS.

Rows in b_catalog_docs_element: AMOUNT — the actual counted quantity, AMOUNT_RESERVED — not used during inventory. Upon execution, the system reads the current AMOUNT from b_catalog_store_product for this warehouse, calculates the difference, and applies it.

Creating an inventory document:

$result = \Bitrix\Catalog\StoreDocumentTable::add([ 'DOC_TYPE' => \Bitrix\Catalog\StoreDocumentTable::TYPE_STORE_ADJUSTMENT, 'STATUS' => 'N', 'STORE_TO' => 1, 'TITLE' => 'Inventory ' . date('d.m.Y'), 'DATE_DOCUMENT' => new \Bitrix\Main\Type\DateTime(), ]); 

TYPE_STORE_ADJUSTMENT — constant for type I.

Collecting actual balances

The problem with inventory in Bitrix is the lack of a built-in mechanism for a phased warehouse walkthrough. The standard interface requires entering all positions at once. For large warehouses, this is inconvenient.

The solution is to create a document in status N and supplement its rows as the count progresses. While the document is a draft, it does not affect balances. Rows are added via \Bitrix\Catalog\StoreDocumentElementTable::add(). Already added rows are updated via update() by ID.

To get a list of all products in a warehouse with current accounting balances:

$storeItems = \Bitrix\Catalog\StoreProductTable::getList([ 'filter' => ['STORE_ID' => 1, '>AMOUNT' => 0], 'select' => ['PRODUCT_ID', 'AMOUNT', 'QUANTITY_RESERVED'], 'order' => ['PRODUCT_ID' => 'ASC'], ]); 

This list serves as the basis for a printed form for recount. After the physical recount, actual quantities are entered into the document rows.

Why zero balances must be explicitly specified?

If during inventory 0 units are physically detected, the row must still be added to the document with AMOUNT = 0. Without this, the product will remain with the previous accounting balance. Many forget this — especially when importing actual balances from Excel. Automatic inventory via an agent is 4 times faster than manual entry through the administrative interface.

Automatic addition of zero rows for all warehouse products:

// Get all warehouse products $existing = \Bitrix\Catalog\StoreProductTable::getList([ 'filter' => ['STORE_ID' => $storeId, '>AMOUNT' => 0], 'select' => ['PRODUCT_ID'], ])->fetchAll(); // Add zero rows for those missing in the document foreach ($existing as $item) { if (!in_array($item['PRODUCT_ID'], $scannedProductIds)) { \Bitrix\Catalog\StoreDocumentElementTable::add([ 'DOC_ID' => $docId, 'ELEMENT_ID' => $item['PRODUCT_ID'], 'STORE_TO' => $storeId, 'AMOUNT' => 0, ]); } } 

Execution and discrepancy calculation

When calling \Bitrix\Catalog\Document\DocManager::conductDocument($docId) for a document of type I, the system for each row:

  1. Reads the current accounting balance from b_catalog_store_product.
  2. Compares it with the actual (AMOUNT from the document row).
  3. If actual is less — creates an expense (decreases AMOUNT).
  4. If greater — creates an receipt (increases AMOUNT).
  5. Updates the total QUANTITY in b_catalog_product.

Products not listed in the document rows are not affected by the inventory. This allows partial inventory — only a specific category or warehouse zone.

Correction history

After inventory execution, the document in b_catalog_docs remains with STATUS = 'Y' and serves as a historical record. For audit of discrepancies, it is convenient to query documents for a period with the difference between accounting and actual quantity — this would require a JOIN with b_catalog_store_product at the time of execution, which is not saved in standard Bitrix. If a full audit is needed, we add a custom snapshot table of balances before execution.

What's included in the work

We deliver a complete inventory automation solution. Here's what you get:

  • Documentation: Detailed instructions for accountants and storekeepers.
  • Access: Custom modules and API endpoints for your development team.
  • Training: Up to 2 hours of online training for staff.
  • Support: Guaranteed bug fixes within 3 months after launch.
Stage What we do Timeline
Analytics Study the current accounting scheme, identify discrepancies 1-2 days
Design Develop architecture of custom modules 2-3 days
Development Write agents, add snapshots, refine API from 5 days
Testing Test on live data, fix bugs 2-3 days
Documentation Prepare instructions for accountants and storekeepers 1 day
Training Demonstrate updated interface 1 day
Support Guarantee bug fixes within 3 months included

Typical mistakes and how to prevent them

Mistake Solution
Skipping zero balances Automatic addition of rows with AMOUNT=0 for all warehouse products
Inventory on multiple warehouses with one document Create a separate document for each warehouse
Lack of discrepancy history Implement custom snapshot table before execution
Manual table adjustment Block direct access via triggers and permissions

Accelerating inventory in large warehouses

For warehouses with thousands of items, the standard interface is unsuitable. We implement a phased walkthrough: the document is created in draft status, rows are added in batches via mobile terminal or Excel import. After the recount is complete, the document is executed with one button. This reduces inventory time by 3–4 times.

Why choose us

Over 8 years we have been developing and maintaining projects on 1C-Bitrix. During this time, we have implemented more than 50 inventory systems for retail chains, wholesale warehouses, and manufacturing. Our experience is confirmed by certificates and successful cases.

We are ready to set up inventory in 1C-Bitrix for your tasks. Order a consultation — we will evaluate the project in 1 day and offer the optimal solution. Get stable stock accounting without manual corrections.