FIFO op basis van voorangsregels

[wiliam01]

Wij werken nu bij het reserveren van artikelen op een verkooporder door middel van FIFO waarbij dus het systeem zelf de charges bepaald.
Is het mogelijk om extra voorwaarden op dit principe toe te passen?
Bijvoorbeeld eerst binnen een opgegeven aantal overeenkomstig het aantal hele pallets, eventueel van meerdere charges, en als laatste om het aantal compleet te maken een selectie uit de restant pallets.
Uitgetekend: Benodigd 72 stuks = 3 pallets van 22 stuks met eventueel ieders een andere charge en aangevuld met een restant van 6 stuks.deze laatste 6 stuks dan van zo weinig mogelijk verschillende charges.

Dit kan natuurlijk wel handmatig maar dat is nogal veel werk gezien de onder handen zijnde orders waarbij telkens ook dezelfde producten geraakt worden.

[Wouter Rijnbende]

Binnen de standaard werkwijze is dit niet eenvoudig te integreren; neemt niet weg dat er wel mogelijkheden zijn in die hoek, maar, het wordt aardig complex. Zie maar eens de functionaliteit in topic http://ha1.heartprofit.nl/profit/index.php?topic=24977.0 waarbij je zelf kunt inplannen welke pallet hoe ingedeeld moet worden. Stel daar ook maar eens bij voor dat de hoeveelheid die op een pallet ligt, kan afhangen van het soort pallet, of zelfs, de lokatie waar die pallet in het vliegtuig moet komen te staan (een pallet die in de ronding van het vliegtuig geladen gaat worden, kan minder hoog gestapeld worden dan een pallet die in het midden van een vliegtuig komt te staan).

Allereerst begint het al al mee dat in jullie administratie nergens bekend is wat één pallet is.

Als jij 110 Verschijningen inkoopt leg je dit nu als één batch op voorraad (aantal = 110). De eerste verandering die zal moeten plaatsvinden is dat je dit soort dingen 'per pallet' gaat boeken. Ofwel, e.e.a. zal als 5 Subcharges (op 1 Hoofdcharge) van 22 Verschijningen op voorraad moeten komen te liggen: 5 x 22V ipv 1 x 110V.

Binnen het bovengenoemde ontwerp begint het verhaal vervolgens met dat iemand per zending gaat plannen hoe een pallet gestapeld gaat worden. Aldaar relatief complex, omdat het in de AGF branche ontwikkeld is, en je meloenen niet op champignons mag stapelen. Met blikken zal dit wel loslopen ;-)

Denk niet dat e.e.a. er nu 100% in zit, maar een basis is er zeker al wel.

[Peter Stordiau]

Misschien heb ik wel wat inside-info, maar misschien sla ik de plank ook wel volledig mis :

Ik denk/vermoed persoonlijk dat jullie weliswaar met FIFO Charges op de Raaplijst e.d. werken (dat gaat redelijk vanzelf) maar dat je je tot op heden relatief weinig stoort aan of de gevraagde Charges ook daadwerkelijk worden geraapt. Dit, terwijl dit (vanaf heden - zeg ik maar even zachtjes) toch wel moet gaan gebeuren ?
Heb ik nog gelijk ? Zo nee, stop dan maar met verder lezen.

Het lijkt me dan ook dat je op dit moment een redelijke "chaos" hebt in de algemene organisatie hiervan en dat je op dit moment wordt gedwongen om je ongans te zoeken naar al die verschillende Charges waar de Raaplijst mee op de proppen komt en die verspreid staan over meerdere pallets.

Uiteindelijk heeft Wouter wel gelijk, maar ik denk zelf (dus) dat je eerst een ander probleem hebt op te lossen : de organisatie van de Charges. Dus alles van 1 Charge netjes op 1 pallet houden; restanten (van eerder geleverde "halve" pallets) op daarvoor bestemde lokaties (desnoods alles op/in dezelfde plank/rek) en ... tja, dus ook weten wat "pallets" zijn. Dit laatste kan je denk ik nog enigszins oplossen middels aparte lokaties per pallet c.q. wellicht is dat voldoende (en gaat de echte oplossing van Wouter dus ook veel te ver).

