Niets. Helemaal niets. Wat mij betreft dient niemand deze parameter te gebruiken. Ook : wat mij betreft werkt het niet goed als deze wel wordt gebruikt.

Een klant wilde dit zo hebben.

Staat in de helptekst niet dat deze niet gebruikt mag worden (in elk geval v.w.b. de laatste wijzigingen van een 6 weken terug) ? dan mag dat nog gebeuren.

Zie http://ha1.heartprofit.nl/profit/index.php?topic=20646.0

Dit betreft een toelichting op dit fenomeen.

Het is al wat langer geleden dat wij het bij Heart nodig vonden een "fenomeen" te verzinnen wat nog niet bestond, maar nu was het weer eens nodig. "Cross docking Rapen vanuit Voorraad" ... ehh, bestaat dat ?

Cross Docking wordt in de wandelgangen gezien als het meteen doorverladen van produkt uit Goederen Ontvangst naar het Leveren, of zo je wilt : van de docks bij Goederen Ontvangst naar de docks bij de uitgaande zijde.

Letterlijk genomen is dit zelden waarheid, omdat je immers slecht in staat bent (bijv.) pallet voor pallet uit de vrachtwagen van de leverancier te verplaatsen naar de vrachtauto die de routes naar de klanten rijdt. Verdere toelichting zal dit niet behoeven; er zijn voldoende redenen waarom dit feitelijk nooit mogelijk is. Althans, niet als basis principe in de zin van "wij doen niet anders". Onmogelijk (zeggen wij bij Heart).

Wat wèl mogelijk is, is dat er een aantal vrachtwagens klaar staan om te vertrekken richting de klant, er nog net op tijd een leverancier komt aanrijden, en dàn vanuit die vrachtwagen "Cross Docking" het produkt uit die vrachtwagen wordt uitgelopen naar de vrachtwagens voor de klanten.
N.b.: Als de vrachtwagens voor de klanten er nog niet zijn, dan hebben we altijd nog de gereserveerde ruimtes voor de plaatsen waar die vrachtwagens komen te staan, ofwel de docks. Het principe is hetzelfde, alleen er is in het algemeen meer tijd om vrachtwagens van de leveranciers te laten arriveren om de uitgaande docks te voorzien van het produkt. Let wel, feit blijft dat niemand zal kunnen stellen dat er 100% cross docking zal worden geleverd in deze, omdat -wil dit mogelijk zijn- er een dusdanige hoeveelheid tijd gaat zitten tussen het gereserveerd moeten hebben van het uitgaande dock en de uiteindelijke levering dat het dock intussen gebruikt had moeten worden voor een eerdere levering.

Een moeilijk verhaal ? denk er maar rustig over na. Tip : als je aan klanten toegewezen voorraad lokaties hebt (waarop dus nooit vrije voorraad staat) dan werkt het principe *wel*. Alleen ... dat zijn geen docks meer. Dit noemen we in Heart-Profit bufferlokaties.

Als we eraan denken dat je vanuit een ingaande vrachtwagen produkt distribueert naar uitgaande docks en dit "cross docking" noemt, maar we feitelijk niét stellen dat het distribueren naar klantlokaties ook zo wordt genoemd (lees : wie durft dat cross docking te noemen), kan je je afvragen wat er gebeurt als je (deels ook) voorraad aanhoudt, en dat op een gegeven moment gaat distribueren naar de docks, of zelfs naar bufferlokaties zoals hierboven bedoeld.

Duidelijker wordt het wanneer we het erover eens zijn dat er vanuit Goederen Ontvangst zelden rechtstreeks wordt doorgeleverd, en het produkt dùs op een voorraadlokatie komt te staan, om het vanuit dié voorraadlokatie te distribueren naar de docks. Is dit nou cross docking (leveren) of niet ?
Tja, als dit dat niet is, dan is niets het (behoudens het rechtstreeks overhalen van pallets van de ene vrachtwagen naar de andere ... wat dus feitelijk nooit gebeurt).

Of ... of benaderen we het verkeerd ?

De crux zit hem in de zojuist tussen haakjes genoemd "leveren";
Wat we in alle gevallen doen, is Cross Docking Leveren !
En verder kan gerust worden gesteld dat "Cross Docking" mag worden gelezen als "gekruisd over de docks lopen om het produkt af te leggen op de behoeftige docks".

