Aplikacja magazynowa ze skanerem offline powinna wyjaśniać, co oznacza każdy odczyt kodu. Zeskanowanie produktu nie musi jeszcze potwierdzać jego przyjęcia, wydania ani zmiany lokalizacji. Te działania wymagają kontekstu i reguł biznesowych. Jeżeli interfejs pokazuje jeden komunikat sukcesu dla wszystkich etapów, operator może błędnie uznać, że stan centralny jest już aktualny.
Rozważmy fikcyjną hurtownię, w której pracownik przenosi towary między strefami o różnej jakości zasięgu. Odczytuje kod produktu i miejsca docelowego, a następnie odkłada urządzenie na czas rozładunku. W tym samym okresie biuro może zmienić dyspozycję. System musi zachować pracę operatora i ustalić, które zmiany wymagają późniejszego sprawdzenia przez uprawnioną osobę.
Zdefiniuj operację przed wyborem skanera
Opisz, czy użytkownik rejestruje przyjęcie, wydanie, przesunięcie czy wynik inwentaryzacji. Każdy przypadek może mieć inne warunki akceptacji. Ustal wymagane identyfikatory, jednostkę i lokalizację. Ten sam kod produktu nie powinien automatycznie określać rodzaju ruchu, jeżeli operator pracuje w kilku procesach i może przełączyć się między nimi podczas zmiany.
Przygotuj przykłady nieczytelnego, nieznanego i ponownie zeskanowanego kodu. Zdecyduj, co operator może poprawić ręcznie i kto zatwierdza wyjątek. Skaner jest sposobem wprowadzania informacji, a nie samodzielnym dowodem poprawności całego ruchu. Interfejs powinien pozwolić sprawdzić wybrany produkt i miejsce przed wykonaniem działania, którego skutki mają znaczenie dla magazynu.
Zachowaj pracę na urządzeniu
Określ dane, które muszą być dostępne bez połączenia, oraz zakres ich pobierania. Operator może potrzebować przypisanych dyspozycji i odpowiedniego katalogu, zamiast całej bazy klientów i towarów. Wyjaśnij stan nieukończonego pobrania, aby pusta lista nie wyglądała jak potwierdzenie, że w danej strefie nie ma żadnych zadań.
Pokaż rozróżnienie między zapisem lokalnym, oczekiwaniem na wysłanie i przyjęciem przez centralę. Sprawdź zamknięcie aplikacji oraz wygaśnięcie sesji z niewysłanymi zmianami. Reguła odzyskania dostępu powinna chronić właściwy kontekst użytkownika i urządzenia, a nie wymagać usunięcia kolejki tylko dlatego, że potrzebne jest ponowne uwierzytelnienie przed dalszą synchronizacją.
Zaprojektuj powtórzenia i różnice
Po utracie połączenia urządzenie może ponowić operację, którą centrala już odebrała. Zachowaj tożsamość ruchu, tak aby kolejna próba nie oznaczała drugiego wydania. Osobno określ, jak rozpoznawana jest rzeczywista korekta ilości. Pracownik i biuro muszą umieć odróżnić powtórzenie transmisji od nowej decyzji dotyczącej towaru.
Ustal zachowanie, gdy lokalizacja albo dyspozycja zmieni się podczas przerwy w łączności. Nie każda różnica powinna być automatycznie rozstrzygana według czasu odebrania wiadomości. Zachowaj informacje potrzebne do wyjaśnienia sytuacji i przypisz odpowiedzialność za przegląd. Operator powinien wiedzieć, czy może kontynuować inne zadania, czy musi poczekać na decyzję.
Odbierz pełną ścieżkę ruchu
Utwórz dyspozycję testową, odłącz urządzenie, zeskanuj towar i lokalizację, a następnie uruchom aplikację ponownie. Zmień dyspozycję w biurze i przywróć połączenie. Sprawdź kolejkę, stan magazynu i listę wyjątków. Ponowne wysłanie ma zachować jeden rozpoznawalny ruch, a nie ukryć problem pod dodatkowym wpisem w historii.
Na rozmowę z Brainbaby Labs przygotuj rzeczywistą kolejność pracy z przykładowymi kodami i danymi dopuszczonymi do użycia. Można na tej podstawie wyznaczyć pierwszy zakres aplikacji i konkretne próby odbiorowe. Warto mierzyć go na urządzeniu używanym przez magazyn, z uwzględnieniem łączności i sposobu pracy, zamiast oceniać wyłącznie wygląd formularza w demonstracji.