Розробка мобільного додатка для сканування та інвентаризації
Інвентаризація на папері або 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 місяці. Вартість розраховується після аналізу вимог до інтеграції та підтримуваних пристроїв.