Aplikacja magazynowa Android w logistyce kontraktowej

Aplikacja magazynowa Android na hali operatora

W logistyce kontraktowej operator logistyczny prowadzi magazyn dla firm trzecich na podstawie umowy z określonymi wymaganiami jakościowymi. Umowa bywa długoterminowa albo krótkoterminowa, ale w obu przypadkach magazynier na hali pracuje dla kilku zleceniodawców w ciągu jednej zmiany. Terminal w jego ręku musi więc wiedzieć, dla którego klienta trwa bieżące zadanie i jakie reguły z umowy obowiązują przy tym towarze.

Ta strona dotyczy urządzenia i aplikacji na hali. Rolę systemu po stronie operatora, w tym dane wielu klientów w jednej bazie, opisuje artykuł o WMS dla operatora 3PL. Modele współpracy z operatorem i kryteria jego wyboru przedstawia osobny tekst o modelach współpracy. Ogólne zasady działania mobilnego WMS zawiera strona o aplikacji magazynowej na Androida.

Kontekst klienta powinien być widoczny na każdym ekranie zadania. Nagłówek z nazwą zleceniodawcy chroni przed pomyłką, w której magazynier odkłada towar jednego klienta do strefy drugiego. Część operatorów dodaje kolor przypisany do klienta, żeby rozpoznanie następowało bez czytania.

Zapotrzebowanie na dane z hali zależy od branży klienta. Operator dopasowuje do niej zakres skanowania, a nie sam sprzęt.

• E-commerce - wysoka rotacja drobnych przesyłek, integracja z platformami sprzedażowymi i kurierskimi oraz szczyty sezonowe.
• FMCG - duże wolumeny i krótkie terminy przydatności części asortymentu, więc wydania zgodne z zasadą FEFO.
• Farmacja i chłodnie - kontrola temperatury i pełna identyfikowalność partii.
• Motoryzacja i produkcja - części zamienne oraz dostawy just-in-time z integracją z ERP producenta.

Wprowadzanie danych - skaner zamiast klawiatury

Aplikacja magazynowa wykonuje cztery czynności na danych. Przyjmuje je i przetwarza, a potem przechowuje oraz udostępnia. Pierwsza z nich decyduje o jakości pozostałych, bo błąd wprowadzony na hali przechodzi przez cały system. Klawiatura jest najsłabszym urządzeniem wejściowym. Człowiek myli cyfry w długim kodzie, a czytnik kodów kreskowych robi to praktycznie wcale.

Skanowanie ma jeszcze dwie zalety. Kod odczytany przez urządzenie trafia do systemu w ułamku sekundy, więc magazynier nie traci czasu na wpisywanie. Terminal przesyła też dane z wielu miejsc do jednej bazy, dzięki czemu kierownik widzi stan pracy na bieżąco. Więcej o zasadach pracy z czytnikami znajduje się w artykule o programie magazynowym ze skanerem.

Rodzaj kodu zależy od poziomu opakowania. Drobne opakowania noszą zwykle kod EAN-13 albo kod dwuwymiarowy, a etykieta logistyczna palety kod GS1-128 z numerem SSCC. Terminal rozpoznaje typ kodu po symbolice i kieruje skan do właściwej operacji: zwykły towar do kartoteki, paletę do dokumentu przesunięcia. Takie rozróżnienie oszczędza magazynierowi wybieranie trybu z menu.

Terminal z Androidem odczytuje kody dwiema drogami. Wbudowany skaner laserowy albo obrazowy przekazuje wynik jako wpis z klawiatury lub komunikat systemowy, a aplikacja odbiera go w aktywnym polu. Kamera urządzenia też potrafi rozpoznawać kody, na przykład przez bibliotekę ML Kit Barcode Scanning, ale na hali o dużej rotacji wolniej i mniej pewnie niż dedykowany moduł. Dobór urządzeń omawia strona o kolektorze danych z Androidem.

Ważna jest też informacja zwrotna po skanie. Krótki sygnał dźwiękowy albo wibracja potwierdza przyjęcie kodu, a inny wzorzec sygnału oznacza odmowę. Magazynier w rękawicach, przy hałasie wózków, nie czyta komunikatów, dlatego sygnał musi być jednoznaczny bez patrzenia na ekran.

Reguła projektowa: pole kodu w aplikacji przyjmuje wynik skanowania, a ręczne wpisanie wymaga osobnego uprawnienia i zapisu w dzienniku. Ręczny wpis jest najczęstszym źródłem pomyłek w ewidencji.

