De volgende stap in het proces "Visueel Reserveren":
In stap #1 hebben we een Vulgraadscherm waarin zichtbaar wordt gemaakt voor welke Afleveradressen van een Raapstation we moeten reserveren. Vanuit dit scherm worden reserverings opdrachten naar een Scanterminal scherm gestuurd.
Stap #2 betrof een Scanterminalscherm waarmee we de opdrachten die op het Vulgraadscherm gemaakt werden konden oppakken, en waarmee we partijen kunnen reserveren voor zo'n Afleveradres.
Nb: Merk op dat partijen gereserveerd kunnen worden op een lokatie die afwijkt van de Lokatie die op de Raapvloer werd vermeld.
Stap #3 betreft het daadwerkelijk Rapen van de Gereserveerde Voorraaditems. Dit gebeurt middels een reeds (voor "meloenen") ontwikkeld scherm "Rapen Voorraaditem", doch welke funktie in dit ontwerp met een aantal formele zaken is aangepast:
- Het is niet toegestaan om te rapen voor een order waarvan op het TouchScreen "Vulgraad Raapstation" is aangegeven dat er voor dit Afleveradres expliciet gereserveerd moet worden.
- Het is niet toegestaan om niet gereserveerde Voorraaditems te rapen op orderregels met produkten, waarvan de kombinatie Artikelgroep-/ Afleveradres aangeeft dat er expliciet vooraf een partij moet worden toegekend. Ofwel, indien we voor een bepaald Afleveradres van een meloen stellen dat er expliciet vooraf een partij moet worden toegewezen, dan zal dit ook daadwerkelijk moeten gebeuren, en mogen we niet zomaar een vrije partij toewijzen aan een Verkooporderregel met dat produkt voor dat Afleveradres.
Nb: Het betreft hier de regels die "roze" zouden worden weergegeven op het TS Leveren Verkooporder.
- Administratief overboeken van de voorraad op de Voorraadlokatie naar een eventueel opgegeven Raapvloer. Hoewel het uitgangspunt voor de Scanterminal/TouchScreen funktionaliteit tot nu toe was "dat de Raapvloer op de Verkooporderregel niet ingevuld mag zijn, om vanaf iedere lokatie te mogen rapen", blijkt dat voor diverse funkties toch niet handig te zijn. Zo geldt bijv. dat het TS Leveren Verkooporder op die manier ook van iedere lokatie afboekt. Kortom, zouden we én scannen én "de oudste charge automatisch afboeken" door elkaar gebruiken, dan werkt dit alsnog niet. Ervanuitgaande dat het doel van het leeglaten was "vanaf iedere lokatie te mogen rapen", kunnen we net zo goed stellen dat als we scannen, we niet naar de Raapvloer kijken, en daarmee ook voorraaditems mogen scannen die niet op de opgegeven Raapvloer liggen. Hier hoort dan weer wel bij dat dergelijke goederen administratief wel naar de juiste Raapvloer overgeboekt moeten worden. Dit, om discrepanties in andere overzichten/rapportages te voorkomen, immers, waar bij invulling van een Raapvloer B2EUR het alleen mogelijk is om voorraad te leveren vanaf de B2EUR lokatie, zou anders ook vanaf een andere lokatie (B1ALG) geleverd kunnen worden. Bestaande rapportages zouden hier wel eens niet op kunen anticiperen. Tevens geldt dat funktionaliteit als "terugboeken levering" haar werk mogelijk niet kan uitvoeren, danwel dit anders dan verwacht uitvoert, immers, moet het ongedaan maken van het rapen van een order op B2EUR op B2EUR worden teruggeboekt, of op B1ALG? Door i.g.v. het rapen van voorraad van een Lokatie die niet overeenkomt met de Raapvloer, eerst administratief over te boeken naar een lokatie die wel overeenkomt met de Raapvloer, omzijlen we deze problemen.
Strikt genomen komt het er dan ook opneer dat we met onze Raapopdracht "Verplaatsen & Rapen" in 1 handeling.
Nb: In de situatie waarin dit nu wordt toegepast, zal bij de Verkooporder altijd een volledige lokatie als Raapvloer zijn ingesteld. In dat geval kunnen we altijd een Voorraadmutatie genereren van een overboeking van de lokatie waar het produkt daadwerkelijk ligt, naar de Raapvloer. Een Raapvloer mag echter ook "een linkerdeel van een serie lokaties" bevatten, bijv. "EA" voor "Eindprodukten Algemeen" of zelfs slechts "E" voor "alle eindproduktmagazijnen".
In zo'n geval zouden we in theorie een voorraadmutatie kunnen maken van de echte voorraadlokatie naar lokatie "E" en daarna administratief doen alsof we van lokatie "E" geraapt hebben, maar, in werkelijkheid bestaat er geen echte lokatie "E", en mogen we verwachten dat dit op andere plekken in het systeem problemen op zal leveren; om te beginnen bij het terugdraaien van een geraapte partij op een Raaplijst.
In plaats van nu te stellen "die situatie ondersteunen we helemaal niet", zeggen we nu dat we de administratieve levering doen via de 1e lokatie die voldoet aan de opgegeven Raapvloer. Vullen we "EA" in als Raapvloer, en bestaat er een lokatie "EA000" als 1e lokatie, dan zal de administratieve levering via EA000 plaatsvinden. Hebben we in werkelijkheid EA-A, EA-B, EA-C als lokaties, dan kan het systeem niet uit zich zelf bepalen welke van de 3 het moet worden; we nemen gewoon de eerste. Werkt dit voor U niet? Dan zal ňf op de Verkooporderregel een echte bestaande lokatie moeten worden opgegeven, ňf is aanvullend maatwerk benodigd. Merk op dat we ons al bevinden in een uitzonderingssituatie voor de regel "Raapvloer dient altijd leeg te zijn".
Bij het eventueel terugboeken van een Levering wordt de partij teruggeboekt op de lokatie van waaraf ze administratief is geleverd; d.w.z. dat als voorraad op B1ALG wordt geleverd op een order met als Raapvloer B2EUR, er administratief een overboeking plaatsvindt van B1ALG naar B2EUR, de goederen vanaf B2EUR worden geleverd, en derhalve terugboeken ook op B2EUR zal plaatsvinden (zoals dat normaal gesproken ook zou gebeuren als we voorraad leveren die aan de opgegeven Raapvloer dient te voldoen).
- Registratie van "Reserveringskaart geplakt"
| Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz |
| LOOFT1 | Omschrijving (nog) niet bekend | 25-09-2012 | 03-10-2012 |
| LOTSSTRV | Omschrijving (nog) niet bekend | 12-01-2010 | 03-10-2012 |