Meer dient er niet in het fenomeen "Cross Docking" te worden gelezen, en we dienen ons hierbij niets aan te trekken van de mate waarin dit voorheen in de logistiek werd aangeduid als "vanuit de inkomende vrachtwagen naar de uitgaande vrachtwagen (c.q. docks)".


Nu we zover zijn, zien we wel dat we alvorens we kunnen Leveren, we ook moeten Rapen ... En het is hierin besloten dat er twee soorten Rapen bestaan in de context Cross Docking;

Als we produkt "cross docking" uitlopen over de uitgaande docks, doen we dit

ofwel vanuit de invalshoek dat produkt zojuist is binnengekomen (Goederen Ontvangst)
dan wel vanuit de invalshoek dat we voorraad aanhouden, en van daaruit de (cross docking dus) het produkt afleggen.

En het laatste is nieuw. Of zo je wilt, tot op heden niet expliciet onderkend.
Het bestaansrecht wordt als volgt omschreven :

Of je nu produkt uitloopt vanuit Goederen Ontvangst of vanuit Voorraad, in beide gevallen doe je dit omdat er efficiency zit in de methode van werken. Deze efficiency is expliciet, en staat lijnrecht tegenover het uitlopen "per order".

Om dit op zich te kunnen doorgronden - of zo je wilt erkennen, moet wel de aanleiding(en) tot het werken volgens de methode "Cross Docking Leveren" worden herkend (ja, we noemen het nu voor het leesgemak cross Docking Leveren);

Stel we hebben orders uitgelopen, maar niet alle orders zijn kompleet omdat er nog een leverancier moest binnenkomen, dan is het evident dat we op dat moment geen orders willen uitlopen. Dus, in Heart-Profit termen zou dit veelaal een 2e Raaplijst betreffen voor iedere verkooporder waarvoor plots produkt beschikbaar is, en je zou met bijvoorbeeld 30 nieuwe Raaplijsten aan de gang moeten om re Rapen vanuit de betreffende Goederen Ontvangst lokatie om het produkt vervolgens af te leggen bij de behoeftige dock posities. Betreft het inderdaad een 2e Raaplijst dan ligt er dus ergens al iets klaar voor de betreffende klant en moet het daar bij; betreft het een 1e Raaplijst dan lag er nog niets voor die klant, en mag een verse dock positie worden ingenomen voor het af te leggen produkt. Feit is : je bent 30 keer bezig met een handeling die ook in één keer kan : Cross Docking "Rapen". Inderdaad, nu noemen we het weer Rapen. Immers :

Er is behoefte aan bijvoorbeeld 120 van het ene produkt, je raapt dus die 120 in één keer, om het Cross Docking uit te lopen over de 30 orders (Raaplijsten) die er behoefte aan hebben. Desnoods zijn dat ook 30 klanten, die zich op x verschillende docks bevinden.
Wedden dat dit veel efficienter is ?

Die is dus duidelijk, en daarom bestaat feitelijk het fenomeen "Cross Docking" al "eeuwig".
Kan nu iemand vertellen wat het verschil is in efficiency met het Cross Docking Rapen uit Voorraad ?

Cross Docking Rapen uit Voorraad betreft dus het Rapen van in principe één produkt, zeg maar dezelfde 120 uit het voorgaande voorbeeld. Het aantal behoefte orders/Raaplijsten/klanten is eveneens hetzelfde, dus waarom niet dezelfde methode toepassen ?
Wel, dit zit hem in juist de overige produkten en wel die in kleinere aantallen moeten worden geleverd. Bijvoorbeeld, als er behoefte is aan flessen druivensap voor diabetici, zou het wel eens zo kunnen zijn dat slechts 2 orders zo'n fles behoeven. En, heb je 50 van dit soort produkten die in geringe mate behoeftig zijn, dan zou je dus 50 keer lopen van de voorraadstelling naar de docks. Niet erg efficient ...

Je kan aldus nooit zeggen dat je *alles* uit Voorraad Cross Docking raapt.
Het komt er domweg op neer dat je die produkten die je voor grote aantallen orders moet rapen het liefst Cross Docking raapt, terwijl je de produkten voor een gring aantal orders juist op order Raapt.