Przetwarzanie skanu w aplikacji i na serwerze

Przetworzenie danych wymaga oprogramowania, które poprawnie zinterpretuje sygnał z czytnika i przełoży go na operację magazynową. Sprzęt daje ciąg znaków, a decyzję o tym, co on oznacza, podejmuje algorytm. Dopiero współdziałanie obu warstw zapewnia natychmiastową reakcję, na przykład aktualizację stanu tuż po zeskanowaniu towaru.

Sensowny podział pracy wygląda tak: terminal sprawdza to, co da się ocenić bez bazy, a serwer rozstrzyga sprawy wymagające kontekstu. Klasycznym testem lokalnym jest cyfra kontrolna kodu EAN-13. Odrzuca ona kod odczytany z błędem, zanim pojawi się zapytanie do sieci.

// przykład: walidacja cyfry kontrolnej EAN-13
static bool IsValidEan13(string code)
{
    if (code.Length != 13) return false;
    foreach (char ch in code)
        if (ch < '0' || ch > '9') return false;

    int sum = 0;
    for (int i = 0; i < 12; i++)
    {
        int d = code[i] - '0';
        sum += (i % 2 == 0) ? d : d * 3;
    }
    return (10 - sum % 10) % 10 == code[12] - '0';
}

Serwer dostaje komunikat opisujący pojedynczy skan. Poniższy przykład jest szkicem formatu, a nie opisem rzeczywistego interfejsu produktu.

POST /api/scan
{
  "ownerId": 12,
  "location": "A-02-05-3",
  "barcode": "5901234123457",
  "qty": 1,
  "deviceId": "TC-07",
  "requestId": "TC-07-000184"
}

Czas odpowiedzi serwera wpływa na rytm pracy. Jeżeli aplikacja czeka na odpowiedź po każdym skanie, magazynier traci sekundy, które w ciągu zmiany sumują się w minuty. Dlatego terminal może przyjąć skan optymistycznie, zapisać go w kolejce i pokazać potwierdzenie, a odmowę serwera zgłosić chwilę później. Ten wariant wymaga jednak dobrze opisanej obsługi odrzuceń, o której mowa w dalszej części.

Pole requestId pełni rolę klucza powtórzenia. Gdy odpowiedź zginie w sieci, terminal wyśle to samo żądanie ponownie, a serwer rozpozna je po identyfikatorze i nie zaksięguje drugi raz.

Każdy skan niesie także tożsamość zalogowanego użytkownika i urządzenia. Dzięki temu w historii operacji widać, kto i którym terminalem wykonał ruch, co ułatwia wyjaśnianie różnic inwentaryzacyjnych i reklamacji zgłaszanych przez klientów operatora.

Przechowywanie danych i praca bez zasięgu

Wszystkie informacje z hali przechodzą przez urządzenia wejścia, a po przetworzeniu trafiają do trwałego zapisu. Trwałość ma dwa poziomy. Na terminalu to lokalna kolejka zdarzeń, która chroni skany podczas utraty zasięgu Wi-Fi w głębi regałów. Na serwerze to baza SQL Server z kopiami zapasowymi i archiwum historii.

Kolejkę lokalną zwykle prowadzi się w bazie SQLite, na przykład przez bibliotekę Room. Zadanie, które opróżnia kolejkę po powrocie sieci, planuje mechanizm opisany w dokumentacji WorkManager. Zdarzenia wysyła się w kolejności ich powstania, a każde z nich niesie klucz powtórzenia opisany wyżej.

Ochrona danych na urządzeniu jest osobnym tematem. Zgubiony terminal nie może ujawnić kartotek klientów operatora, więc urządzenia obejmuje się szyfrowaniem i zdalnym zarządzaniem. Zasady opisują artykuły o bezpieczeństwie programu magazynowego na Androida oraz o wdrożeniu zarządzania urządzeniami MDM.

Odrzucenie po czasie jest zwykłą sytuacją, a nie awarią. Skan mógł dotyczyć lokalizacji, którą w międzyczasie zablokowano, albo zlecenia wycofanego przez klienta. Serwer zwraca wtedy przyczynę, a terminal przenosi zdarzenie na listę wyjątków. Brygadzista przegląda ją na koniec zmiany i decyduje, czy operację powtórzyć, czy skorygować ręcznie.

