Welke magazijntaken mogen offline?

Begin met de handeling, niet met de verbinding. Een medewerker kan een telling vastleggen zonder dat de centrale voorraad meteen verandert. Een vrije voorraadreservering is een andere zaak: ondertussen kan een collega dezelfde voorraad nodig hebben. Geef per taak aan welke informatie lokaal beschikbaar moet zijn en welke beslissing het centrale systeem moet bevestigen.

De Android-documentatie over offline apps onderscheidt lokaal lezen van schrijven en beschrijft synchronisatieconflicten. Een app die zonder internet bestaande gegevens toont, kan dus niet vanzelf ook veilig voorraadmutaties uitvoeren. Onderstaande proceskeuzes zijn ons ontwerpkader voor magazijnsoftware.

  • Tellen: sla de waarneming op met locatie, telopdracht en moment. Laat het WMS bepalen welke correctie nodig is.
  • Vooraf toegewezen picks: onderzoek of de opdracht exclusief aan dit apparaat of deze medewerker is toegewezen en hoe lang die toewijzing geldt.
  • Vrije picks of blokkades opheffen: vraag centrale bevestiging als actuele beschikbaarheid of toestemming beslissend is.
  • Ontvangst: bepaal of goederen alvast mogen worden geregistreerd, maar nog niet beschikbaar mogen komen voor verkoop of picking.

Laat de medewerker zien wat er is gebeurd.

Gebruik aparte statussen voor lokaal vastgelegd, wacht op verzending, centraal verwerkt en aandacht nodig. Een groene melding mag niet tegelijk “barcode gelezen” en “voorraad bijgewerkt” betekenen. Laat de medewerker openstaande taken terugvinden en geef bij een afwijzing een begrijpelijke reden.

Toon ook hoe actueel een opdracht is. Een eerder opgehaalde picklijst kan inmiddels ingetrokken zijn. Het systeem kan de medewerker laten doorwerken binnen vooraf afgesproken grenzen, maar moet die afspraak kunnen herkennen bij synchronisatie. Als een taak niet offline mag, zeg dan wat de medewerker wél kan doen: een andere taak kiezen, een verbinding herstellen of de verantwoordelijke inschakelen.

Bewaar handelingen voordat je succes meldt.

Ontwerp de lokale opslag als onderdeel van het werkproces. Een bevestigde handeling moet een herstart van de app kunnen overleven. Koppel de registratie aan de gebruiker, taak, artikelidentiteit, eenheid en hoeveelheid. Houd de oorspronkelijke handeling herkenbaar als de medewerker later een correctie vastlegt.

Dit maakt apparaatbeheer onderdeel van de keuze. Wat gebeurt er bij uitloggen, een lege batterij, een defect of het vervangen van een terminal? Maak zichtbaar of er nog onverzonden werk staat voordat iemand het apparaat wist of opnieuw instelt. Beperk de lokaal opgeslagen gegevens tot wat de taak nodig heeft en spreek beveiliging, toegang en opruimen na verwerking af.

Een lokaal bewaarde registratie is geen back-up buiten het apparaat. Bij verlies of fysieke schade kan onverzonden werk verloren gaan. Bepaal daarom welke taken verantwoord zijn zonder centrale bevestiging en hoe medewerkers die situatie herkennen.

Voorkom dubbele boekingen bij opnieuw verzenden.

Geef iedere handeling een blijvende unieke identificatie. Als de app dezelfde aanvraag opnieuw verstuurt na een timeout, gebruikt zij dezelfde identificatie. De ontvangende toepassing moet vervolgens herkennen dat die handeling al is verwerkt en het eerdere resultaat teruggeven. Alleen een nummer meesturen is niet genoeg.

Leg bij de ontvanger het verwerkingsresultaat en de voorraadmutatie gezamenlijk vast, zodat een storing tussen twee stappen geen tweede boeking mogelijk maakt. Voor een pakketkoppeling moet je onderzoeken of de API zo'n werkwijze ondersteunt. Is dat niet zo, ontwerp dan een controle op de bestaande boeking en bied onzekere uitkomsten ter beoordeling aan.