Vanuit de order (Raaplijst) gezien, kan aldus worden gesteld dat je eigenlijk nooit volledige orders raapt.
Al met al pas je beide methoden toe (Rapen op order - Cross Docking Rapen) opdat je voor het geheel de meeste efficiency bereikt.

N.b.: De vulgraadschermen zijn bedoeld om realtime hierin steeds de juiste keuze te kunnen maken (zie ook  Touch Screen Weergeven Vulgraad Debiteur-/Route alsmede TouchScreen - Weergeven Vulgraad Artikel-/Verschijningen.
Merk op dat met "realtime" wordt bedoeld dat dit van minuut tot minuut kan veranderen, en waar je bijvoorbeeld het ene moment orders aan het rapen bent omdat de grote hoeveelheden nog moeten binnenkomen, je op het andere moment die grote hoeveelheden niet wilt meenemen op dezelfde orders, maar die (eventueel parallel) Cross Docking gaat rapen.
Andersom mag ook : Als de Vulgraadschermen tonen dat er onvoldoende efficiency meer zit in het Cross Docking Rapen, ga je voor het overige produkt over op rapen op order.

Het zal duidelijk zijn dat de efficiency op zich wordt bepaald door de afstanden die moeten worden gelopen. Ofwel, hoe korter de afstand was die de orderpickers door een dag heen (gezamenlijk) hebben afgelegd, hoe beter het was. Ook zal het duidelijk zijn dat het gebruik van de beide methoden (door elkaar dus) 100% zeker een "beste efficiency" kunnen bewerkstelligen. Een handleiding om op voorhand te kunnen zien wat (iedere minuut anders !) het beste is, is er nog niet, maar deze zou in de loop der tijd kunnen ontstaan, namelijk op het moment dat we zien hoe e.e.a. uitpakt in welke situatie. Uiteindelijk is het ook het gevoel dat de orderpicker zelf heeft, en waarbij het al dan niet vol zijn van zijn trolly enz. al leidend kan zijn in de perceptie van efficiency.

Cross Shelving ?

Niet een werkelijk onderkend fenomeen, maar feitelijk wel aan de orde bij Cross Docking Rapen;
Denkend aan de zojuist genoemde mate van vol zijn van de trolly, kan je je meer ingewikkelder situaties voorstellen van het rapen van de 120 uit het eerdere voorbeeld, terwijl je intussen toch ook even die 2 flessen druivensap mee pak, a. omdat je toevallig toch langs het schap loopt waar ze staan, en b. omdat het nog op de trolly paste;

Om het geheel nog meer efficient te maken, dan wel de keuzes "wanneer pas ik welke methode toe ?" (is aan de orderpicker zelf overigens), is het domweg toegestaan om meerdere produkten tegelijk te rapen in de context Cross Docking. Al zijn het 100 verschillende produkten ...
Aldus hebben we in dat geval niet alleen te maken met Cross Docking (je weet, kruisend over de docks ...) maar net zo goed met Cross Shelving. Of anders gezegd, het systeem staat toe om je langs alle voorraadstellingen te leiden waar behoeftig produkt ligt. Sterker, als je die 120 raapt, toont het systeem die 2 flessen druivensap die er toevallig juist naast staan en eveneens behoeftig zijn.

Kom je in zo'n geval bij de docks aan met de 120 en de 2 flessen druivensap, dan vertelt het systeem je vanzelf wel waar je alles mag afleggen (volgens de gedefinieerde looproute), en ergens onderweg zal je ook die 2 flessen druivensap wel moeten laten vallen ...


Dan : Cross Docking Rapen vanuit Goederen ontvangst is normaliter middels bovenstaande gewoon gedekt, en daarmee dus niets anders als Cross Docking Rapen vanuit Voorraad. Dit is het gevolg van het gegeven dat na Goederen Ontvangst het produkt zich immer op een Voorraad Lokatie bevindt, hetgeen voldoende is om Cross Docking Rapen uit Voorraad te kunnen bewerkstelligen. ECHTER :
Cross Docking Rapen uit Goederen Ontvangst wordt separaat onderkend in Heart-Profit, omdat hiermee in principe anoniem produkt wordt behandeld wat niet-anoniem wordt verwerkt. Denk aan het kratje wat de slager "op klant" inpakt, en waarvan het systeem de inhoud weliswaar kent, maar waarbij het produkt na Goederen Ontvangst visueel niet zichtbaar is (voor de orderpicker). Uiteraard is wel zichtbaar is voor welke klant het is, en het wat dat betreft dus a. kan worden geraapt en b. kan worden afgelegd bij de betreffende dock positie.
Let op : Als er *iets* is binnen Heart-Profit wat Cross Docking Leveren zou mogen heten in de zin van het in de logistiek reeds bekende fenomeen, dan betreft het dit. Immers, technisch gezien zorgt de Goederen Ontvangst er hier voor dat het produkt (wat in de kratjes zit) meteen wordt doorgeleverd naar de klant. Lees dit goed, want dit produkt kan dùs al formeel niet meer worden geraapt ! ... maar wat fysiek toch nog moet gebeuren ... er nog pakbonnen e.d. moeten worden uitgedraaid tezamen met het overige produkt van de betreffende orders enz. enz. enz.

Aldus is Cross Docking Rapen vanuit Goederen Ontvangst een bijzonder proces, doch alleen als gevolg van de reden dat het produkt anoniem is waardoor het niet op normale wijze kan worden geraapt.
Let op : Bepalend hiervoor is onverwijld het gegeven of het produkt op klant is ingekocht. Dus : Als ook de flessen druivensap 1 op 1 voor de klant zijn ingekocht, in die zin dat de leverancier net als bij het kratje vlees de druivensap in een kratje plaats met op het kratje de naam van de klant, kan - nee *moet* - ook de druivensap via Cross Docking Rapen uit Goederen ontvangst worden behandeld. Immers, ook dan is het produkt anoniem geworden, ook eraan denkend dat de leverancier naast de druivensap ook tomatensap in het krayje heeft geplaatst (en overigens die kratjes niet eens worden opengemaakt na Goederen Ontvangst !).


Over de in het begin genoemde bufferlokaties :

Een bufferlokatie - op zich niets anders dan een normale Voorraad Lokatie - kan worden behandeld als "Cross Docking", wat opgaat voor al het hierboven genoemde. Feitelijk mogen bufferlokaties ook worden gezien als "docks" waarover "Cross Docking" produkt wordt uitgelopen. Het enige verschil is het moment in de tijd, namelijk dat de bufferlokaties zullen worden toegepast als de docks nog vol zijn. Wat dit betreft zijn de "Dock Rijen" net zo goed bufferlokaties, namelijk op het moment dat een Dock Rij wordt gevuld voor een niet-aanstaande vrachtwagen (de "andere" Rij wordt eerder geleverd op het dock).

Als we dit eenmaal (en allemaal) doorhebben, zien we ook dat een bufferlokatie niets anders is - of zo kan worden behandeld - als een klant lokatie, waarbij het zelfs zo kan zijn dat er geen normale voorraad lokaties aan de orde zijn (lees : er wordt van geen enkel produkt voorraad aangehouden). Immers, wat in de laatste situatie gebeurt is dat de bufferlokaties niet anders worden uitgelopen (kan wel een week tevoren zijn) als middels Cross Docking (Cross "buffering"), waarbij ook net zo goed weer het formele (zoals zojuist beschreven) Cross Docking uit Goederen Ontvangst kan worden toegepast. Wordt wèl ook voorraad aangehouden, dan kunnen de bufferlokaties tevens (en parallel) worden gevuld middels de methode Rapen order, zoals eerder beschreven.

Het enige verschil tussen Cross Docking Rapen naar docks en Cross Docking Rapen naar bufferlokaties, is dat in het laatste geval nog zal moeten worden overgeboekt naar de docks (Dock Rijen) wat per bufferlokatie middels één handeling kan geschieden.

Merk dan nog op dat het werken met buffertlokaties zoals hier bedoeld op zich niet is gerelateerd aan het Cross Docking (moeten) werken, omdat er immers ook voor kan worden gekozen op alleen het normale Rapen op order toe te passen.


Als laatste : Wat alles wèl met elkaar verbindt is de Scanterminal;
Het is de funktionaliteit die hierop draait die dit alles mogelijk maakt, en wat met de normale programmatuur onmogelijk kan worden verwezelijkt.

... met overigens als doel

a. het leveren op door de klant gevraagde pallets, inklusief de gewenste maximale stapelhoogte per Afleveradres (wat middels een indirekte methode wordt gerealiseerd c.q. niet werkelijk logistiek);
b. het communiceren met de vervoerder aangaande het aantal te vervoeren (en het aantal in rekening gebrachte) pallets omgerekend naar blok- en europallets.

Samengevat komt het erop neer dat het systeem nu per Verschijningsvorm precies weet hoeveel er op welke pallet kan voor een klant c.q. gewenste pallet, en daarmee ook hoeveel pallets er zullen worden gaan geleverd.

Wij komen hier zonder een ontwerp van een dagje of 2 niet uit. En daarna kan blijken dat het onmogelijk is.
Dus ja, ik wil dit graag voor je uitwerken, maar in dit geval tegen betaling.

N.b.: Dit is al best vaker aan de orde geweest, en vooralsnog is het mijn probleem dat ik kan bewijzen dat je er geen consistente administratie van kan bijhouden (wat is gerelateerd aan emballage die per klant wordt bijgehouden, vervoerders die niet meedoen, en *jij* niet bepaalt welke vervoeders jouw klant allemaal heeft -> uitwisselbare emballage (lees : verkoop v.q. inkoop).

Mocht je dit willen uitdiscussiëren alhier, dan zeg ik

a. ja graag
b. de tijd gaat lopen.

Dus vergeet s.v.p. dat laatste niet.

Iemand ?
Ik heb er zelf een tijdje niet meer naar gekeken, maar is er al weer nieuws ?

Anders wij wel ! Maar, we zijn wel heel erg van jullie afhankelijk, en je zult toch zelf moeten aangeven in welke situatie zoiets nu optreedt. Dit is voor een ander veelal geen probleem, maar jou lukt het tot nu toe niet.

... wat ook niet verwonderlijk is als je wéken na het voorval pas konstateert (meldt ?) dat er iets niet goed is. Anders gezegd : bij jullie zal het zo ongeveer op de dag zelf verkeerd gaan (en anders "morgen" wel), waarbij je (ook niet makkelijk hoor) wellicht nog weet wat er bijzonder is aan de situatie. Weken verder weet je dat niet meer natuurlijk. En zo wordt het nooit opgelost ...

Is al weer een weekje opgelost hoor;
Class coding is ook opgebouwd vandaag.

Andries, ik denk niet dat er hier iemand is die dit zo maar gaat proberen, om vervolgens het idee te hebben dat vervolgens wel geraden kan worden wat he bedoelt. Wat mij betreft een reden om nooit antwoord te krijgen ...

Ofwel, kan je niet duidelijker zijn ?

Wil je dit zelf in de gaten houden ? Het is nu nog wat te vroeg om het in te plannen. Ok ?

Maandag weer. Het zal Wouter wel ontschoten zijn. Die tweede keer dan.

Ja lekker zeg ...


Nu ik begrijp wat er gebeurt weet ik onderstaande plaatjes ook wel anders uit te leggen (en zie de grootte van de Captions (= titel balk) ... die is zelfs kleiner bij jou -> Windows past die *niet* aan) :
Op de e.o.a. manier hanteer je een groter font of zo, waarbij ik denk dat dit niet "vanzelf" gaat. Dus, tweede beeldscherm of niet, op het beeldscherm waar dit optreedt moet iets aan de orde zijn van "groter font" (kan je normaal gesproken voor een PC instellen, maar wie weet is dat per video head).
Probeer maar eens op een andere PC (met 1 beeldscherm), dan krijg je dit ook wel voor elkaar (nee, ik weet niet precies waar die instelling zit).

Uiteindelijk hanteer je een ander font, kijk maar eens naar de hoofdletters R en K.

Als dat al werkt, lijkt me dat niet de methode.
Als de vertegenwoordigers iets niet willen dan mag dat uiteraard, maar moet het pakket daar formeel mee omgaan, anders krijg je elders problemen. Dat het eerder goed uitpakte voor de vertegenwoordigers was toeval, en gebaseerd op een fout.

Als ik alles zo snel even goed begrijp hoor.

Frank, ik weet niet precies hoe intelligent jouw concullega's zijn, maar ik zou ook die percentages even wegpoetsen.

Grapjas. En ik zeg dat het niet veel minder als 4 uur zal zijn.