Heart-Profit ERP

Touch Screen Weergeven Vulgraad Debiteur-/Route. (LOTSLVVG)

Nb: Onderdeel van het ontwerp "Rapen via Scan Terminal".

Op het TouchScreen Weergeven Vulgraad Debiteur-/Route wordt per Debiteur-/Route de "Vulgraad" weergegeven. "Vulgraad" is in deze gedefinieerd als de mate waarin de Verkooporders voor deze Debiteur-/Route volledig kunnen worden geraapt. "Debiteur" is hier eigenlijk niet juist, omdat we hiermee altijd een Debiteur in combinatie met het Afleveradres zullen bedoelen; voor het gemak zullen we het hebben over een "Debiteur".

Een Debiteur wordt (op zijn Afleveradres) geleverd volgens een schema zoals is opgesteld in het Master Routeplan. De produkten die de Debiteur voor een bepaalde levering besteld heeft, hoeven niet specifiek op 1 order besteld te zijn. Hij kan dit om verschillende redenen over meerdere orders verspreid hebben, bijv. omdat hij nádat hij een bestelling geplaatst heeft, besluit nog meer erbij te bestellen, hetgeen via een 2e order gebeurd.

Als we gaan rapen, is het uitgangspunt dat we de produkten van een Debiteur rapen voor een specifieke levering (Route met een Ritdatum-/tijd). De aanname is dat het nooit nuttig is om één Verkooporder (of één Raaplijst daaruit) te gaan rapen, en dat het juist altijd nut heeft om alle orders van die Debiteur voor de betreffende Route ineens te gaan rapen. Problematiek die hierbij komt kijken is dat niet alle voorraad die geleverd moet worden ook meteen op voorraad aanwezig is. Natuurlijk is het uitgangspunt dat we uiteindelijk altijd zullen leveren wat er besteld is, immers, op basis van de bestellingen zullen we hebben ingekocht. Echter, de Debiteur kan verschillende produkten bestellen, die bij verschillende Leveranciers ingekocht worden, en welke Leveranciers hun goederen op verschillende tijden gedurende de dag zullen leveren. Stel dat een Debiteur én melk én kaas besteld heeft, en beide via Raaplijsten geraapt worden, dan kan het zijn dat de kaasboer al wel geleverd heeft, en de melkboer niet. Hierdoor kunnen alle orders v.w.b. de kaas wel uitgelopen worden, maar kunnen orders die melk besteld hebben hooguit worden uitgelopen voor het deel wat nog uit voorraad geleverd kan worden.
Voorheen kwam dit eropneer dat bijv. eerst een Raaplijst werd geprint met kaas erop, deze werd uitgelopen, en later op de dag nogmaals een ronde voor dezelfde Debiteur-/Route moest worden gelopen maar dan t.b.v. de melk.

Het Vulgraadscherm is bedoeld om inzicht te geven in de mate waarin de produkten voor een Debiteur-/Routes geraapt kunnen worden, waarbij de bestelde hoeveelheid wordt afgezet tegen de beschikbare voorraad, en resulteert in een beschikbaarheidspercentage: de vulgraad.  Hoe hoger de Vulgraad, des te meer nut het heeft de orders van deze Debiteur-/Route te gaan rapen. Zouden we een regel met 100% Vulgraad gaan rapen, dan weten we zeker dat we voor deze Debiteur-/Route niet nog een ronde hoeven te lopen. Het TS Scherm sorteert de regels dan ook in eerste instantie op deze Vulgraad, waarbij de regels met het hoogste percentage bovenaan staan.

Na de Vulgraad zal er worden gesorteerd op Raapload. De Raapload van een Debiteur-/Route wordt berekend door de som van de te rapen hoeveelheid van de onderliggende Verkooporderregels te vermenigvuldigen met het aantal Raaploadunits zoals opgegeven bij de betreffende Artikel-/Verschijning. Ofwel, per gelijk percentage komen de orders die het meeste werk (tijd) vergen bovenaan te staan.

Nb: Indien er bij de Artikel-/Verschijning geen Raaploadunit is opgegeven, zal worden gerekend met de waarde 1.


De Debiteur-/Route regels krijgen afhankelijk van het Vulgraadpercentage een kleur toegekend:

