Hoewel er binnen Profit al mogelijkheden waren om een specifiek Voorraaditem voor een klant of order te reserveren, we ons Bestelniveau konden verhogen, en ook HPP tot onze beschikking stond om aan de verwachte vraag van een klant in een bepaalde periode te voldoen, was er een situatie die niet volledig kon worden afgevangen: "ervoor zorgen dat we
altijd 10 zakken op voorraad hebben voor een specifieke klant".
In het geval wat we altijd 10 zakken, of eenduidiger, 10 Artikel-/ Verschijningen voor iemand op voorraad moeten hebben, impliceert dit dat als er 10 op voorraad liggen, en de klant er 6 bestelt, deze 6 stuks weliswaar direkt uit voorraad geleverd kunnen worden, maar de voorraad wel direkt weer met 6 stuks moet worden aangevuld omdat de klant (desnoods een dag later) er wéér 10 zou kunnen bestellen.
Als we 10 stuks voor een klant willen reserveren, en we hebben er ook 10 op voorraad liggen, dan kunnen we uiteraard stellen dat de 10 die op voorraad liggen speciaal voor die klant gereserveerd moeten worden. Hierbij wordt echter dié specifieke charge gereserveerd, welke met de dag ouder wordt. Als we in januari een partij zouden reserveren welke door de klant misschien pas in augustus wordt afgenomen, krijgt die klant bijvoorbaat al een partij die 8 maanden oud is. Betreft het een produkt wat met houdbaarheid werkt (we moeten altijd 10 leverworsten voor iemand op voorraad houden), dan mag duidelijk zijn dat het reserveren van een specifieke charge tot ongewenste resultaten zal leiden.
Ook middels HPP is een dergelijk probleem niet te ondervangen, immers, als we 10 stuks op HPP zetten, en de klant er 6 bestelt, dan zal het HPP (in die periode) afnemen tot 4 stuks, en dát is dus niet gewenst, immers, de voorraad dient direkt weer met 6 stuks te worden aangevuld en dat gebeurt niet op deze manier.
Uiteraard kunnen we ook een impliciete reservering realiseren door gewoon het Bestelniveau met 10 stuks te verhogen. Dit zal immers automatisch resulteren in het "altijd minimaal 10 stuks op voorraad hebben" van de betreffende Artikel-/Verschijning. Probleem hierbij is echter dat als we voor meerdere klanten iets moeten reserveren, en we zélf ook nog een Bestelniveau willen hanteren, we niet over de wetenschap beschikken hoe het uiteindelijke Bestelniveau tot stand is gekomen. Anders gezegd: als een van onze klanten aangeeft dat de reservering ongedaan mag worden gemaakt (danwel failliet gaat) ontbreekt de wetenschap met hoeveel we het Bestelniveau moeten verlagen.
Daarnaast beperkt niets ons in het tóch leveren van voorraad die in principe gereserveerd is, immers, bij de diverse leverfunkties kan de aanwezige voorraad onder het Bestelniveau uitkomen.
Middels een nieuw fenomeen "Reservering Voorraad tbv Relaties" zijn we in staat voorraad te reserveren voor diverse Relaties, waarbij we
niet expliciet aangeven om welke partij dit gaat. Bij de diverse leverfunkties zijn we dan gewoon in staat om FIFO te leveren, mits de totale voorraadhoogte maar niet onder de 10 stuks uit komt.
In praktijk zal echter de som van alles wat we moeten reserveren niet gelijk (hoeven te) zijn aan datgeen we daadwerkelijk gaan reserveren. Als er 50 klanten zijn die ieder 10 stuks gereserveerd willen hebben zou dit inhouden dat we continue 500 stuks op voorraad moeten houden, waar de kans dat die 50 klanten hun 10 stuks tegelijk komen opeisen wellicht erg klein is. Hoeveel we dan wél willen reserveren zal van de situatie afhangen; hebben we het over blikjes verf dan is misschien de helft wel voldoende, maar betreft het een nieuwe CD van een bekende pop-artiest die uit binnenkort uit gaat komen, dan willen we wellicht tóch de volledige hoeveelheid reserveren.
Ook als er slechts één klant is voor wie we 100 stuks moeten reserveren hangt het er maar net vanaf of we verwachten dat die klant die 100 ineens zal afnemen of niet.
U bepaalt dit dus zelf.
Vanuit
Raadplegen Artikel-/Verschijningen kunnen we een zijstap maken naar de funktie
Raadplegen gereserveerde voorraad voor Relaties. Hier kunnen we per Relatie (iemand hoeft niet speciaal als Debiteur geregistreerd te zijn om iets voor hem te kunnen reserveren) aangeven hoeveel Artikel-/Verschijningen we voor hem willen reserveren.
Betreft het een Artikel welke met (aanpasbare) Kenmerken werkt, bijv. een Profiel waarvan de lengte, profieltype en kleur variabel zijn, dan zal e.d. reservering geacht kenmerkkombinatie moeten worden geregistreerd; we reserveren dus 10 profielen met een laagdikte van 60µm met een lengte van 2,6 meter volgens een profieltype "TTE56" en in de kleur "RAL 9002". Eventueel willen we ook nog een reservering opnemen voor hetzelfde profiel, maar dan in een andere kleur.
Bij Artikelen met Kenmerken zal de reservering dus per kenmerkkombinatie moeten worden geregistreerd. Vanuit
Raadplegen Artikel-/ Verschijning zullen we eerst een zijstap moeten maken naar
Raadplegen Kenmerkkombinaties, vanwaaruit we vervolgens weer naar
Raadplegen gereserveerde Voorraad kunnen.
Nb: Reserveringen op Kenmerkniveau is alleen mogelijk indien Uw systeem over de module
Profit-Kenmerk beschikt.
Vanuit Raadplegen gereserveerde Voorraad kunnen we vervolgens aangeven hoeveel items we voor welke Relatie wensen te reserveren; hier vullen we de 50 klanten in die ieder 10 stuks willen hebben.
Merk hierbij op dat alleen "volle" items gereserveerd kunnen worden; we reserveren een zak van 25 Kg, en niet 12 Kg uit een zak van 25 Kg.
Of we nu op Artikel-/Verschijningsvorm niveau danwel op Kenmerkniveau reserveren, de som van de opgegeven reservering zal worden getotaliseerd op het eerst hogere niveau. Dit betreft dan òf de Artikel-/Verschijning òf de kombinatie Artikel-/Verschijning + Kenmerken. Op dit hogere niveau kan vervolgens deze totale reservering worden overruled (overschreven). Hier kunnen we aangeven dat de verwachting is dat het continue reserveren van 500 stuks aan de te hoge kant is, en dat iets meer dan de helft (stel 300 stuks) ook wel voldoende is. De waarde die op dit hogere niveau wordt ingevuld is uiteindelijk bepalend voor de daadwerkelijk te reserveren voorraad, en heeft vanaf dat moment
niets meer te maken met de afzonderlijk gedefinieerde reserveringen. De opgegeven reserveringen geacht klant zijn hooguit een middel om de Totale Reservering op dat hogere niveau te vullen, danwel een analyse hoe dat totaal is opgebouwd. Indien gewenst mag de totale reservering dus ook hóger worden gezet dan de som van de reserveringen per relatie.
Iedere wijziging die we later aanbrengen op de reserveringen tbv een Relatie, zal een korrektie impliceren op de totale reservering van het hogere niveau. Dit betekent dat als we nóg een extra reservering van 10 stuks voor een 51e klant zouden opnemen, de totale reservering (die we handmatig hadden overschreven met 300) zal worden verhoogd tot 310. Deze werkwijze wordt geacht beter te funktioneren dan de totale reservering helemaal opnieuw uit te rekenen, hetgeen zou uitkomen op 510 stuks, waarbij dan het feit dat deze handmatig met 200 stuks werd verminderd teniet zou worden gedaan.
Welke methode er ook gebruikt zou worden, in beide gevallen impliceert aanpassing van de reserveringen per relatie dat altijd de totale reservering op het hogere niveau gekontroleerd moet worden en (indien gewenst) moet worden aangepast.
Vervolgens hebben we aangegeven dat er 300 Artikel-/Verschijningen gereserveerd moeten worden voor diverse klanten. Deze 300 stuks worden nu in de Behoefterun opgeteld bij het Bestelniveau, waarin op zich weer het aantal stuks kan staan welke we voor ons zélf minimaal op voorraad wensen te houden. Als we bijvoorbeeld voor eigen gebruik danwel voor overige klanten ook nog eens 50 gedefinieerd hebben, zal de Behoefterun deze twee met elkaar salderen, en nèt doen alsof het Bestelniveau op 350 staat.
Zouden we in de situatie "geen voorraad aanwezig" een Behoefterun draaien, dan zal het Besteladvies tonen dat er 350 stuks besteld moeten worden; 300 omwille van de reservering voor klanten, en 50 omwille van het werkelijke Bestelniveau.
Nb: Het Besteladvies toont deze opsplitsing niet.
Middels de reeds bestaande EOQ kunnen we vervolgens weer aangeven dat áls we eenmaal gaan inkopen (of produceren) we dit in veelvouden willen doen van 100 stuks, en dús zal het Besteladvies dan tonen dat er 400 stuks nodig zijn.
Vervolgens gaan we 400 stuks inkopen en worden deze via Goederen Ontvangst op voorraad geboekt. Op dit moment hebben we 400 stuks op voorraad en 0 stuks in daadwerkelijke orders.
Als we nu vervolgens een Verkooporder gaan toevoegen voor 10 stuks, kunnen deze gewoon uit voorraad geleverd worden. De Verwachte Technische Voorraad (400-10=390) komt niet onder het Bestelniveau (300+50=350) uit en zouden we nogmaals een Besteladvies genereren dan hoeven we niets te bestellen.
Als er vervolgens nogmaals 50 wordt besteld, kan dit zonder meer vanuit voorraad worden geleverd; we hebben er immers 390 en we hebben 300 reserveringen voor diverse klanten. Wél komen we door deze order (390-50=340) onder het Bestelniveau uit, en dus zal een nieuwe Behoefterun voorstellen om er 10, nee 100 vanwege de EOQ, te gaan bestellen.
Een ander voorbeeld:
Stel dat er zelf géén Bestelniveau hebben, en er 10 gereserveerd hebben voor een klant, en er ook 10 op voorraad liggen. Als iemand er nu 6 bestelt, komt de VTV (10-6=4) onder het Bestelniveau (0+10=10) uit, en worden er meteen 6 nieuwe besteld! Precies zoals helemaal aan het begin van deze tekst werd beschreven. De bestelde 6 kunnen direkt uit voorraad worden geleverd, en voor een voorraadaanvulling zal het Besteladvies al hebben gezorgd.
In praktijk kunnen er echter 2 dingen gebeuren:
a. De klant bestelt met een latere leverdatum dan de tijd die nodig is om de voorraad aan te vullen; in dit geval zullen eerst de 6 ingekochte stuks worden ontvangen (voorraad wordt 16) en zal daarna de klant worden beleverd (voorraad wordt 10).
b. De klant bestelt dit op zo'n korte termijn dat er niet op tijd voor voorraadaanvulling kon worden gezorgd; in dit geval zal de voorraad eerst even 4 worden (10-6) en zullen er daarna weer 6 worden ontvangen uit inkoop (voorraad weer 10).
Omdat we niet voor niets een voorraadreservering hebben voor klanten, zal dit wellicht impliceren dat er altijd op zeer korte termijn geleverd moet worden, hetgeen ook kan, immers, we hebben het niet voor niets gereserveerd.
Zou de voorraadaanvulling echter 7 dagen kosten, dan zal het duidelijk zijn dat als de klant een dag later wéér 6 stuks bestelt (we moesten immers altijd 10 op voorraad hebben) dit niet mogelijk is, immers, we hebben er nog slechts 4. Voor zover dit door U als "probleem" gezien wordt, zal de reservering voor die klant maar hóger moeten worden ingevuld, immers, op een andere wijze kan hier reëlerwijs geen rekening mee worden gehouden. Het uitgangspunt is dat we weliswaar 10 stuks reserveren, maar vervolgens wel minimaal onze inkooptijd de tijd hebben om voor voorraadaanvulling te zorgen alvorens de debiteur nogmaals bestelt.
Op een aantal plekken (Leverfunkties + Omvormen) is tevens een kontrole ingebouwd die waarschuwt voor het kritiek worden van de Technische Voorraadhoogte. Immers, als er 10 op voorraad liggen, en we gaan er 6 reserveren op een Raaplijst (leveren), dan zullen we er nog maar 4 overhouden hetgeen minder is dan de som van alle reserveringen (10). Of dit nu voor de klant is voor wie e.e.a. gereserveerd is of voor een andere klant, in theorie kán er iets fout gaan als de klant een dag later nógmaals die hoeveelheid wil afnemen.
Merk op dat er ook diverse funkties zullen zijn alwaar e.d. kontrole nimmer gewenst is, zoals bijv. Handmatige Voorraadmutaties; Ook al ís de voorraad specifiek voor iemand gereserveerd, we kunnen niet voorkomen dat een doos bij het rapen uit een magazijnstelling valt, of dat iemand ergens met zijn palletwagen tegenaanrijdt.
Vanuit
Raadplegen te leveren Artikelen kan een te leveren Verkooporderregel middels
F1___ worden opgevraagd, waarna het systeem zal tonen hoeveel er op voorraad ligt, hoeveel hiervan daadwerkelijk gereserveerd is kwa Voorraaditems én wat de som is van de reserveringen voor de diverse klanten. Dit laatste getal zal tussen "[]" tekens worden getoond.
Het is (helaas) niet mogelijk om alhier weer te geven hoeveel er daadwerkelijk "vrij" op voorraad ligt, omdat "de aanwezige voorraad" de Raapvloer van de Verkooporderregel dient te respekteren, en dús niet
alle voorraad bevat, alwaar de reservering voor de diverse klanten wél betrekking heeft op alle voorraad (de reservering voor de diverse klanten doen we niet "per Raapvloer").
Hoevaak er meldingen volgen dat de voorraad onder de som van de reserveringen uitkomt zal mede te maken hebben met overige instellingen als Bestelniveau en EOQ (zie het voorbeeld van de 300+50 met een EOQ van 100, in welk geval we pas meldingen zullen krijgen als we ónder de 300 stuks uit gaan komen).
Nb: Reserveringen geacht Kenmerken kunnen momenteel wél worden ingevoerd, maar werken vooralsnog niet in de Behoefterun vanwege het formeel ontbreken van de registratie van EOQ en Bestel niveau per Kenmerkkombinatie. Beide worden wel binnenkort verwacht.
| Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz |
| LOARVHTT | Omschrijving (nog) niet bekend | 21-02-2000 | 22-10-2001 |
| LOLLDR | Direkt Leveren | 16-10-2001 | 23-10-2001 |
| LOLLLA | Omschrijving (nog) niet bekend | 18-09-2001 | 23-10-2001 |
| LOLLRA | Raadplegen Te leveren Art./Ver | 28-08-2001 | 22-10-2001 |
| LOLLTVDL | Toevoegen aan Raaplijst | 27-07-2001 | 25-10-2001 |
| LOLLTVGL | Regel toevoegen aan Raaplijst | 27-07-2001 | 25-10-2001 |
| LOLLTVIR | Omschrijving (nog) niet bekend | 29-08-2001 | 23-10-2001 |
| LOLLTVOR | Gehele Verkooporder toevoegen | 19-02-2001 | 26-10-2001 |
| LOLLTVZR | Levering zonder Raaplijst | 05-09-2001 | 24-10-2001 |
| LOLLWG | Omschrijving (nog) niet bekend | 09-08-2001 | 22-10-2001 |
| LOLZRA | Raadpl. Te Lev. Art. op Vrzndd | 09-08-2001 | 22-10-2001 |
| LOOFT | Omschrijving (nog) niet bekend | 16-10-2001 | 22-10-2001 |
| LOOOTV | Toevoegen Omvorm Opdracht | 05-09-2001 | 24-10-2001 |
| LORVRDRA | Raadplegen Reservering op Rel. | 12-10-2001 | 26-10-2001 |
| LORVRDTV | Toevoegen reservering Art/Vrs | 12-10-2001 | 26-10-2001 |
| LORVRDWY | Wijzigen reservering Art/Vrs p | 12-10-2001 | 26-10-2001 |
| LOVIOT | Omvormen Voorraad-Item | 18-10-2001 | 24-10-2001 |
