Интеграция 1С-Битрикс с терминалами сбора данных (ТСД)

Представьте: на складе 10 000 единиц товара, инвентаризация занимает 2 дня, а после ручного ввода обнаруживаются расхождения на 5%. Интеграция 1С-Битрикс с терминалами сбора данных (ТСД) решает эту проблему: каждое сканирование мгновенно попадает в систему, остатки обновляются автоматически, ошибки исключены. Экономия на операционных расходах и снижение потерь от ошибок инвентаризации — значительные, окупаются в первые же месяцы.

Как устроена интеграция ТСД с Битрикс?

Архитектура: ТСД никогда не обращается напрямую к БД Битрикс — это нарушение безопасности и технически нереализуемо. Правильная схема: ТСД ↔ REST API на стороне Битрикс ↔ модули catalog и sale. Мы реализуем набор API-эндпоинтов, с которыми ТСД работает по WiFi склада. Для офлайн-режима устройство хранит задание локально и синхронизируется при восстановлении соединения.

Авторизация: каждый ТСД получает персональный API-токен (хранится в HL-блоке bl_tsd_tokens). Токен жёстко привязан к warehouse_id — устройство видит только задания своего склада. Токены бессрочные, но отзываются через административный интерфейс. При интеграции гарантируем, что токены создаются по REST API и поддерживают отзыв без потери данных.

Почему REST API — оптимальный протокол?

Современные ТСД работают на Android, где REST/JSON — нативный формат. Для Windows CE устройств (например, Motorola MC9200) используем HTTP POST с ограниченной функциональностью — только сборка заказов, без инвентаризации. REST API Bitrix позволяет:

• получать задание на сборку (список позиций с штрихкодами и местами хранения);
• подтверждать сканирование каждой позиции;
• завершать задание и переводить заказ в статус «Готов к отгрузке».

Контроллер /api/tsd/v1/ проверяет штрихкод через \Bitrix\Catalog\ProductTable (поле BARCODE или таблица b_catalog_product_barcode), находит позицию задания и обновляет счётчик. Ошибки: если штрихкод не найден или позиция не из задания — API возвращает 422 с описанием.

REST API для ТСД в 5 раз быстрее, чем обмен через XML-файлы, и не требует дополнительных конвертеров.

Как решается проблема офлайн-работы?

ТСД сохраняет задание локально в SQLite. При потере WiFi сканирования накапливаются, а после восстановления соединения отправляются на сервер. Для этого используется очередь: каждый запрос получает уникальный request_id, сервер проверяет дубликаты. Это гарантирует, что ни одно сканирование не потеряется и не задвоится.

Настройка интеграции за 5 шагов

1. Проектирование схемы БД: HL-блоки для заданий, токенов, результатов сканирования.
2. Разработка REST API: контроллеры для сборки, приёмки, инвентаризации.
3. Административный интерфейс: создание заданий, просмотр отчётов, управление токенами.
4. Тестирование с реальным устройством: проверка всех сценариев (офлайн, конфликты штрихкодов, переполнение очереди).
5. Обучение сотрудников склада: 1 час онлайн.

Пример запроса:

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

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

Ответ: 200 OK или 422 Unprocessable Entity с описанием ошибки.

Что входит в работу

• Документация: описание REST API, схема БД, инструкция для операторов склада.
• Настройка доступов: создание HL-блока токенов, привязка к складам.
• Обучение: 1 час онлайн для сотрудников склада.
• Пост-релизная поддержка: 2 недели мониторинга и исправления.

Инвентаризация через ТСД

Для инвентаризации создаём задание типа inventory. ТСД загружает список товаров с ожидаемыми остатками (qty_system), сотрудник сканирует и вводит фактическое количество. После завершения — отчёт о расхождениях (qty_system vs qty_actual).

class TsdInventoryTask {
    public function create(int $warehouseId, array $productIds = []): array {
        // Создаём запись в bl_tsd_inventory_task
        $taskId = InventoryTaskTable::add([
            'WAREHOUSE_ID' => $warehouseId,
            'STATUS' => 'pending',
            'CREATED_BY' => $GLOBALS['USER']->GetID(),
        ])->getId();

        // Загружаем ожидаемые остатки из 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, // заполнит ТСД
            ]);
        }

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

Приёмка товара

При приёмке поставки сотрудник сканирует каждую единицу. API-обработчик /api/tsd/v1/receipt/scan сопоставляет штрихкод с позицией поставки (через таблицу поставщиков b_catalog_docs_element или кастомную таблицу закупок) и увеличивает счётчик принятых единиц. По завершении приёмки автоматически:

• обновляются остатки в b_catalog_store_product;
• создаётся документ прихода через \Bitrix\Catalog\Document\Store API;
• при расхождении с заказом — создаётся задача менеджеру в CRM.

Популярные ТСД и совместимость

Для Windows CE рекомендуем ограничить функциональность только сборкой заказов — инвентаризация и приёмка на них работают медленно из-за ограничений HTTP-стека.

Сроки и стоимость

Сроки: от 12 до 15 рабочих дней. Стоимость рассчитывается индивидуально — зависит от количества типов заданий, необходимости дополнительных интеграций (1С, СДЭК) и сложности бизнес-логики. Мы оцениваем проект на основании технического задания.

По данным Oracle, автоматизация склада снижает операционные ошибки на 70%.

Получите консультацию по вашему проекту — мы покажем демо уже настроенной интеграции, предоставим референсы и в течение 1 дня подготовим коммерческое предложение. Свяжитесь с нами для оценки. Закажите интеграцию у нас: более 5 лет на рынке, 50+ успешных проектов в складской логистике — гарантируем стабильную работу решения под нагрузкой.