Groen = 100% Vulgraad.
Geel   = Voldoet aan opgegeven "raapgrens"
Rood  = Vulgraad ontoereikend

Hierover straks meer...


Alvorens tot een konkreet voorbeeld over te gaan, eerst nog een aantal instellingen, die we terugvinden op het eerste scherm zodra we het TouchScreen Vulgraad scherm opstarten:

(http://www.heartprofit.com/www/transfer/graphics/forum/lotslvvg080620001.png)


Routes verwerken van route-groep

Hiermee kunnen we aangeven van welke "route-groep" we de Debiteur-/Routes met hun vulgraad willen zien. Een "routegroep" is een groep Routes welke allen een vertrektijd hebben welke ongeveer gelijk is. Iedere route welke met een vertrektijd is gedefinieerd korter dan 1 uur t.o.v. de vorige route, behoort toe tot dezelfde routegroep. Ofwel, een route van 09:30 hoort bij de routegroep van 10:00 omdat die rit binnen de grens van 1 uur ligt. Een route van 09:15 hoort er ook bij. En, een eventuele rit van 08:45 ook, ervanuitgaande dat er om 09:30 of 09:15 een rit gedefinieerd was, immers dan ligt ze alsnog binnen 1 uur t.o.v.de vorige.
Uitgangspunt hierbij is dat routes ingedeeld zijn in groepjes, en dat er (op basis van deze marge van 1 uur) onderscheid valt te maken tussen routes die om 06:00 vertrekken, om 10:00 danwel 15:00 's middags.
Routes die gedefinieerd zijn ná de datum-/tijd van de opgegeven routegroep worden niet getoond. Ofwel, een route van 10:15 hoort niet bij de routegroep van 10:00, omdat ze ná 10:00 plaatsvindt. Wel zijn we weer vrij om in zo'n geval als routegroep 10:15 te kiezen, in welk geval 10:00 daar weer bij hoort, vervolgens 09:30 ook, 09:15 ook, en 08:45 ook weer.

Doel van de routegroep is op te kunnen geven dat er vooruitgewerkt moet worden voor a.s. maandag 06:00, zonder dat we daarbij de orders van vrijdag of zaterdag in het scherm willen zien.


Data verversen met interval

De gepresenteerde informatie betreft een moment opname. In principe kan deze situatie een seconde later al weer anders zijn. Gedurende de dag komen er nieuwe bestellingen bij, vervallen er bestellingen, wordt er voorraad geleverd, verbruikt, waardoor de status anders kan worden. Middels deze rubriek kan worden aangegeven dat xxx seconden nadat het overzicht is opgebouwd, de gegevens opnieuw berekend moeten worden. Indien deze rubriek met 0 wordt gevuld, worden de gegevens niet bijgewerkt.

Indien het scherm automatisch ververst wordt, kunnen gebruikers van afstand o.b.v. de toegekende kleur (groen, geel, rood) zien of er nieuwe Debiteur-/Routes bijgekomen zijn welke interessant zijn om te gaan rapen.


Rapen toegestaan vanaf vulgraad % ("raapgrens")

Regels die voor 100% geraapt kunnen worden, zullen altijd in het groen worden weergegeven. Regels die niet voor 100% geraapt kunnen worden zijn in principe rood. Middels deze rubriek kan worden aangegeven dat orders vanaf dit percentage (in dit voorbeeld 85%) ook interessant genoeg zijn om te mogen worden geraapt. De regels die boven dit percentage uitkomen worden in het geel weergegeven (waarbij 100% altijd groen blijft).


Regels op Opdrachtblad weergeven

Deze rubriek vereist eerst meer uitleg over wat een Opdrachtblad precies is, maar in het kort: zodra van een Debiteur-/Route wordt aangegeven dat ze geraapt mag worden, wordt er een Opdrachtblad gegenereerd-/geprint.  Een Debiteur-/Route waarvoor een (openstaand) Opdrachtblad bestaat, zal niet meer worden weergegeven in het vulgraad scherm. Middels deze rubriek kan worden aangegeven dat de regels die op een Opdrachtblad staan alsnog dienen te worden weergegeven (en binnen de normale sortering). Die modus is bedoeld om een Debiteur-/Route regel te resetten. Het eerder geprinte Opdrachtblad wordt hiermee ingetrokken, en zodra er opnieuw een (normaal) overzicht wordt opgevraagd zal de Debiteur-/Route er weer bij staan.


Respekteren Cross Docking indikator

Bij een Artikel-/Verschijning is een rubriek "Cross Docking Rapen J/N" opgenomen.  Van produkten die Cross Docking geraapt moeten worden zal  een grotere hoeveelheid van voorraad worden geraapt, welke vervolgens over de verschillende docks wordt afgelegd bij de verschillende Debiteur-/Routes die behoefte aan  het produkt hebben.  Voor deze Artikel-/Verschijningen geldt dat ze in eerste aanleg niet "meedoen" met het Rapen van Debiteuren-/Routes.
Als bijv. van melk is gesteld dat deze Cross Docking geraapt moet worden, zal een Debiteur-/Route die niet op 100% uitkomt omdat er niet voldoende melk is, alsnog op 100% kunnen komen te staan, immers, de melk doet ineens niet meer mee, en telt dus ook niet mee in de berekening van de Vulgraad. Deze rubriek is vervolgens bedoeld om aan te kunnen geven of de Cross Docking Rapen Indikator moet worden gerespekteerd J/N, ofwel, hiermee kunnen we er op enig moment voor kiezen om de melk via een Raaplijst te gaan rapen, en vervolgens 80% te zien, omdat er niet voldoende melk is.

Via een button "Vulgraad" op het 1e scherm wordt het daadwerkelijke Vulgraadscherm getoond.

(http://www.heartprofit.com/www/transfer/graphics/forum/lotslvvg080620003.png)


Een simpel voorbeeld:

Op voorraad staan 10 pakken melk.

Restaurant Tojaco bestelt 5 pakken melk. Deze kunnen uit voorraad geleverd worden, en dus is de vulgraad 100%. Deze regel wordt in het groen weergegeven.

(http://www.heartprofit.com/www/transfer/graphics/forum/lotslvvg080620002.png)

Iedere regel in het scherm is representatief voor één Debiteur-/Route, of strikt genomen, één Debiteur+Afleveradres i.c.m. een specifieke Rit (Route op een Ritdatum).


Een 2e bestelling van 3 pakken melk door een ander restaurant, kan ook uit voorraad geleverd worden, en daarmee is ook die regel groen. Dit maal echter een iets andere kleur groen, omdat de regels om en om iets van kleur verschillen, om duidelijker het verschil zichtbaar te maken van alles wat bij een regel hoort.

(http://www.heartprofit.com/www/transfer/graphics/forum/lotslvvg080620004.png)

Komt er vervolgens een 3e bestelling binnen voor een andere klant die eveneens 3 pakken melk besteld, dan hebben we nog maar 2 pakken beschikbaar. Deze order kan dus voor 2/3e deel geraapt worden, en heeft een Vulgraad van 66,7%

(http://www.heartprofit.com/www/transfer/graphics/forum/lotslvvg080620005.png)

De regel is rood, omdat het percentage onder de ingestelde "raapgrens" van 85% uitkomt. Zou de order nog meer produkten bevatten waardoor de vulgraag boven de 85% uitkomt, dan zal deze regel in het geel worden weergeveven.

Merk op dat in de eerste kolom (Vulgraad) naast het Vulgraadpercentage er nóg een percentage wordt weergegeven:

(http://www.heartprofit.com/www/transfer/graphics/forum/lotslvvg080620006.png)

Dit 2e percentage geeft aan voor hoeveel procent de order geraapt zou kunnen worden als we deze nú volledig zouden gaan rapen, daarmee niet rekening houdend met wat er door het systeem is toegekend aan de andere orders. In werkelijkheid liggen er nu 10 pakken op voorraad, en de 3e (rode) order heeft er maar 3 nodig. Stel dat we deze order nú zouden willen gaan rapen, dan kan dit voor 100%. Hoewel we ervoor kunnen kiezen om dit te doen, is het de vraag of we dit moéten doen.
Bij de opbouw van het Vulgraad scherm zal het systeem zelf de aanwezige voorraad intern reserveren-/toekennen aan de orders die het eerst geleverd moeten worden; de orders met de oudste leverdatum-/tijd. Dit, omdat iemand die alleen op maandag en vrijdag geleverd wordt, en maandag een backorder had, welke voorraad er dinsdag weer is, niet gekonfrontreerd wordt met het feit dat ze vrijdag weer niets geleverd krijgt omdat de ontvangen voorraad dinsdag, woensdag en donderdag al aan andere klanten geleverd is.
Een order met een vulgraadpercentage van 100% heeft een vulgraad van 100% mede "omdat ze aan de beurt is". Als, zoals in dit voorbeeld, alle 3 klanten voor dezelfde levering besteld hebben, zal de voorraad worden toegekend op basis van het ordernummer (wie het eerst komt, die het eerst maalt).

Kijken we wat nauwkeuriger naar de kolom "Route":

(http://www.heartprofit.com/www/transfer/graphics/forum/lotslvvg080620007.png)

dan zien we dat aldaar de Route, de Ritdatum-/tijd maar ook het Dock (en mogelijk de Dockrij) getoond worden. Via de gegevens uit het Master Routeplan is per Route, per Ritdatum bekend op welk Dock deze Route geladen moet worden. Als er al goederen voor deze Route klaargezet zijn, zal iemand eerder een Dockrij geselekteerd moeten hebben uit de beschikbare pool van Dockrijen. In dat geval wordt de omschrijving van de Dockrij gepresenteeerd (zie de Nijmegen route).

Opdrachtblad

Iedere regel, waarvan het tweede percentage hoger is dan 0% bevat een button "Printen Opdrachtblad". Het clicken op deze button impliceert dat we de betreffende Debiteur-/Route willen gaan rapen. Het systeem genereert een identifikatie welke representatief is voor Debiteur+Route, en kent een volgnummer toe, tesamen vormen die twee het Opdrachtblad. Alle goederen die voor deze Debiteur-/Route geraapt moeten worden, worden formeel gereserveerd (door formeel Raaplijsten aan te maken voor de onderliggende orders). Die Raaplijsten worden vervolgens gekoppeld aan het Opdrachtblad, opdat altijd bekend is welke Raaplijsten bij het Opdrachtblad horen.

Vervolgens wordt het Opdrachtblad geprint. Een Opdrachtblad bevat eigenlijk niet veel meer dan een barcode die gescand kan worden, en representatief is voor het Opdrachtblad, en daarmee alle Raaplijsten die door dat Opdrachtblad geïmpliceerd worden. Middels een Scan Terminal scherm zullen de produkten van de Raaplijsten van een Opdrachtblad kunnen worden geraapt. Het Opdrachtblad drukt tevens nog wat algemene gegevens af, zoals Debiteur, Route en Raapload. Het Opdrachtblad bevat zelf nooit de te rapen Artikelen (die info is immers al snel achterhaald).

Zodra er voor een Debiteur-/Route een Opdrachtblad is gegenereerd, zal de betreffende regel in het scherm niet meer zichtbaar zijn (doch zie de uitzondering met rubriek "Weergeven regels op Opdrachtblad J/N"). Indien het Vulgraadscherm bij een nieuwe berekening nieuwe (raapbare) orderregels tegenkomt voor een Debiteur-/Route waarvan reeds (of nog) een openstaand Opdrachtblad bestaat, dan zullen deze regels automatisch aan het laatste openstaande Opdrachtblad worden toegevoegd.
Merk op dat het niet verplicht is om hiervoor het Vulgraad scherm continue aktief te hebben, het zou ook handmatig mogelijk zijn om regels toe te voegen aan de Raaplijst die reeds aan het Opdrachtblad is gekoppeld, waarna ook de nieuw aan de Raaplijst toegevoegde regels op het Scan Terminal scherm zullen verschijnen.

Onderstaand heb ik voor de 2e regel (Route Nijmegen) een Opdrachtblad gegenereerd, waarna deze Debiteur-/Route verdwijnt uit het overzicht.

(http://www.heartprofit.com/www/transfer/graphics/forum/lotslvvg080620008.png)

Via button "Instellen" kan ik weer terugkeren naar het 1e scherm, alwaar ik de instellingen kan wijzigen, om vervolgens een nieuw overzicht op te vragen.

(http://www.heartprofit.com/www/transfer/graphics/forum/lotslvvg080620009.png)

Zou ik er nu voor kiezen om de regels die op een Opdrachtblad staan te tonen,

(http://www.heartprofit.com/www/transfer/graphics/forum/lotslvvg080620010.png)

dan komen de regels die reeds op Opdrachtbladen staan gewoon weer terug in het overzicht, en wel op dezelfde plek (zelfde sorteervolgorde) als ware ze nooit naar het Opdrachtblad gestuurd. In deze modus is nu een button "Reset" opgenomen bij die regels (Debiteur-/Routes) waarvoor reeds een Opdrachtblad is gegenereerd. Clicken we op de reset button, dan zal zullen de Raaplijsten horende bij dit Opdrachtblad worden geannulleerd, en zal het Opdrachtblad worden afgesloten. Als op een later moment de Debiteur-/Route alsnog weer een Opdrachtblad geprint gaat worden, dan zal dit Opdrachtblad een ander volgnummer kennen dan het eerste. Het eerste Opdrachtblad is afgesloten.
Merk op dat zodra een Opdrachtblad gegenereerd is, deze direkt geprint wordt, en het intrekken van een Opdrachtblad niet het reeds geprinte overzicht ongedaan kan maken. Anders geformuleerd, iemand kan met een Opdrachtblad rondlopen, deze scannen, en moet vervolgens kunnen zien dat hij niets meer te doen heeft (omdat het Opdrachtblad is ingetrokken). Hieruit volgt dat als er opnieuw een Opdrachtblad gegenereerd wordt voor dezelfde Debiteur-/Route, dit een ander volgnummer moet betreffen.

Volgnummers zullen ook kunnen ontstaan als gevolg van funktionaliteit waarmee een Opdrachtblad geplitst wordt in tweeën; bedoeld om een Debiteur-/Route die voor 1 persoon teveel tijd vergt, een 2e persoon bij te betrekken die met het gesplitste deel kan gaan lopen.

Nb: De limiet staat op dit moment op maximaal 999 volgnummers van 1 Opdrachtblad, hetgeen ruim voldoende moet zijn. Echter, 999 keer een Debiteur-/Route naar een Opdrachtblad sturen en deze vervolgens weer te resetten, resulteert er wel in dat je door je volgnummers heen bent. Vandaar deze enigzins hoge limiet, om nog enigzins wat speling te hebben, waarmee speling vooral niet verward moet worden met "spelen", want ergens houdt het op.

Nb: Merk op dat een overzicht inklusief de regels die op Opdrachtblad staan, ook gebruikt kan worden om te kijken welke Opdrachtbladen er nog in omloop zijn. Bijv. om te kijken hoeveel personen hun opdracht nog moeten uitlopen alvorens een route klaar is.


Alleen Rapen in Verschijningen

Zodra er een Opdrachtblad wordt gegenereerd, zullen de te rapen regels formeel op een Raaplijst worden gereserveerd. Een Raaplijst reserveert de voorraad, om ervoor te zorgen dat deze nog aanwezig is zodra de Raper op de betreffende Lokatie aankomt. Reserveren geschiedt op het niveau van een Voorraaditem; het is niet mogelijk om een déél van een Voorraaditem te reserveren op een Raaplijst. Raaplijsten lenen zich derhalve niet om "bulk" hoeveelheden te reserveren-/rapen. Ook bij normale bulkleveranties, gebeurt dit buiten de Raaplijst om (bijv. door dit rechtstreeks uit voorraad af te boeken).

Het Touch Screen scherm "Leveren Verkooporder" is wél in staat om "bulk" te leveren, omdat aldaar een bulkhoeveelheid eveneens rechtstreeks uit de voorraad wordt afgeboekt; dit wordt niet eerst op een Raaplijst geplaatst. Dat zelfde TS scherm is ook aangepast m.b.t. het leveren van een bulk hoeveelheid, welke uit een andere Verschijningsvorm mag worden afgeboekt; zo kan een klant 2,5 Kg andijvie bestellen, terwijl er op voorraad alleen maar kisten van 6 Kg liggen.  Ditzelfde trucje is niet mogelijk via een Raaplijst.

Het Opdrachtblad (en daarmee de berekening van de Vulgraad) werkt derhalve alleen met Verkooporderregels die in "Aantal Verschijningen" geraapt kunnen worden; regels in eenheden worden niet verwerkt. Dát er regels zijn die niet verwerkt worden wordt in het scherm zichtbaar gemaakt via onderstaande regel:

(http://www.heartprofit.com/www/transfer/graphics/forum/lotslvvg080623001.png)

Ook regels waarvan Debiteur-/Afleveradres niet in een Route zijn opgenomen, danwel waarbij er geen Ritinfo (koppeling met Dock op specifieke datum) is opgenomen zullen onder dit kopje worden vermeld.  Rechts op het scherm zal een uitroepteken worden geplaatst zodra er ongeldige regels, danwel regels zonder ritinfo aanwezig zijn. Dit, opdat het iets beter opvalt dát er regels zijn die niet verwerkt worden (en ter voorkoming dat deze regels straks helemaal niet geleverd zullen gaan worden).

(http://www.heartprofit.com/www/transfer/graphics/forum/lotslvvg080623002.bmp)

Nb: Geen onderdeel van dit ontwerp, maar middels aanvullend maatwerk uiteraard wel mogelijk: een print waarop wordt aangetoond welke regels er niet voldoen.


Backorders

Normaal gesproken geldt dat een Debiteur bestelt voor een specifieke levering. Ofwel, stel dat hij op maandag, woensdag en vrijdag beleverd wordt, dan zal hij bestellen voor een maandag, een woensdag of een vrijdag. Zijn bestelling zal automatisch worden toegevoegd aan de Rit die op die betreffende Leverdatum staat gepland conform het Master Routeplan.
Backorders worden anders afgehandeld: Backorders zullen (zonder verder ingrijpen) bij de eerst mogelijke levermogelijkheid worden uitgeleverd.  Produkten die we op maandag niet konden leveren, zullen v.w.b. bovengenoemde klant automatisch worden toegekend aan de woensdag route (en als een klant iedere dag wordt beleverd, zal gelden dat een backorder "morgen" met de levering meekomt). Een orderregel wordt als backorder behandeld zodra ze niet is afgesloten, de Rittijd reeds vertreken is, en de Rit niet op dit moment nog geladen wordt op een van de Dockrijen.
Zie ook http://ha1.heartprofit.nl/profit/index.php?topic=20380.0

NB: Overigens is het (via de normale Profit schermen) ook mogelijk om een regel buiten de TouchScreen-/ScanTerminal schermen om te rapen. I.g.v. "nood" is het op deze wijze altijd mogelijk een zending alsnog via een extra rit na te leveren, zonder dat deze rit eerst formeel ingepland hoeft te worden (inkl. Dockrij, afleggen etc.)


Potentie zonder te rapen via Scan Terminals

Hoewel bovenstaande funktionaliteit is ontwikkeld t.b.v. het Rapen via Scan Terminals, mag het zo lijken dat het scherm met enkele simpele aanpassingen ook gebruikt zou kunen worden voor andere doeleinden; Inmiddels zijn er diverse gebruikers die hun produkten rapen o.b.v. een kopie van de Verkooporder, en de levering vervolgens registreren via het Touch Screen Leveren Verkooporder. Ook in die situatie zou het scherm een welkome aanvulling kunnen zijn, immers, het scherm toont dan alsnog welke orders (Debiteur-/Routes) volledig geraapt kunnen worden. Hierbij kunnen we ons vervolgens maatwerk voorstellen waarmee i.p.v. een Opdrachtblad, juist de Verkooporder (= Raaplijst voor zie situaties) wordt afgedrukt, en waarbij op deze manier dit scherm alsnog een (of het) middel kan zijn om te bepalen welke orders het nuttigst zijn om te gaan rapen. Echter :
Omdat alles zich baseert op volledige real-time verwerking (denk maar eens aan het genoemde automatisch aanvullen aan een Opdrachtblad wat voor iemand met een scanner vanzelf onderweg als te rapen wordt voorgesteld), moet het toch het uitgangspunt zijn dat betreffende dan benodigde aanpassingen meer zijn dan simpel, of zelfs onmogelijk.

Ter info: Het Opdrachtblad welke (onder water) geprint wordt, stuurt een koppeling Queue-/Funktie aan v.w.b. Funktie LOPRZH.