Goods Receipt via Terminal Setup in 1C-Bitrix
Mobile data collection terminals (MobileTerminals) with Bitrix are used for warehouse receipt where you scan barcodes and fix arrival in system immediately — without duplication via Excel or paper documents. Task is technically simple but requires correct integration point selection.
How This Works in Bitrix
Bitrix has no native MobileTerminal module. Integration is built via REST API or direct catalog module access. Two main scenarios:
Scenario 1 — Terminal works via browser. Most modern terminals (Honeywell, Zebra, Urovo) have built-in browser. You create mobile-adapted interface in Bitrix: receipt page with barcode scan form, AJAX request to server, record in database. Barcode is read by terminal's built-in scanner into input field.
Scenario 2 — Terminal works via application through API. Terminal application (usually written in Android Java/Kotlin or uses ready solution like "Cleverence") calls Bitrix REST endpoints. More reliable but more expensive to develop.
Key Tables and Methods
Product receipt in Bitrix is stock replenishment operation. Data stored in:
-
b_catalog_store_product— stock by warehouses -
b_catalog_store_docs— warehouse documents (arrival/departure) -
b_catalog_store_docs_element— document positions
For programmatic arrival document creation use \Bitrix\Catalog\StoreDocumentTable:
$result = \Bitrix\Catalog\StoreDocumentTable::add([
'DOC_TYPE' => \Bitrix\Catalog\StoreDocumentTable::TYPE_ARRIVAL,
'STATUS' => 'N',
'SITE_ID' => 's1',
'CREATED_BY' => $userId,
'DATE_CREATE' => new \Bitrix\Main\Type\DateTime(),
'TITLE' => 'Receipt via Terminal ' . date('d.m.Y'),
]);
$docId = $result->getId();
Document positions added via \Bitrix\Catalog\StoreDocumentElementTable:
\Bitrix\Catalog\StoreDocumentElementTable::add([
'DOC_ID' => $docId,
'ELEMENT_ID' => $productId, // Product ID in infoblock
'STORE_FROM' => null,
'STORE_TO' => $storeId, // Target warehouse ID
'AMOUNT' => $quantity,
'PURCHASING_PRICE' => $price,
'CURRENCY' => 'RUB',
]);
After adding all positions, document is posted — status changes to 'Y', stock updates automatically.
Finding Product by Barcode
Terminal sends barcode — need to find product. Barcodes stored in b_catalog_product_barcode. Query via ORM:
$barcode = \Bitrix\Catalog\ProductBarcodeTable::getList([
'filter' => ['=BARCODE' => $scannedCode],
'select' => ['PRODUCT_ID', 'BARCODE'],
'limit' => 1,
])->fetch();
If barcodes not configured in catalog — search via infoblock properties (CIBlockElement::GetList with BARCODE property filter or similar).
REST API for Terminal Application
If terminal works via application, expose REST handler. In Bitrix, easiest to create component-controller in /local/ajax/ or use rest module:
POST /local/ajax/tsd-receive.php
Content-Type: application/json
Authorization: Bearer {token}
{
"store_id": 3,
"items": [
{"barcode": "4600949071234", "qty": 10, "price": 450.00},
{"barcode": "4606244001234", "qty": 5, "price": 120.00}
]
}
Authorization simplest via static token in module settings or standard \Bitrix\Main\Engine\Controller with session check.
What to Watch Out For
- Units of measure. Ensure arrival documents and stock use same units. Confusion between pieces and packages — common mistake.
- Multiple warehouses. If several warehouses, terminal interface must allow destination warehouse selection before scanning.
- Duplicate scan. Terminal may send barcode twice on poor connection. Need duplicate protection at receipt session level.
- Document posting. Don't post automatically on scan. Let warehouseman review final list and confirm.
| Stage | Time |
|---|---|
| Analyze current warehouse accounting scheme | 2–4 h |
| Develop API endpoint / web interface | 8–16 h |
| Set up barcode search | 2–4 h |
| Test on real terminal | 4–8 h |
| Staff training | 1–2 h |







