Setting up product acceptance via 1C-Bitrix

Setting Up Product Receipt in 1C-Bitrix

Typical situation: warehouse keeper receives goods according to a paper sheet, then someone manually enters data into the system. Or receipt goes through 1C, and Bitrix inventory arrives with a delay via CommerceML synchronization once an hour. In both cases, the website shows outdated data.

Arrival document in catalog module

Product receipt in Bitrix is implemented through a document of type A (arrival) in the b_catalog_docs table. Document structure: header in b_catalog_docs, product rows in b_catalog_docs_element.

Key fields of b_catalog_docs: DOC_TYPE = 'A', STORE_TO — ID of destination warehouse, CONTRACTOR_ID — supplier from b_catalog_contractor, STATUS — N (draft) or Y (conducted).

Each b_catalog_docs_element row contains: DOC_ID, ELEMENT_ID (product), STORE_TO, AMOUNT (quantity in document), PURCHASING_PRICE — purchase price, CURRENCY.

Creating a receipt document via API:

$result = \Bitrix\Catalog\StoreDocumentTable::add([
    'DOC_TYPE' => \Bitrix\Catalog\StoreDocumentTable::TYPE_ARRIVAL,
    'STATUS' => 'N',
    'STORE_TO' => 2,
    'CONTRACTOR_ID' => 5,
    'TITLE' => 'Receipt from ' . date('m.d.Y'),
    'DATE_DOCUMENT' => new \Bitrix\Main\Type\DateTime(),
]);

$docId = $result->getId();

After creating the header, rows are added via \Bitrix\Catalog\StoreDocumentElementTable::add().

Conducting and inventory recalculation

Conducting a document is the most critical step. The \Bitrix\Catalog\Document\DocManager::conductDocument($docId) method executes several operations transactionally:

1. Updates b_catalog_store_product: increases AMOUNT at destination warehouse.
2. Updates b_catalog_product: recalculates total QUANTITY across all warehouses.
3. Records purchase price in b_catalog_price if this is the first receipt or recalculation is enabled.
4. Creates record in b_catalog_docs with STATUS = 'Y'.

If document is already conducted, repeated conductDocument() call returns an error. For correction, you must first rollback the document via cancelDocument($docId), make changes to rows, then conduct again.

Access rights for warehouse keepers

Warehouse admin interface (/bitrix/admin/cat_store_document_list.php) requires access rights to the catalog module. Minimum required role is catalog_document. Assigned in Settings → Access Management → User Groups, "Module Rights" tab.

For work via mobile terminal (barcode scanner), use REST API or custom component. Product search by barcode goes via b_catalog_product_barcode — table stores PRODUCT_ID → BARCODE correspondence. Query:

$item = \Bitrix\Catalog\ProductBarcodeTable::getList([
    'filter' => ['BARCODE' => '4607134392015'],
    'select' => ['PRODUCT_ID'],
])->fetch();

Purchase prices and cost price

When conducting receipt, Bitrix can automatically update product purchase price. This is managed by catalog module setting — parameter update_purchase_price_on_arrival in b_option. With parameter enabled, each receipt conduct rewrites the price in b_catalog_price for "Purchase" price type.

If you need purchase price history (FIFO/weighted average), the standard module doesn't provide this — you'll need a custom table with price history for each document row and custom cost calculation logic on shipment.

Integration with supplier orders

The catalog module contains document type O — supplier order (b_catalog_docs with DOC_TYPE = 'O'). When supplier ships goods, order document is converted to receipt: method \Bitrix\Catalog\Document\DocManager::createArrivalByOrder($orderId) creates document of type A based on order rows. Quantity can be adjusted before conducting — this covers partial delivery scenario.