Je mag het ook zo lezen :
Bijna iedereen levert op basis van (Charge) FIFO en die gebruiken allemaal heus Wouter z'n oplossing niet. Kortom, als je dit wat "beter" organiseert gaat het vanzelf al goed of goed genoeg.

Ook nog even dit :
Waar je momenteel denkelijk niet goed in staat bent (of het gewoon niet doet) om te rapen wat de Raaplijst aangeeft, is het binnen de kortste keren puinhoop (op een volgende Raaplijst staat hetzelfde produkt maar genoemde Charge heb je onterecht gepakt voor die vorige Raaplijst). Het wordt nu heel wat anders als je weliswaar de juiste Charge niet levert maar *wel* aangeeft welke je dan wel hebt geleverd. Dit voldoet dan weliswaar niet aan FIFO op dat moment, maar je vermijdt de puinhoop voor de volgende leveringen (het systeem weer nu dus precies welke Charges er op voorraad zijn). Dat wordt dus feitelijk scannen, maar die faciliteit heb je ...

Excuses op voorhand als dit allemaal nergens op slaat.

[wiliam01]

Dank je Wouter en dank je Peter,

Allereerst Peter, we rapen wat we reserveren dus dat gaat prima.(geen chaos meer dus)
We reserveren nu alleen op basis van eenheden vanuit een totale charge en niet op basis van aantal pallets op basis van sub charges.
Daarom zie ik wel brood in het verhaal van Wouter maar moet even goed overdenken welke definities dan wel voorwaarden wij nodig hebben.
Ik zal een en ander nader uitwerken met ook gelijk een aantal voorbeelden van hoe het wel zou moeten gaan werken.
In mijn overwegingen ga ik dus gemakshalve alvast uit van sub charges(hoewel dit voor ons een nieuw fenomeen is).

Kom er dus z.s.m. op terug.

[wiliam01]

Automatisch reserveren op basis van sub charges,
Actueel  reserveren wij op basis van eenheden en met eenzelfde charge.
Dat wil zeggen dat als wij een partij na productie gereed boeken van 115 stuks, dan krijgen zij allen hetzelfde charge nummer. 
Als we op basis van FIFO automatisch gaan reserveren, dan worden de oudste charges het eerst geselecteerd zonder dat daarbij naar een eventueel economisch voordeel gekeken kan worden.
Het economische voordeel zit hem voor ons voornamelijk in hele pallets en met als resultaat zo weinig mogelijk restant pallets. Wat wij nu graag zouden willen is het volgende:
We hebben een order voor 22 stuks. Een vol pallet is 22 stuks dus zou het economisch zijn als er een vol pallet gereserveerd gaat worden. Echter: Onze vrd is,
Charge A met charge datum 01-05-2014 1 pallet met 16 stuks
Charge B met charge datum 01-06-2014 1 pallet van 22 stuks en 1 pallet van 9 stuks

Op basis van de huidige voorwaarden wordt eerst charge A met 16 stuks geselecteerd en vervolgens het restant van charge B. 
In dit geval zou het economischer geweest zijn als eerst de charge B en pallet met 22 stuks was geselecteerd.

Een ander voorbeeld met dezelfde order is:
Onze vrd:
Charge A met charge datum 01-05-2014 1 pallet met 16 stuks
Charge B met charge datum 01-06-2014 1 pallet van 20 stuks en 1 pallet van 9 stuks

Omdat er hier nu geen vol pallet aanwezig is zal er dus over meerdere charges geselecteerd moeten gaan worden.
In dit geval zou dus de voorwaarde FIFO wel afgedwongen moeten worden en zal het restant van het pallet met 9 stuks geselecteerd moeten worden.

Bijkomende zaken zijn:
We hanteren diverse aantallen met eenheden op pallets
Per artikel/verschijning daarentegen staan deze wel vast.
Bijvoorbeeld bij artikel/verschijning  X staan er altijd als basis 22 stuks op een pallet.
Zo kunnen er voor Artikel/verschijning Y altijd als basis 100 stuks op een pallet staan.
Uiteraard kunnen er in alle gevallen restant pallets ontstaan met afwijkende aantallen.

