TouchScreen-/Scanterminal ReserverenIn dit topic wordt een groot ontwerp "Reserveren" beschreven.
Achterliggende gedachte is dat we enerzijds diverse partijen op voorraad hebben liggen van onze produkten, anderzijds een stapel met orders van klanten die deze produkten nodig hebben, en we zullen moeten bepalen welke klant welke partij geleverd krijgt. Normaal gesproken hoeft dit niet zo moeilijk te zijn. We kunnen orders leveren op basis van "wie het eerst komt, wie het eerst maalt", of we kunnen produkten toekennen op basis van Leverdatum. Maar, normaal gesproken zal iedere partij gelijke specifikaties hebben, danwel specifikaties hebben conform de eisen van de strengste klant, opdat iedere partij aan iedereen geleverd kan worden.
Het wordt een stuk complexer indien de kwaliteit van een specifieke partij wél mee gaat spelen, en we niet meer zomaar alles aan iedereen kunnen leveren.
Bij A.G.F. produkten kan een produkt gedurende de tijd van kwaliteit wijzigen. Een tomaat die nu groen is, is over een tijdje rood; een tomaat die nu rood is, is over een tijdje rot, en kan niet meer verkocht worden. Leveren we een rode tomaat aan een nederlandse winkel, dan kan deze de tomaat meteen verkopen. Leveren we een groene tomaat aan dezelfde winkel, dan kan de winkel deze niet verkopen, want de consument zal de tomaat meteen willen nuttigen. Maar, daarmee is niet iedere rode tomaat geschikt en groene tomaat ongeschikt, immers, lever de rode tomaat aan een klant in Japan, en tegen de tijd dat die tomaat daar aankomt, is de partij alsnog rot en kan ze niet meer verkocht worden. Ofwel, de Japanner zullen we een dermate goede kwaliteit willen leveren, dat als het produkt in Japan arriveert, de kwaliteit alsnog acceptabel is.
Aldus gaat dit ontwerp ervanuit dat er een zgn.
Produktverantwoordelijke. Dit is een persoon die alles afweet van het produkt (of de produkten) waar hij/zij voor verantwoordelijk is. De Produktverantwoordelijke weet dus welke partijen we op voorraad hebben, weet welke orders we hebben, weet voor welke klanten die orders zijn, weet hoe lang het transport naar een dergelijke klant in beslag neemt, en kan op basis van al dit soort informatie bepalen welke partij het beste voor welke klant (Afleveradres) ingezet kan worden.
Waar het Artikelbestand uit meer dan 10.000 verschillende Artikelen-/Verschijningen kan bestaan, zal de produktverantwoordelijke alleen geďnteresseerd zijn in "zijn" produkten. We moeten derhalve een filter leggen op de Artikelen die we willen zien. Zoiets zou in theorie via een Artikelgroep kunnen, maar, de produktverantwoordelijke kan ook over Artikelen uit verschillende Artikelgroepen gaan. Ook kan het gewenst zijn om 1 Touchscreen scherm te delen met andere produktverantwoordelijken, en zodoende verschillende produkten op hetzelfde scherm te presenteren. Binnen dit ontwerp is een
Raapstation geďntroduceerd, als zijnde een kapstok om Artikelgroepen aan te kunnen koppelen die we op een betreffend TouchScreen scherm willen tonen. Zo'n Raapstation mag dus 1:1 worden gedefinieerd met een produktverantwoordelijke, maar zou ook 1:1 kunnen worden gedefinieerd met een fysiek TouchScreen scherm en de data die we daarop willen tonen.
Raapstations
Via Hmenu-1-1-3-1-8 kunnen we Raapstations vastleggen.
Via Shift-F4 gaan we naar de Artikelgroepen die aan het Raapstation zijn gekoppeld.
Vanuit deze funkties leggen we vast welke produkten we wensen te zien als we de gegevens van een specifiek Raapstation opvragen.
Te Reserveren Afleveradressen per Artikelgroep
Vervolgens is het uitgangspunt dat we niet voor ieder produkt vooraf een partij moeten laten toewijzen door een produktverantwoordelijke, en ook niet voor iedere Debiteur (of beter: Afleveradres, immers als een Debiteur een Afleveradres in Nederland heeft, maar ook in Azië, zullen we voor Azië toch een andere partij wensen toe te kennen). Tevens zullen we voor de Afleveradressen waarvoor we wensen te reserveren moeten aangeven welk Afleveradres met welke Prioriteit moet worden behandeld. Hiervoor is een speciale Listmover + Listsort control opgenomen.
Deze is te bereiken middels Shift-F5 vanuit Raadplegen Raapstations.
Boven in het scherm dienen we als eerste een Artikelgroep te selekteren (omdat registratie op niveau van Artikel te bewerkelijk zou zijn, is ervoor gekozen dit op Artikelgroepniveau te doen). Vervolgens krijgen we een Listmover te zien, met links de nog niet opgenomen Afleveradressen, en rechts de wel opgenomen Afleveradressen. Afleveradressen kunnen links gemarkeerd worden en naar rechts worden verplaatst. Per serie waarin ze verplaatst worden, zal er een nieuw volgnummer worden toegekend.
Tip: Door bijv. op kolom uit de List te clicken, wordt de data in de List gesorteerd op die kolom. Clicken we op kolom 'Landkode', dan zien we als vanzelf alle Afleveradressen in een bepaald land.
In onderstaand scherm is al 1 Afleveradres in Korea opgenomen. Deze krijgt prioriteit 00001.
Vervolgens selekteren we een groep Afleveradressen in Duitsland:
en als we die naar rechts verplaatsen, krijgen deze allen volgnummer 00002.
Middels Afleveradres '-----------'/0 is het mogelijk om een registratie "Ongeacht Afleveradres" vast te leggen.
Met F1 verwerken we onze selektie.
Op het 2e tabblad kunnen we vervolgens nog sorteren. Op dit scherm kunnen we bijvoorbeeld de Nederlanders selekteren...
en met Up Arrow deze naar boven verplaatsen. Ze komen dan boven de eerst vorige prioriteit te staan.
Blokkade op TouchScreen Leveren Verkooporder
Zodra van een kombinatie Artikel + Afleveradres is aangegeven dat er vooraf een partij moet worden toegekend (zie bovenstaande schermen), geldt dat dit produkt niet meer automatisch mag worden afgeboekt op het TouchScreen Leveren Verkooporder. Dat scherm weet nl. niets af van de specifikaties van de verschillende Charges, en zal simpelweg "de oudste Charge" als eerste afboeken. Is derhalve aangegeven dat een kombinatie gereserveerd moet worden, dan wordt deze kombinatie automatisch geblokkeerd op het TS scherm, en kan ze niet meer via dat scherm worden geleverd. De regel wordt daar in het rose weergegeven.
Vulgraadscherm v/e Raapstation
Omdat een Scanterminal scherm te klein is om allerlei informatie op te presenteren die nodig is om te kiezen voor welke Afleveradressen er gereserveerd moet worden, is ervoor gekozen om het toewijzen van alle partijen aan te sturen via een TouchScreen scherm. Via dit scherm worden vervolgens "te reserveren" opdrachten gemaakt die door een separaat Scanterminal scherm kunnen worden opgepikt.
Op het 1e scherm kiezen we als eerste voor het Raapstation waarvan we de produkten willen zien. Afhankelijk van het geselekteerde Raapstation zal het systeem bepalen welke "Routegroepen" er voor de Artikelen van dat Raapstation zijn, en kan dat in de daaronderstaande control worden geselekteerd.
T/m welke Routegroep we willen gaan reserveren mogen we zelf bepalen. De praktijk zal aantonen hoever vooruit we deze rubriek mogen zetten, maar, realiseer je dat als we dagelijks goederen binnen krijgen en goederen verzonden worden, het opvragen t/m "volgende week" kan impliceren dat we nú voorraad gaan toekennen aan een order van volgende week, en er vervolgens voor zorgen dat een order van morgen niet uitgeleverd kan worden. Pas dus op met hoever we vooruit gaan werken.
Na dit voorloopscherm volgt een overzicht met daarop de verschillende kombinaties van Artikel+Verschijning+Kenmerken waarvoor gereserveerd
kan worden; voor het gemak korten we de term "Artikel-/Verschijning-/Kenmerkkombinatie" even af met
AVK.
Een AVK-regel kan hierin zijn opgebouwd uit verschillende kleuren. Iedere regel moet worden gezien als een tijdsbalk, waarbij uiterst links "nu" is, en uiterst rechts "de opgegeven eindtijd" betreft. Ofwel, de regels tonen nu een tijdsbalk van 05-09-2012 09:49 t/m 14-09-2012 16:00. Deze tijdsbalk is vervolgens weer in een aantal subblokken verdeeld. Het midden van de balk zal overeenkomen met het midden van bovengenoemde tijdreeks (ergens rond 09-09-2012).
Per subblok berekend het systeem de VTV van de betreffende AVK, en toont het resultaat in kleuren:
De 1e regel is helemaal groen, en impliceert dat alles wat gereserveerd moet worden gereserveerd kán worden omdat er voldoende voorraad is.
De 2e regel begint groen, wordt daarna rood, daarna oranje, en daarna weer rood; voor de eerste orders kan uit voorraad worden gereserveerd, dan komt er een moment dat we teweinig voorraad zullen hebben, daarna gebeurt er "iets" (bijv. een Inkooporder die binnen wordt verwacht) waardoor de VTV weer toereikend is, en verderop in de tijd hebben we alsnog weer niet voldoende voorraad.
Als we op de button "Toon Debiteuren" clicken, krijgen we een overzicht van de Debiteuren (Afleveradressen) voor wie gereserveerd moet worden.
Alles groen? Maar het vorige scherm toonde toch rood en oranje ?
Korrekt. Maar... dit scherm vereist ook weer wat uitleg.
Vergelijk dit scherm met het overzicht "Raadplegen Te Leveren Artikelen".
Rechts boven in het scherm zien we de Technische Voorraadhoogte van de geselekteerde AVK : 320 Verschijningen.
In de regels wordt aangegeven hoeveel er in totaal voor welk Afleveradres benodigd is, en dat "per Rittijd";
ofwel Debiteur "Timac" staat 2x vermeldt in bovenstaand voorbeeld, omdat ze voor 2 verschillende ritten orders open heeft staan (welke we afzonderlijk van elkaar zouden kunnen willen afhandelen).
Nb: Alle regels, op 1 na, tonen een afbeelding van een kassa in kolom "Soort". Dit, om aan te geven dat het hier om een verkoop gaat, ofwel, dit zijn uitgaande behoeftes a.g.v. Verkooporderregels (zijnde de regels waarvoor wij moeten gaan reserveren). De 5e regel op het scherm toont een afbeelding van 'gereedschap', en impliceert een bewerking, een Produktie-/Omvorm Opdracht die ook input nodig heeft. Hoeveel we ook zouden kunnen wensen dat we voor dergelijke orders gaan reserveren, is dat geen onderdeel van dit ontwerp. Wel tonen we de regel in het overzicht, en kan ze geselekteerd worden, maar puur als tool om aan te geven dat we dié order voorrang willen geven, en het systeem de beschikbare TV te laten verminderen met de hoeveelheid van die order; immers, als we vinden dat we de voorraad moeten gebruiken voor die Produktie-/Omvorm order, hebben we minder over om te kunnen toe te kennen aan onze klanten.
Terug naar "Raadplegen te leveren Artikelen"...
We hebben 320 Verschijningen op voorraad, en verschillende Afleveradressen aan welke we die kunnen toekennen. Alle regels zijn nu "groen" omdat we iedere regel afzonderlijk volledig kunnen "reserveren" uit de beschikbare 320V. Echter, zodra we een regel selekteren (vastzetten), en zeggen "die moet gereserveerd worden uit de beschikbare 320V", heeft dat gevolgen voor de resterende regels.
De regels worden gesorteerd op
Prioriteit zoals aangegeven bij de eerdergenoemde Listmover control. Per prioriteit wordt e.e.a. vervolgens weer getoond per Rit, omdat bij een gelijke prioriteit, iets wat eerder de deur uit moet vast belangrijker zal zijn dan iets wat later de deur uit moet. Merk op dat het overzicht zoals hier getoond is eigenlijk niet representatief is, immers, het is 1 week vooruit opgevraagd, en we hebben ook nog eens niet voldoende voorraad om alles te kunnen doen. De order van Timac van 14-09 wordt eerder getoond dan een order van Westerhoff van 06-09, waarmee we nu dus zullen uitlokken dat we voorraad gaan reserveren voor een klant die pas volgende week beleverd hoeft te worden, en daardoor een andere klant niet kunnen leveren. De fout is hier dan dat we het overzicht te ver in de toekomst hebben opgevraagd (Routegroeptijd ligt tever vooruit).
Voor het voorbeeld selekteren we nu als eerste "Mi Kwang Sun"; dit doen we door op de button met het rode kruis te clicken op de regel waarin dit Afleveradres wordt getoond.
De beschikbare voorraad neemt af met 128V tot 192V.
De prioriteit wijzigt in #00001; alle regels met een # ervoor impliceren 'vastgezette regels', en zijn vastgezet in de volgorde van het nummer wat erachter staat. Dat nummer heeft dus niets meer met de oorspronkelijke Prioriteit uit de Listmover te maken. Een vastgezette regel komt ook altijd bovenaan te staan, d.w.z. boven de regels die nog niet vastgezet zijn. Om dat wat duidelijker te maken selekteren we nu de 64V van Westerhoff op Afleveradres 1.
Dit Afleveradres verschuift vervolgens naar boven, en wel op de 2e plaats;
de Beschikbare TV vermindert met 64 tot 128V.
Als 3e selekteren we de order van Timac (96V). Hierdoor vermindert de beschikbare TV tot 32V, en dan beginnen we regels 'rood' te zien kleuren.
Van de nog niet vastgezette regels kunnen we er twee (Vallermosa en de Produktieorder) voor 100% reserveren. Echter, de orders van Timac en Westerhoff kunnen slechts voor een deel gereserveerd worden. Ofwel, als we de orders leveren zoals bovenstaand, zien we dat we Timac en Westerhoff niet kunnen uitleveren. "Rood" is hier kwa kleur nog een stukje erger dan oranje, immers, bij oranje geldt hooguit dat er "nu" niet gereserveerd kan worden, maar later in de tijd wel, omdat er al een inkomende behoefte (Inkooporder) is die dekkend zal zijn voor de te reserveren hoeveelheid. Rood toont aan dat er ook geen voorraad verwacht wordt, en dus zal er straks echt iets foutlopen als er geen aktie wordt ondernomen.
Over deze kleuren kunnen we nog veel meer voorbeelden geven, maar, beter is dit zelf te ervaren door ermee te spelen.
Voor mijn voorbeeld selekteer ik nog even de laatste order van Westerhoff, welke voor maar 32/96e deel gereserveerd kan worden.
Wellicht is het al opgevallen dat zodra we meerdere regels geselekteerd hebben, achter die regels pijltjes toetsen komen te staan. Middels deze pijltjes toetsen kunnen we regels "verschuiven". Hierdoor ontstaat het effekt dat we met selekteren kunnen aangeven hoe belangrijk we een order vinden, maar dat we middels verschuiven toch kunnen zeggen dat we een ander Afleveradres eerst willen doen. Stel dat we de laatste order van Westerhoff verder naar boven zouden verschuiven, dan blijft de maximaal te reserveren hoeveelheid 32V (waar als we de order eerst zouden selekteren dit 96V werd), alleen geven we aan die 32V eerst te willen reserveren. We gaan dus niet 32V reserveren uit de 32V die overblijven nadat we #00001 t/m #00003 gedaan hebben, nee, we gaan die 32V als eerste reserveren uit de 320V die beschikbaar waren.
V.w.b. het "Reserveringsscherm" zijn we nu klaar. Het feit dat we hier hebben aangegeven voor welke Afleveradressen-/Ritten we wensen te reserveren heeft al "te reserveren opdrachten" gemaakt voor het Scanterminal scherm.
Let op:* AVK kombinaties zonder Voorraad worden niet weergegeven.Het doel van het Vulgraadscherm is om een 'produktverantwoordelijke' op pad te sturen om de aanwezige charges van een specifieke kombinatie Artikel-/Verschijning-/Kenmerken toe te kennen aan de orderregels die er voor die kombinatie zijn. Zodra er geen vooraad aanwezig is, vallen er geen Charges toe te kennen aan de Verkooporderregels. In theorie zouden we dan alsnog die produkten kunnen weergeven om expliciet aan te geven dat er nog geen voorraad van is (het geeft mogelijk een idee van wat er nog uit Goederen Ontvangst danwel Produktie-/Omvorming moet binnenkomen), maar, vooralsnog is gesteld dat we op het scherm alleen die regels tonen waarvoor ook daadwerkelijk iets gereserveerd kán worden (omdat er voorraad van is).
* Het Reserveren van een partij voor een VO regel respekteert géén Raapvloer !Al eerder is gesteld dat zodra we met Docks-/Afleggen / Cross Docking Rapen of Scannen aan het werk zijn, het niet meer is toegestaan om bij de Verkooporderregel een Raapvloer op te geven. Alhier een verdere uitwerking daarvan, omdat zoiets ook optreedt bij het 'Reserveren'.
In een gegeven situatie, wordt bij iedere Verkooporderregel een B2 Raapvloer ingevuld op basis van de 'markt' waarvoor het produkt bestemd is. Zo hebben we bijv. B2EUR (Europa), B2MOO (Midden Oosten), B2JAP (Japan) en B2USA (Amerika). Stel dat we Cross Docking gaan rapen, dan loopt een Raper langs diverse lokaties en haalt daar goederen op en legt ze op zijn/haar kar (= Raper Lokatie, bijv. RPHRT). Resultaat is dat als we vanaf deze kar de voorraad op orders gaan afboeken, die orderregels feitelijk geleverd (geraapt) worden vanaf die Raper Lokatie, die (uiteraard) niet overeen zal komen met een Raapvloer B2EUR t/m B2USA.
Derhalve is in dat ontwerp gesteld dat we nooit een Raapvloer bij een Verkooporderregel mogen invullen (behoudens misschien i.g.v. Externe Magazijnen), zodra we vrij zijn om voorraad vanaf iedere gewenste lokatie in te zetten.
Bij "Reserveren" treedt eenzelfde situatie op: Zodra produkten bij Goederen Ontvangst op voorraad komen (Lokatie GO000, en desnoods nog niet daadwerkelijk in een magazijnstelling zijn weggezet) moet het al mogelijk zijn om e.d. partij te reserveren voor een specifieke Verkooporder. De Lokatie GO000 komt dan al meteen niet overeen met de B2 Raapvloer van de Verkooporderregels.
Technisch krijgen we het natuurlijk best voor elkaar om bij het Reserveren-/Leveren de Raapvloer te 'negeren', en voorraad in te zetten die op een Lokatie ligt die niet overeenkomt met de Raapvloer. Maar, wat voor een effekt heeft dat? Wel, ten eerste, het is misschien krom dat we iets kunnen rapen vanaf een lokatie die niet voldoet aan de opgegeven Raapvloer, en, misschien zijn er wel overzichten (statistieken) met selekties op basis van de Raapvloer die er niet op anticiperen dat er vanaf andere lokaties geraapt kan zijn.
Het verplichten van het leeglaten van de Raapvloer lijkt veel meer problemen uit te lokken ! immers, daar kreëren we mee dat een Verkooporderregel die op B2EUR stond, nu geen Raapvloer heeft, en daarmee ook geďmpliceerd wordt dat het TouchScreen Leveren Verkooporder voorraad mag afboeken van een andere lokatie, zoals B2MOO of welke plek dan ook waar er voorraad is in het systeem. Dit haalt de hele voorraadadministratie op lokaties onderuit.
Het grote verschil zal hem in het
Scannen zitten. Het kon er wel eens op neerkomen dat de Raapvloer, zoals ingevuld bij de Verkooporderregel, mag worden gezien als een soort voorkeurs-raapvloer, welke altijd gerespekteerd dient te worden door processen die automatisch voorraad afboeken, maar zodra we daadwerkelijk een unieke partij op een specifieke lokatie gescand hebben, moeten we deze altijd kunnen inzetten, ook al komt die niet overeen met de opgegeven Raapvloer. Scannen overrulet daarmee de opgegeven Raapvloer.
Bij het Reserveren hebben we aan de ene kant hebben we orderregels voor Artikel-/Verschijning-/Kenmerk kombinaties. Zodra er ook maar een klein beetje voorraad aanwezig is voor e.d. kombinatie, maakt niet uit op welke Lokatie deze ligt, zal dit zichtbaar moeten worden in het Vulgraadscherm, opdat een produkt-verantwoordelijke de partij kan beoordelen en kan bepalen of, en op welke orderregel ze deze partij wil gaan inzetten. Hierbij mág de Verkooporderregel dus gewoon een Raapvloer B2EUR bevatten, maar zal het Vulgraadscherm expliciet op zoek gaan naar voorraad op alle lokaties (ok, met uitzondering Externe Lokaties).
Scanterminal Reserveren
Als we naar het Scanterminal Reserveren gaan (SCT Menu, 4, 8 ) dan selekteren we ook daar als eerste voor welk Raapstation we willen reserveren.
Naast reserveren kunnen we ook een gereserveerde partij weer vrijgeven (bijv. omdat we die aan een andere klant willen toekennen); daar verderop meer over.
Met F1 bevestigen we de selektie van het Raapstation, en wordt een overzicht getoond van de Artikel-/Verschijningsvorm-/Kenmerk kombinaties waarvoor gereserveerd moet worden. Het Scanterminal scherm pikt a.h.w. de op het TouchScreen scherm geselekteerde regels op.
In bovenstaand scherm wordt getoond dat we moeten reserveren voor Paprika Rood maat 70/90 klasse #1 uit NL, en voor Paprika Rood maat 80/100 klasse #1 uit NL.
Nb: Dit scherm respekteert de parameter of Artikelen op basis van Artikelnummer danwel o.b.v. Omschrijving moeten worden getoond;
veel ruimte is er niet, tenzij we de regel blokken groter maken, hetgeen dan weer ten koste gaat van het aantal regels wat we op 1 scherm kunnen tonen.
We selekteren het produkt waarvoor we willen reserveren door op de button te clicken voor het Artikelnummer.
Click ik op de PRO80/101NL, zoals in bovenstaand scherm behandeld, dan toont het Scanterminal scherm de Afleveradressen die we op het TouchScreen scherm hebben vastgezet, en wel in de volgorde zoals daar aangegeven.
Vervolgens dienen we een Afleveradres te selekteren, en gaan we op zoek naar mooie partijen die voor dat Afleveradres geschikt zijn. In principe is op het TS scherm al de volgorde bepaald, en dienen we op het Scanterminal scherm de lijst van boven naar beneden af te werken. Maar, als we willen, mógen we hiervan afwijken, en kunnen we eerst een ander Afleveradres selekteren. Dit kan bijv. aan de orde zijn omdat we niet op zoek gaan naar geschikte partijen voor een Afleveradres, maar omdat we bijv. bij een specifieke partij staan en vinden "dit is wel een geschikte partij voor Timac". In dat geval selekteren we eerst Timac, en scannen we vervolgens de partij waar we naast staan.
Ervanuitgaande dat we e.e.a. afhandelen zoals bedoeld, selekteren we als eerste de bovenste.
Zoals aangegeven hebben we vrij weinig ruimte op zo'n klein scherm, en moeten er keuzes gemaakt worden m.b.t. de informatie die getoond wordt. Omdat ook in de situatie dat "Artikelnummers meer aanspreken dan Artikelomschrijvingen" niet alles 100% duidelijk hoeft te zijn, hebben we eerst een "overzicht" scherm opgenomen. Hierop worden de NAW gegevens getoond van het geselekteerde Afleveradres, wordt de Artikel-/Verschijning (en eventueel Kenmerken) opgesomd, en wordt de Rittijd t/m wanneer gereserveerd moet worden getoond. Dit tabblad dient met F1 te worden bevestigd.
Na het overzichtscherm volgt er in principe een tabblad met een keuze voor een specifieke Verkooporderregel (we reserveren immers op Verkooporderregel niveau; een regel wordt naar een Raaplijst gestuurd). In veel gevallen (zoals in dit voorbeeld) geldt dat er maar 1 bestelling is voor een specifieke Rit, en wordt dit scherm overgeslagen. Het orderscherm verschijnt dus alleen indien er meerdere orderregels zijn voor het betreffende Afleveradres (zie verderop). Voor dit voorbeeld gaan we dus meteen naar het reserveren van de V-items.
Het voorraad tabblad toont boven in het scherm een overzicht met de aanwezige voorraaditems. Deze zijn gesorteerd per Lokatie, en vervolgens wordt per Charge weergegeven hoeveel ervan op voorraad ligt, en met welke "aantallen".
Heel belangrijk binnen dit ontwerp is dat het uitgangspunt is dat we met
Subcharges per Pallet werken, en dat één Subcharge uniek is voor een (deel van een) pallet, die we óf in zijn geheel toekennen aan een order óf helemaal niet. Willen we een deel van een pallet toekennen aan een order dan zullen we het scherm moeten verlaten en zullen we de partij eerst formeel moeten
Splitsen, waarbij er een nieuwe Subcharge ontstaat voor het gesplitste deel. Een simpele scan zou dus voldoende moeten zijn om een partij voor een klant te reserveren; het reserveren van een deel van een partij is niet mogelijk.
Nu nogmaals kijkend naar het voorraadoverzicht, zien we op de 1e regel dat we 3x32 Verschijningen hebben; ofwel 3 partijen (pallets) van ieder 32 Verschijningen, en met de Subcharges L28T0020101 t/m .. 03 (L28T0020103). Middels de ..03 of ..10 wordt aangegeven dat er series van opvolgende Subcharges (pallets) bestaan, zodat we deze makkelijker kunnen selekteren.
De cursor staat te knipperen in de Barkode control, en vraagt ons feitelijk om 'partijen' te scannen die we willen reserveren voor het geselekteerde Afleveradres. Rechts onderin het scherm zien we 96 / 0 staan. De 96 betreft de nog te reserveren hoeveelheid (als we hetgeen gescand hebben verwerken), de 0 staat voor het aantal in dit scherm geselekteerde Verschijningen (en die verwerkt worden nadat we op F1 hebben gedrukt). Omdat we nu nog geen partijen gescand hebben staat dit op 96 (te reserveren) / 0 (geselekteerd).
We gaan op zoek naar een mooie partij voor deze klant. Als we zelf niet weten waar we deze partijen moeten vinden, zal de Lokatie in het overzicht ons kunnen navigeren naar de lokaties waar we voorraad zouden moeten hebben, opdat we vervolgens de partijen kunnen beoordelen. Partij L28T0020105 lijkt wel een mooie partij, en dus scannen we deze.
Ook al is de partij nog niet "verwerkt", het scannen van de partij zorgt er al voor dat de 96/0 wordt bijgewerkt naar 64/32. Dit moeten we lezen als "als we nu op F1 drukken zullen we nog 64V moeten reserveren; in deze selektie hebben we 32V geselekteerd".
Onder de Barkode control zien we nog een spinner. Deze is standaard gevuld met het Subchargenummer welke geďmpliceerd wordt door de gescande Charge. In dit geval 05 omdat we partij L28T00201
05 scanden. Dit maatwerk is ontwikkeld in een omgeving waar vnl. volle pallets verkocht worden, en in grote hoeveelheden. Om nu te voorkomen dat als we 20 pallets tegelijk verkopen, we ook 20 pallets moeten scannen, is hier een Subcharge-spinner opgenomen, waarmee we de scan op de 1e Subcharge (05) kunnen uitbreiden met t/m Subcharge xx. In plaats van dus een 2e pallet te moeten scannen, kunnen we simpelweg 1x op de > button drukken.
De Subcharge-spinner bevat nu 6, waarmee we de selektie van Subcharge L28T00201
05 t/m L28T00201
06 impliceren. We moeten dan nog 32V selekteren, en hebben 64V geselekteerd.
Door nogmaals op de > te drukken selekteren we nog een pallet erbij.
en hebben we alles geselekteerd wat gereserveerd moet worden.
Nb: Merk op dat het voorraadscherm wordt ingedeeld per "hoeveelheid per pallet" om zodoende mede op zoek te kunnen gaan naar pallets met geschikte hoeveelheden voor de gewenste klant. "Niet hoeven te splitsen" zou nl. ook kunnen meegeven in de keuze voor de te selekteren partij.
Met F1 verwerken we onze selektie. De 3 geselekteerde partijen worden vervolgens gereserveerd voor deze order.
Omdat we vervolgens niet meer orders hebben voor dit Afleveradres, zijn we voor dit Afleveradres klaar. We keren terug naar het overzicht met Afleveradressen van de geselekteerde AVK, en kunnen met het volgende Afleveradres verder gaan. Deze procedure herhaalt zich tot alles gereserveerd is.
Voor Debiteur Timac hebben we overigens meerdere orders open staan. Zouden we deze selekteren dan zien we het eerder genoemde orderoverzicht.
en zullen we moeten aangeven voor welke order we willen reserveren.
Systeemtechnisch kunnen we nu wel een partij reserveren voor een specifieke klant (Afleveradres), maar, in praktijk moet ook zichtbaar zijn dat de partij "gereserveerd is" en niet mag worden geraapt. Hiervoor hadden we een systeem met "paarse kaarten" bedacht. Zodra we een pallet reserveren voor een klant, plakken we een paarse kaart op de pallet. Het feit dat er een paarse kaart op de pallet zit geeft vervolgens aan dat die pallet gereserveerd is.
Voor wie de pallet gereserveerd is staat op zich niet op de kaart, maar "weet het systeem natuurlijk wel op te hoesten".
Ook zal het vast wel handig zijn dat je meteen aan de paarse kaart kan zien voor wie het gereserveerd is, maar, dat zou dan weer impliceren dat zodra een partij voor iemand gereserveerd is, op dát moment een paarse kaart bedrukt moet worden met de NAW of Ordergegevens van die klant, hetgeen weer erg bewerkelijk is (er moet steeds iemand naar de printer lopen om de bedrukte kaart op te halen). Derhalve, een blanco kaart voldoet ook.
Nb: De kaart mag natuurlijk ook best een andere kleur hebben dan paars ;-)
Nb2: Voor zoekdoeleinden op het forum; in het oorspronkelijke ontwerp werd de persoon die de "paarse kaarten" op de pallets plakt een "Pimpel" genoemd.
Op enig moment kan de situatie ontstaan dat we bij een partij aankomen en denken "hey, dat is een mooie partij voor Mi Kwang Sun", echter, er zit al een paarse kaart op de pallet, ofwel, de pallet is al gereserveerd. Op het 1e tabblad konden we naast het selekteren van een Raapstation, ook op een "Vrijgeven" button clicken.
Als we dat doen, verschijnt er een tabblad waarin we een partij kunnen scannen.
Het systeem toont ons vervolgens voor wie deze pallet gereserveerd is.
Ook hier kan het gescande Subchargenummer worden verlengd t/m een hoger (aansluitend) Subchargenummer van deze Hoofdcharge. Met F1 wordt de reservering ongedaan gemaakt. D.w.z., waar we met "Reserveren" de Voorraaditems naar de Raaplijst van die Verkooporder stuurden, halen we ze met "Vrijgeven" weer van deze Raaplijst af. De partijen komen daarmee weer vrij op voorraad, en we kunnen ze vervolgens aan een ander Afleveradres toekennen. Tevens zal ook het "Te Reserveren" record weer worden heropend, immers, voor de klant waarvoor deze pallets gereserveerd waren zullen we nu opnieuw moeten gaan reserveren.
