פיתוח אפליקציות מובייל לסריקה ומלאי
אנו בונים אפליקציות מובייל לסריקה ומלאי שמחליפות גיליונות אלקטרוניים ואקסל. הפתרונות שלנו משתמשים במצלמת הסמארטפון או בסורקים מקצועיים לקריאת ברקודים, קודי QR ותגי RFID. בניגוד לגישה המסורתית שבה ספירת מלאי אורכת שלושה ימים ומועדת לשגיאות אנוש, אפליקציה אוטומטית מאפשרת למספר עובדים לסרוק בו-זמנית, כשהנתונים מאוגדים במסד נתונים מרכזי בזמן אמת.
האתגרים העיקריים שחברות נתקלות בהם במהלך האימוץ: קריאות קוד ירודה בתנאים קשים, חוסר במצב לא מקוון, וקושי באינטגרציה עם 1C ו-SAP. הניסיון מראה שבחירה נכונה של מחסנית הטכנולוגיות (ML Kit, CameraX, Room, WorkManager) וארכיטקטורה (MVVM עם Clean Architecture) פותרת 90% מהבעיות הללו. החיסכון הממוצע לאחר ההטמעה מגיע עד $14k–20k לשנה עבור מחסן עם 5000 פריטים. אנו יכולים להעריך את הפרויקט שלכם – צרו קשר לייעוץ.
מדוע מצלמות סמארטפון נכשלות בקריאת קודים במחסן?
האכזבה הנפוצה ביותר בניסיון הראשון: מצלמת הסמארטפון מתקשה לקרוא קודים בתנאים אמיתיים. סריקת ברקודים של ML Kit של גוגל היא בחירה מוצקה לאנדרואיד: היא תומכת ב-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. סורק הלייזר מעבד עד 200 קודים לדקה, פי 5–7 מהר יותר ממצלמת סמארטפון (20–30). במחסן, זה עושה הבדל מהותי.
| סוג סורק | תפוקה (קודים/דקה) | תנאי עבודה | המלצה |
|---|---|---|---|
| מצלמת סמארטפון | 20–30 | רגישה לאור ובוהק | לשימוש מזדמן |
| סורק לייזר (Zebra) | 150–200 | חזק בכל תנאי | למחסנים תעשייתיים |
| קורא RFID (Zebra RFD) | 300+ תגים/שנייה | טווח ±3 מ', ללא צורך בקו ראייה | למלאי בכמות גדולה |
כיצד פועל המצב הלא מקוון באפליקציית המלאי?
אזורי Wi-Fi מתים קיימים בכל מחסן. הארכיטקטורה שלנו: Room לאחסון מקומי של פריטים שנסרקו + WorkManager לסנכרון ברקע. האתגר המרכזי הוא זיהוי התנגשויות. אם שני עובדים סורקים את אותו פריט במצב לא מקוון, נוצרים שני אירועים מקומיים. השרת צריך לוגיקת הסרת כפילויות המבוססת על document_id + sku + timestamp.
עבור מלאי גדול (50,000+ פריטים), שאילתות Room עם מסננים דורשות אינדקסים מורכבים: @Index(value = ["sku", "location_code"]) ב-Entity – אחרת, סינון על שני שדות מבצע סריקה מלאה.
מלאי RFID
סיפור נפרד – RFID. קוראי Zebra RFD40/RFD90 מתחברים לסמארטפון דרך Zebra RFID SDK (אנדרואיד). דוגמה ל-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 מטרים, ויש לקחת זאת בחשבון בעת ספירת מלאי לפי תאי אחסון. עבור מחסן עם 10,000 פריטים, החיסכון השנתי עולה על $27k–39k.
כיצד לשלב סריקה באפליקציה: מדריך שלב-אחר-שלב
-
הוספת תלות ב-build.gradle:
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(). -
יצירת מופע BarcodeScanner עם אפשרויות:
implementation 'com.google.mlkit:barcode-scanning:17.2.0'. - הגדרת CameraX עם
BarcodeScannerOptions.Builder().setBarcodeFormats(Barcode.FORMAT_ALL_FORMATS).enableAllPotentialBarcodes().build()וחיבורPreviewViewלהזנת פריימים לסורק. - התחלת סריקה ועיבוד תוצאות בקולבק:
ImageAnalysis.Analyzer. - למצב לא מקוון, שמירת תוצאות ב-Room והגדרת סנכרון דרך WorkManager.
תהליך המלאי באפליקציה
זרימה טיפוסית: יצירת מסמך מלאי בשרת → הורדה לאפליקציה → סריקה לפי אזורים → השוואה עם נתוני הנהלת חשבונות → רישום פערים → הגשת תוצאות.
חשוב: ספירות חוזרות. כאשר נמצא פער, על מפעיל המחסן לסרוק מחדש את האזור. האפליקציה צריכה לאפשר עריכה של פריטים שכבר הוזנו עד לסגירת המסמך, אך לתעד את כל השינויים עם חותמת זמן ו-user_id לצורך ביקורת.
אינטגרציה עם מערכות הנהלת חשבונות
רוב מערכות WMS ו-ERP מספקות REST API למסמכי מלאי. 1C – דרך הרחבת שירותי HTTP. SAP – דרך OData או RFC. מערכות לא סטנדרטיות – דרך ייצוא CSV/Excel בלוח זמנים (איטי אבל עובד).
| סוג אינטגרציה | מהירות | מורכבות |
|---|---|---|
| REST API | גבוהה (שניות) | בינונית |
| OData | בינונית | גבוהה |
| CSV/Excel | נמוכה (שעות) | נמוכה |
מה כולל פיתוח אפליקציית הסריקה?
- תיעוד ארכיטקטוני ומפרט API (OpenAPI)
- קוד מקור לאנדרואיד/iOS/Flutter עם כיסוי בדיקות יחידה
- הגדרת CI/CD עבור App Store ו-Google Play
- גישה לחנות ומדריך פריסה
- הכשרת עובדים לשימוש באפליקציה
- תמיכה טכנית ואחריות ל-6 חודשים
לוח זמנים ועלות
לוח זמנים לפיתוח: אפליקציית סריקה בודדת עם אינטגרציית REST – 4–7 שבועות. מחזור מלא עם RFID, מצב לא מקוון ואינטגרציות מרובות – 2–4 חודשים. העלות מחושבת לאחר ניתוח דרישות האינטגרציה והמכשירים הנתמכים. הזמינו פתרון מותאם אישית – נמצא את המחסנית האופטימלית.