Rosnący zbiór informacji o towarach i kontrahentach wymaga mechanizmu wyszukiwania danych historycznych. Archiwizację warto zaplanować od pierwszego dnia pracy systemu. Zapobiega to problemom po awarii sprzętu, utracie urządzeń albo zmianie struktury plików, a raporty za dawne okresy nadal działają na tych samych zasadach.

Numery seryjne i zasada FEFO

Adres lokalizacji określa położenie towaru, ale nie mówi nic o konkretnym egzemplarzu. Strefy oznacza się symbolami, tak samo jak regały, więc lokalizacja jest jednoznaczna. Kiedy klient wymaga śledzenia, ewidencja obejmuje dodatkowo numer seryjny albo numer partii produkcyjnej. Dopiero wtedy operator wie, ile sztuk o danym numerze seryjnym lub z określonym terminem ważności leży w magazynie.

Śledzenie kosztuje czas, więc zakres ustala się w umowie. Skanowanie każdej sztuki wydłuża przyjęcie, dlatego numer seryjny wymaga się tylko dla asortymentu, w którym klient go potrzebuje, na przykład dla urządzeń objętych gwarancją. Reszta towaru pozostaje w ewidencji ilościowej albo partiowej.

Taka informacja jest niezbędna przy wydawaniu według zasady FEFO (First Expired, First Out), czyli według najkrótszego terminu przydatności. Towar z krótszym terminem opuszcza magazyn jako pierwszy, więc maleje ryzyko przeterminowania, a klient dostaje towar o właściwej jakości. Zasady prowadzenia partii opisuje artykuł o partiach produkcyjnych i datach ważności, a specyfikę branży spożywczej - strona o logistyce w branży spożywczej.

Reguła: przy wydaniu FEFO terminal wskazuje najpierw partię o najkrótszym terminie przydatności. Skan partii innej niż wskazana wymaga potwierdzenia i pozostaje w historii operacji.

Udostępnianie danych i eksport kartotek

Udostępnianie danych zaczyna się od decyzji, jaka informacja jest naprawdę potrzebna odbiorcy. Baza zawiera znacznie więcej, niż potrafi przyswoić magazynier w trakcie zadania. Widok na terminalu powinien więc pokazywać tylko to, co potrzebne do zadania: adres lokalizacji i towar do zeskanowania. Szczegóły warto zostawić dla ekranu administratora. Aby system pomagał w codziennej pracy, korzystanie z niego ma wymagać minimum wysiłku. Stąd rosnące znaczenie aplikacji na Androida, które skracają liczbę kroków przy wprowadzaniu i odczycie danych.

Dane trafiają także poza magazyn. W Studio WMS.net menu eksportu obejmuje kartoteki magazynowe i kartoteki kontrahentów. Są w nim też lokalizacje oraz stany magazynowe z miejscami składowania. Operator kontraktowy używa takich plików do wymiany danych z klientami i do kontroli własnej ewidencji.

Eksport danych powinien podlegać uprawnieniom. Plik z kartoteką kontrahentów zawiera dane handlowe klientów operatora, więc dostęp do tej opcji przydziela się wybranym rolom, a każde użycie zostaje w dzienniku. Zasada ta chroni operatora przed sytuacją, w której lista odbiorców jednego zleceniodawcy trafia do drugiego.

Wyeksportowany plik jest tylko migawką. Jeżeli klient potrzebuje danych na bieżąco, właściwszą drogą jest portal albo integracja, a nie cykliczne przesyłanie arkuszy pocztą.

Oprogramowanie na zamówienie dla magazynu

Firma SoftwareStudio z Poznania od 1994 roku tworzy oprogramowanie na zamówienie. Rozwiązania obejmują aplikacje internetowe i aplikacje mobilne na system Android, a warstwę serwerową opierają na Microsoft IIS oraz bazach SQL Server. Od 2017 roku firma rozwija aplikacje mobilne dla magazynów. Szczegóły oferty opisuje strona o oprogramowaniu na zamówienie w Poznaniu.

Operator kontraktowy zwykle nie chce inwestować w serwerownię, więc ważny jest model rozliczania. Licencje miesięczne albo roczne pozwalają ograniczyć wydatki na własny dział IT i na infrastrukturę. Przegląd urządzeń i rozwiązań do pracy radiowej w magazynie znajduje się na stronie o terminalach radiowych.