Розробка мобільного додатка для складського обліку
На складі з 15 000 позицій ручний учёт — це не просто повільно. Це помилки в залишках, розбіжність з 1С, інвентаризація по три дні. Мобільний додаток з інтеграцією в WMS/ERP та підтримкою сканування штрихкодів закриває цей розрив: кладовщик сканує товар, дані одразу входять у систему, залишки актуальні у реальному часі.
Сканування: де чаще всього ломається
Перше, з чим стикаються при розробці — ненадійність камерного сканування у умовах складу. Погане освітлення, пошкоджені етикетки, DataMatrix замість звичного EAN-13. На Android CameraX + ML Kit Barcode Scanning закриває більшість форматів (QR, Code128, Code39, DataMatrix, PDF417), але тонування при яскравому бічному світлі дає помилкові спрацювання.
Рішення — апаратний сканер через Zebra DataWedge Intent API або Honeywell Mobility SDK. На пристроях Zebra TC-серії (TC21, TC52) DataWedge перехоплює скан та відправляє як ACTION_BARCODE_DATA Intent. У додатку достатньо зареєструвати BroadcastReceiver:
private val scanReceiver = object : BroadcastReceiver() {
override fun onReceive(context: Context, intent: Intent) {
val barcode = intent.getStringExtra("com.symbol.datawedge.data_string")
val symbology = intent.getStringExtra("com.symbol.datawedge.label_type")
barcode?.let { viewModel.onBarcodeScanned(it, symbology) }
}
}
Камерне сканування залишається як fallback для звичайних смартфонів. ZXing тут гірше ML Kit — точність на PDF417 у реальних умовах заметно нижча.
Офлайн-режим та синхронізація
Складське додаток без офлайн-режиму — нерабоче додаток. Зони приймання, стелажи в дальніх рядах, холодильні камери — покриття Wi-Fi нестабільно.
Архітектура: локальна база Room як джерело істини, синхронізація через WorkManager при відновленні з'єднання. Конфлікти при злитті вирішуються стратегією «остання запис перемагає» з timestamp на сервері або через чергу операцій з ідемпотентними ключами.
Типова проблема — транзакції при масовому приймані товару. Якщо користувач сканував 200 позицій та додаток упав на 150-й, потрібно або відкотити все, або продовжити з точки зупину. Room підтримує транзакції через @Transaction, але межа «що вважати завершеною операцією» повинна бути явно визначена на рівні бізнес-логіки.
Інтеграція з 1С та WMS
REST API 1С через розширення конфігурації — найчастіший сценарій. Формат обміну: JSON з типізованими полями для номенклатури, складів, документів. На стороні мобільного — Retrofit + OkHttp з interceptor для авторизації через Basic Auth або OAuth2.
Інтеграція з промисловими WMS (SAP EWM, Manhattan, Solvo) часто через брокер повідомлень — RabbitMQ або Kafka. Мобільний додаток у цьому разі працює з REST-фасадом, який скриває специфіку ERP.
Критичний момент: маппінг одиниць виміру. В 1С «шт», «уп», «кор» — це рядки, у ERP може бути числовий код. Помилки у маппінгу дають некоректні залишки, це обнаруживається лише при інвентаризації.
Функціональність типового складського додатка
- Приймання товару по накладній з розбіжністю кількості
- Перемішення між ячійками (адресне зберігання)
- Підбір замовлень (picking) з маршрутизацією по складу
- Інвентаризація — повна та вибіркова по зонам
- Друк етикеток через Zebra ZPL або TSC TSPL на парний Bluetooth-принтер
- Перегляд залишків та історії руху по штрихкоду
Стек та підхід
На Android — нативна розробка переважна для роботи з Zebra/Honeywell SDK. Kotlin + MVVM + Room + Retrofit. Для кросс-платформи: Flutter з flutter_barcode_sdk від Dynamsoft (підтримує DataWedge intent) — життездатний варіант, якщо немає жорсткої прив'язки до вендорського SDK.
iOS використовується значно рідше у складських сценаріях через обмежений вибір промислових сканерів, але можливий через AVFoundation + Vision framework для камерного сканування.
Терміни
Базовий додаток (приймання + переміщення + інвентаризація + REST-інтеграція): 6–10 тижнів. Повний цикл з користувацьким WMS-бекендом, адресним зберіганням та друком: 3–5 місяців. Вартість залежить від обсягу інтеграцій та числа підтримуваних пристроїв.