Интеграция 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+ успешных проектов в складской логистике — гарантируем стабильную работу решения под нагрузкой.