Laat een technisch herhaalverzoek bovendien verschillen van een bewuste tweede scan. Twee afzonderlijke stuks kunnen dezelfde artikelbarcode dragen. Blind alle gelijke codes binnen een paar seconden wegfilteren kan juist geldige handelingen laten verdwijnen. Zie ook scanners koppelen aan bedrijfssoftware.

De ontvangende kant werken we verder uit in betrouwbare API-koppelingen, inclusief gelijktijdige herhalingen en een verloren antwoord na verwerking.

Voorbeeld: dezelfde taak is intussen gewijzigd.

Een fictieve situatie: een picker haalt een opdracht op, verliest verbinding en verzamelt de toegewezen artikelen. Intussen annuleert kantoor de order. Wanneer de terminal weer verbinding heeft, moet de software beide gebeurtenissen herkennen. De latere ontvangsttijd van de scan maakt de fysieke pick niet ongedaan, en de offline pick heft de annulering niet automatisch op.

Een passende herstelroute kan zijn: blokkeer de zending, toon welke artikelen al zijn verzameld en maak een teruglegtaak. Laat een bevoegde medewerker de verdere afhandeling bevestigen. Welke route passend is, hangt af van je proces; het voorbeeld is geen beschrijving van een gerealiseerd klantproject.

Voorkom dat conflicten verdwijnen in een technische log die niemand bekijkt. Spreek af wie een afwijking oppakt, binnen welke werkstap dat gebeurt en wanneer een taak weer vrijgegeven mag worden.

Test een storing tijdens het echte werk.

Beproef de complete route op de beoogde apparatuur, met representatieve labels en taken. Een test waarbij alleen wifi wordt uitgezet voordat de app start, mist juist de onzekere uitkomsten midden in een boeking.

  1. Verbreek de verbinding vlak vóór en vlak ná een centrale verwerking. Controleer dat de app een onzekere uitkomst toont totdat de centrale verwerking is gecontroleerd.
  2. Herstart de app met onverzonden registraties en controleer aantallen en volgorde.
  3. Wijzig of annuleer een taak terwijl de terminal offline is.
  4. Test twee medewerkers met overlappende opdrachten en dezelfde artikelcodes.
  5. Laat de verbinding meerdere keren wegvallen tijdens synchronisatie.
  6. Controleer wie herstelwerk ziet en of een afgehandelde taak werkelijk uit de lijst verdwijnt.

Vergelijk daarna fysieke handelingen met centrale boekingen. Het doel is een verklaarbare uitkomst per handeling, inclusief fouten die bewust door een medewerker worden afgehandeld.

Wifi verbeteren, bestaande app aanpassen of maatwerk?

Onderzoek eerst waarom de verbinding wegvalt. Als het probleem met netwerkdekking of apparaatinstellingen is op te lossen, kan dat een gerichte verbetering zijn. Offline gedrag blijft een afzonderlijke ontwerpkeuze voor situaties waarin verbinding toch niet beschikbaar is.

Bekijk vervolgens welke mogelijkheden de bestaande WMS-app biedt. Als die je taken en herstelroutes goed ondersteunt, kan inrichting voldoende zijn. Wanneer de werkwijze, apparatuur of uitzonderingen niet passen, kan Blade een scannerapp op maat bouwen en koppelen. Die app kan ook onderdeel zijn van een volledig eigen WMS. Vergelijk ontwikkeling en beheer met de tijd die medewerkers kwijt zijn aan onderbrekingen en herstel; een besparing volgt pas uit je eigen cijfers.

Bespreek je scannerproces met Blade. Neem één taak mee waarbij het nu vastloopt, plus het type terminal en de software die je gebruikt. We verkennen welke handelingen moeten doorlopen en welke eerste stap daarbij past. Een uitgewerkt technisch plan is niet nodig.