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