Seamless Warehouse Integration: 1C-Bitrix and DCT

Seamless Warehouse Integration: 1C-Bitrix and DCT

Picture this: your warehouse holds 10,000 units of goods, inventory takes two days, and after manual entry you discover 5% discrepancies. Integrating 1C-Bitrix with data collection terminals (DCT) solves this: every scan instantly enters the system, stock levels update automatically, and errors are eliminated. Savings in operational costs and reduced inventory errors pay off within the first months. According to Oracle, warehouse automation reduces operational errors by 70%.

How DCT Integration with Bitrix Works

Architecture: The DCT never talks directly to the Bitrix database — that would be a security breach and is technically unfeasible. The correct scheme is: DCT ↔ REST API on the Bitrix side ↔ catalog and sale modules. We implement a set of API endpoints that the DCT communicates with over the warehouse WiFi. For offline mode, the device stores the task locally and syncs when the connection is restored.

Authorization: Each DCT gets a personal API token (stored in the HL-block bl_tsd_tokens). The token is rigidly tied to warehouse_id — the device only sees tasks for its own warehouse. Tokens are perpetual but can be revoked through the admin interface. During integration we ensure tokens are created via REST API and support revocation without data loss.

Why REST API Is the Best Protocol

Modern DCTs run on Android, where REST/JSON is the native format. For Windows CE devices (e.g., Motorola MC9200) we use HTTP POST with limited functionality — only order picking, no inventory. REST API Bitrix allows:

• retrieving a picking task (list of items with barcodes and storage locations);
• confirming each scan;
• completing the task and moving the order to "Ready for shipment" status.

The controller /api/tsd/v1/ checks the barcode via \Bitrix\Catalog\ProductTable (field BARCODE or table b_catalog_product_barcode), finds the task item, and updates the counter. Errors: if the barcode is not found or the item isn't in the task, the API returns 422 with a description.

REST API for DCT is 5x faster than exchanging XML files and requires no additional converters.

Solving Offline Operation

The DCT saves the task locally in SQLite. When WiFi drops, scans accumulate; after reconnection, they are sent to the server. A queue is used: each request gets a unique request_id, and the server checks for duplicates. This ensures no scan is lost or duplicated.

Integration Setup in 5 Steps

1. Database schema design: HL-blocks for tasks, tokens, and scan results.
2. REST API development: controllers for picking, receiving, inventory.
3. Admin interface: task creation, report viewing, token management.
4. Testing with a real device: verify all scenarios (offline, barcode conflicts, queue overflow).
5. Warehouse staff training: 1-hour online session.

Example request:

POST /api/tsd/v1/shipment/scan
Content-Type: application/json
Authorization: Bearer <token>

{
  "task_id": 123,
  "barcode": "4601234567890",
  "qty_actual": 1
}

Response: 200 OK or 422 Unprocessable Entity with error description.

What's Included

• Documentation: REST API description, database schema, operator instructions.
• Access setup: creating the HL-block for tokens, linking to warehouses.
• Training: 1-hour online session for warehouse staff.
• Post-release support: 2 weeks of monitoring and fixes.

Inventory via DCT

For inventory we create a task of type inventory. The DCT loads a list of products with expected quantities (qty_system); staff scan and enter actual quantities. After completion, a discrepancy report (qty_system vs qty_actual) is generated. This process reduces inventory time by 80% and improves accuracy to 99.9%.

class TsdInventoryTask {
    public function create(int $warehouseId, array $productIds = []): array {
        // Create record in bl_tsd_inventory_task
        $taskId = InventoryTaskTable::add([
            'WAREHOUSE_ID' => $warehouseId,
            'STATUS' => 'pending',
            'CREATED_BY' => $GLOBALS['USER']->GetID(),
        ])->getId();

        // Load expected quantities from b_catalog_store_product
        $expected = \Bitrix\Catalog\StoreProductTable::getList([
            'filter' => ['STORE_ID' => $warehouseId],
            'select' => ['PRODUCT_ID', 'AMOUNT'],
        ]);

        while ($row = $expected->fetch()) {
            InventoryItemTable::add([
                'TASK_ID' => $taskId,
                'PRODUCT_ID' => $row['PRODUCT_ID'],
                'QTY_SYSTEM' => $row['AMOUNT'],
                'QTY_ACTUAL' => null, // to be filled by DCT
            ]);
        }

        return ['task_id' => $taskId];
    }
}

Goods Receiving

During goods receiving, staff scan each unit. The API handler /api/tsd/v1/receipt/scan matches the barcode to a receipt line (via supplier table b_catalog_docs_element or a custom purchase table) and increments the received count. Upon completion, the system automatically:

• updates stock in b_catalog_store_product;
• creates an inbound document via \Bitrix\Catalog\Document\Store API;
• if discrepancies exist, creates a task for the manager in CRM.

Popular DCT Devices and Compatibility

For Windows CE, we recommend restricting functionality to order picking — inventory and receiving run slowly due to HTTP stack limitations.

Timelines and Cost

Typical timelines: 12 to 15 working days. Costs start from $2,500 and are calculated individually based on the number of task types, need for additional integrations (1C, CDEK), and business logic complexity. We assess the project based on the technical specification.

Company Strengths

With over 5 years on the market and 50+ successful warehouse logistics projects, we guarantee stable operation under heavy load. Our experience ensures that integrations are delivered on time and within budget.

Get a consultation for your project — we'll show a demo of a working integration, provide references, and prepare a commercial proposal within 1 day. Contact us for an estimate.