Разработка мобильного приложения для сканирования и инвентаризации

Разработка мобильного приложения для сканирования и инвентаризации

Инвентаризация на бумаге или в Excel — это три дня работы, ошибки при переносе и невозможность работать параллельно несколькими командами. Мобильное приложение с поддержкой штрихкодов, QR и RFID переводит инвентаризацию в реальный режим: несколько сотрудников сканируют одновременно, данные агрегируются в центральной базе, расхождения видны сразу.

Форматы кодов и реальные проблемы со сканированием

Самое частое разочарование при первом запуске — камера смартфона плохо читает коды в реальных условиях. ML Kit Barcode Scanning от Google — хороший выбор для Android: поддерживает EAN-13, EAN-8, Code 128, Code 39, QR, DataMatrix, PDF417, Aztec. Но при плохом освещении, бликах на упаковке или повреждённых этикетках распознавание нестабильно.

Параметры, которые реально влияют на точность:

• Разрешение превью: CameraX с ResolutionSelector — минимум 1080p для мелких кодов
• BarcodeScanner с включённым ENABLE_ALL_POTENTIALS флагом — агрессивный режим, находит частично перекрытые коды
• Авто-фокус через FocusMeteringAction на центральную зону — без явного запуска иногда не срабатывает на бюджетных устройствах

Для промышленной инвентаризации — Zebra TC21/TC52 или Honeywell CT45. На этих устройствах аппаратный лазерный сканер работает через DataWedge Intent API. Скорость сканирования — 150–200 кодов в минуту против 20–30 у камеры. На складе это принципиально.

RFID-инвентаризация

Отдельная история — RFID. Считыватели Zebra RFD40/RFD90 подключаются к смартфону через Zebra RFID SDK (Android). API сессии:

val rfidReader = RFIDReader(activity, readerName, null)
rfidReader.connect()
rfidReader.Events.setInventoryScanEvent(true)
rfidReader.Events.addEventsListener(object : RfidEventsListener {
    override fun eventReadNotify(event: RfidReadEvents) {
        event.ReadEventData.tagData?.forEach { tag ->
            viewModel.onTagRead(tag.tagID, tag.peakRSSI)
        }
    }
    override fun eventStatusNotify(event: RfidStatusEvents) {}
})
rfidReader.Actions.Inventory.perform()

Одна антенна читает до 300 меток в секунду. Погрешность по зоне — плюс-минус 3 метра, что нужно учитывать при инвентаризации по ячейкам хранения.

Офлайн-режим — не опция, а требование

Зоны без Wi-Fi есть на любом складе. Архитектура: Room для локального хранения отсканированных позиций + WorkManager для фоновой синхронизации. Ключевой момент — детектирование конфликтов. Если два сотрудника отсканировали одну и ту же позицию в офлайн, у неё будет два локальных события. На сервере нужна логика дедупликации по document_id + sku + timestamp.

При большой инвентаризации (50 000+ позиций) Room-запросы на выборку с фильтрами нужно покрывать составными индексами. @Index(value = ["sku", "location_code"]) в Entity — иначе поиск по двум полям без индекса работает как full scan.

Процесс инвентаризации в приложении

Типовой flow: создание документа инвентаризации на сервере → загрузка в приложение → сканирование по зонам → сравнение с учётными данными → фиксация расхождений → отправка результата.

Важная деталь: пересчёт. Когда обнаружено расхождение, кладовщик должен пересканировать зону. Приложение должно позволять редактировать уже занесённые позиции до закрытия документа, но фиксировать все изменения с timestamp и user_id для аудита.

Интеграция

Большинство WMS и ERP предоставляют REST API для документов инвентаризации. 1С — через HTTP-сервисы расширения. SAP — через OData или RFC. Нестандартные системы — через CSV/Excel экспорт по расписанию (медленно, но работает).

Сроки разработки: приложение под один тип сканирования с REST-интеграцией — 4–7 недель. Полный цикл с RFID, офлайн-режимом, несколькими интеграциями — 2–4 месяца. Стоимость рассчитывается после анализа требований к интеграции и поддерживаемым устройствам.