Ben benieuwd.

[Peter Stordiau]

Maar vraagje Wiliam :

Misschien had ik het tussen de regels door al eerder moeten lezen, maar *nu* wil je dus juist FIFO expliciet onderuit halen (impliciet ook goed, maar het gebeurt dus).

Nu suggereerde ik zoiets ook wel (als je maar aangeeft dat je "anders" hebt geraapt) maar ik vraag me af of het zo "expliciet" FIFO omzeilen nu wel de bedoeling is ...
Lees : weten ze dit in Japan wel ? (ik hoop dat je snapt wat ik bedoel)

[wiliam01]

Het is geenszins de bedoeling om FIFO onderuit te halen maar verder uit te breiden met voorwaarden die FIFO niet altijd leidend laten zijn. Als je logisch beredeneert, en dat kan jij beter dan ik, dan zul je tot de ontdekking komen dat de oudste charge in principe nooit langer op vrd zal staan dan een tweede charge daarna. Veelal door de hoge omloopsnelheid. Kortom ik vind dit verdedigbaar naar ons SOX programma. (dat is waar jij op doelt neem ik aan) Uiteraard zal het definitieve ontwerp daar eerst aan getoetst worden en waar nodig ook voorgelegd worden aan de auditoren.

Laat maar horen wat er van mijn gedachten, in combinatie met jullie kennis der programmatuur, mogelijk is op dit gebied zonder dus al op voorhand zaken uit te sluiten.

[Peter Stordiau]

OK.

Zeg je nu in feite dat FIFO mag inhouden : 1 Charge ouder is ook goed ?

Ik neem even aan dat je Ja zegt (maar zeg het gerust als het niet zo is).

Wat je dan kan krijgen is dat bij een 1e selektie voor een Levering Charge B wordt gekozen over Charge A (B is "1 nieuwer").
Maar daarna is B uit de voorraad en zal een volgende Levering hetzelfde kunnen doen, alleen nu met A en C (die 1 nieuwer is als B was).

Waar ik dus een simpele en flexibele methode zou willen hebben, gaat deze dus niet werken. Bedenk ook maar dat A toevallig uit 6 blikken bestaat die je nooit nodig hebt (want toevallig altijd meer). Het gevolg is dan dat A (die oorspronkelijk de oudste was) steeds "te veel ouder en ouder" wordt.

Mooi. Dit kan ik zelf al niet meer volgen, maar projekteer zo'n gedachte is op je eigen idee. Gaat het dan nog goed ?

[wiliam01]

Klopt Peter, ... ik kon je overigens helemaal volgen tot het eind en zelfs verder en je hebt inderdaad een punt.
Alhoewel ik die kans niet zo heel groot acht, heb ik hier natuurlijk wel wat te verdedigen inderdaad als het gaat om FIFO.
Daarentegen als we nu kiezen om eerst de hele pallets voorrang te geven en daarna altijd eerst het oudste restant te pakken, dan heb ik in ieder geval al veel gewonnen.
Betekend dan wel dat er een mogelijkheid bestaat dat er meerdere restanten worden aangesproken maar zo blijf ik wel dicht bij FIFO en heb ik de garantie dat de oudste charge altijd binnen een bepaalde tijd is opgelost.

We zouden ook kunnen zeggen, en nu ga ik misschien wel heel ver(dwalen zelfs): als het een artikel/verschijning betreft die alleen uit pallets van 22 stuks bestaat(muv restant) dan zouden we ervoor kunnen kiezen dat alles binnen een range van 22 -3 of minder eerst het eventueel passende pallet wordt gekozen van elke willekeurige charge en als het daarbuiten valt dat dan eerst het oudste restant gekozen wordt. Hiermee wordt de kans wel heel erg verkleind en vind ik het evengoed verdedigbaar. Ook hier geldt dan weer dat er opnieuw eventueel meerdere restanten worden aangesproken.

Al denkende in oplossingen bedenk ik me zo dat het niet eens zo heel ver van de basis af is als dat het lijkt, toch?

[Peter Stordiau]

Wiliam,

Al denkende in oplossingen bedenk ik me zo dat het niet eens zo heel ver van de basis af is als dat het lijkt, toch?

Klopt. En daar wilde ik in elk geval voor mezelf graag naar toe. Dus eigenlijk is het nu relatief simpel om iets leuks te "bedenken", maar dat begint bij het nu (denk ik althans) volledig begrijpen.

Om nu verder te kunnen is het wel redelijk cruciaal om te weten of jullie via scanners gaan rapen (wie weet doe je dat al - geen idee). Je mogelijkheden zijn dan xx keer groter plus dat het eigenlijk 100% betrouwbaar is. Denk als voorbeeld aan :
Systeem stelt voor om toch maar die pallet te nemen waar je net even niet bij kan, operator (zo noem ik 'm even) schiet op andere pallet die zijn voorkeur heeft maar systeem zegt "mooi niet !". Of, systeem stelt volgende pallet (of blikken) voor omdat operator aangeeft "deze even niet graag".
Zonder scannen kan dit allemaal niet en moét je doen wat er op het papiertje staat en dat is in gevallen niet echt werkbaar (of kost veel tijd).

[Peter Stordiau]

Andere vraag die eigelijk wel heel belangrijk is :

Werken jullie nou nog met die externe beheerder (Mepavex ?) of niet ?
Ik hoop het eigenlijk niet, want ...

[wiliam01]

Peter,
Wij werken inderdaad met een externe partij (en wij zijn blij van wel) en onze vrd registratie loopt 1 op 1 en dat zal straks ook het geval zijn igv pallets.
Zij werken namelijk al met pallet registratie en daar ontstaat nu juist de kneep.
Wij stellen eenheden voor en zij moeten pallets rapen.
Dat doen zij dan binnen die eenheden/charge die wij gereserveerd hebben en dat laat dan weer te weinig ruimte voor hun.
Als wij dus van meet af aan de pallets goed kunnen voorstellen(reserveren dus), dan ontstaat er voor hun meer ruimte mbt economisch rapen.
Let wel: Wij stellen straks pallets/sub- charges voor en niet de locatie waar vanaf geraapt moet worden want dat is juist de eco slag die zij dan kunnen maken.
Ik hoor je al denken: kunnen zij dat dan niet anders inrichten? Dat kunnen zij wel maar nog steeds binnen die range van eenheden die wij gereserveerd hebben.
M.a.w.: zij mogen in principe nooit afwijken van datgene wat wij reserveren dus kunnen ze ook niet vrijelijk een andere charge rapen om zo een pallet te pakken wat passender is.
Daarnaast kan ik het "NIET consequent FIFO" reserveren niet aan hun verantwoording overlaten want dan krijg ik het zekers niet uitgelegd.

Resumé:
Aannemende dat beide vrd gelijk zijn.
Vrd artikel/verschijning/charge1 = 92 stuks / onderverdeeld in 4 pallets van 22 stuks en een restant van 4 stuks
Vrd artikel/verschijning/charge2 = 50 stuks / onderverdeeld in 2 pallets van 22 stuks en een restant van 6 stuks
Vrd artikel/verschijning/charge3 = 132 stuks / onderverdeeld in 6 pallets van 22 stuks

Wat wij dan aangeven aan derde partij:
Order = 112 stuks en resulteert in 4 pallets van charge1 en  1 pallet van charge2 en 2 losse eenheden van charge1
Order = 94 stuks en resulteert in 4 pallets van charge1 en 6 losse eenheden van charge2
Order = 188 stuks en resulteert in 4 pallets charge1 en 2 pallets charge2 en 2 pallets van charge3 +4 losse eenheden charge1+6 eenheden charge2 + 2 eenheden charge3
Order = 7 stuks en resulteert in 4 stuks van charge 1 en 3 stuks van charge 2
Order = 11 stuks en resulteert in 4 eenheden charge1 + 6 eenheden charge2 + 2 eenheden charge3

De laatste 2 voorbeelden zijn dus gebaseerd op wel FIFO met inachtneming van 22-3 principe wat ik eerder aangaf en wat er dus mede voor zorgt dat FIFO nooit langer dan 3 charges duurt.

Goed weekend alvast,

[Peter Stordiau]

Nou Wiliam, het weekend was wel goed, maar of de week ook zo goed wordt ?

Op dit moment heb je (voordat we verder kunnen) even twee keuzes (of-of dus) :

1. Jullie voorzien ieder blik op dezelfde pallet van hetzelfde Chargenummer.
2. Mepavex zorgt ervoor dat blikken he-le-maal nooit van de ene pallet naar de andere verhuizen.

Ad 1.
Is wellicht niet pratisch (en daarmee niet uitvoerbaar). Maar er mogen dus geen twee pallets zijn met dezelfde charges erop.
Subcharge = : Hoofdcharge van de produktie + volgnummer van de pallet waar het op staat.
N.b.: Normaliter mag een hoofdcharge van bijv. 1000 blikken (hoofdcharge staat op alle 1000 blikken en ieder blik is dus gelijk) worden verdeeld over de ~50 pallets en bevat iedere pallet een sticker met die hoofdcharge maar met voor iedere pallet een uniek nummer (01 t/m 50) en wat zo'n pallet een "Subcharge" maakt.

Ad 2.
Als aan #1 niet wordt voldaan (kan worden voldaan) zijn dus alle 1000 blikken gelijk, maar plakt Chukogu nog wel de Hoofd+Subcharge op de pallet. Het systeem kent nu de vooraad per pallet en feitelijk wordt ieder blik geaddresseerd met zijn hoofd+subcharge, ook al staat alleen de hoofdcharge op het blik. Als 12001 de hoofdcharge is en 03 een volgnummer voor een pallet van oorspronkelijk 22, dan kent het systeem dus 22 blikken met "Charge" 12001-03.
Bij Mepavex staan 2 pallets naast elkaar, beiden met blikken met 12001 erop, maar de ene pallet met sticker 12001-03 en de andere met 12001-04. Het is nu verboden om een blik te verhuizen van pallet -04 naar pallet -03, ook al ziet Mepavex dezelfde 12001 op de blikken van beiden.
N.b.: Analoog aan de geschetste voorbeelden (maar iets anders in elkaar gedraaid) kunnen er dus 10+ pallets onstaan met ieder nog enkele blikken erop, omdat klanten toevallig steeds 20 blikken willen uit pallets met 22 blikken. Gewoon, allemaal dezelfde Hoofdcharge. Die 10 pallets mogen dus nooit worden samengevoegd tot 1 door Mepavex en blijven dus 10 pallet plaatsen in beslag nemen.
Als Chugoku aan #1 voldoet is dit geen probleem, en mogen er ook 22 blikken met ieder een andere "Charge" op een pallet staan als Mepavex dat nodig vindt. Hooguit zoeken ze zich een ongeluk naar die ene gevraagde Charge van Chugoku, maar dat zoeken ze (dan) zelf maar uit.

Wiliam, je moet goed weten dat er geen tussenweg is; In Profit zelf is dit allemaal geen probleem (alles geregeld via scannen en nog wat meer) en is zodoende 100% werkbaar.
Je hoeft het Mepavex niet te vertellen, maar wat er o.a. (weinig echt werkbaar) zal gebeuren is dat iemand 20 blikken nodig heeft en Mepavex die 20 blikken van een pallet moet halen waar er 22 op staan zodat er 2 over blijven. Beetje dom heh, als er ook 2 blikken afgehaald kunnen worden, op een lege pallet kunnen worden gezet en de oorspronkelijke pallet met 2 blikken achter kan blijven. Waar zou je zelf voor kiezen ?
Nou, het laatste lukt niet want dan moet eerst de oorspronkelijke sticker die op de pallet zit en die naar expeditie gaat op de nieuwe pallet worden geplakt (of een nieuwe sticker maken wat Mepavex ook niet echt lukt).

Er zijn best nog wel meer haken en ogen maar dat is allemaal een kwestie van de consequenties niet vertellen en "ze" trappen er wel in voor het huidige contract.

Dus ?