Inleiding
De omschrijving van het topic is wellicht ietwat vreemd, maar, onder dit mom is het onderwerp herkenbaar voor de klant voor wie e.e.a. is ontwikkeld. Het topic is zéér specifiek van aard en wellicht voor velen niet bruikbaar, of moeilijk te begrijpen. We gaan dan ook niet teveel tijd besteden om uit te leggen wat u w.s. nimmer zult gaan gebruiken. Het topic is op het Forum opgenomen om daar als 'handleiding' teruggevonden te kunnen worden. Ze omvat meerdere aanpassingen als totaaloplossing voor een specifiek probleem, gerelateerd aan de naam van het topic: Behoefterun Turkije.
Doel van de hierna beschreven nieuwe funktionaliteit
Misschien ligt het niet erg voor de hand voor een pakket van intussen ruim 30 jaar oud, maar stel je voor dat aan de lezer dezes de schone taak is gegeven om de logistieke behoeften in kaart te brengen van een verkopend en voorraad houdend filiaal in een buitenland (Turkije), dit filiaal is ontstaan uit een overname, dit filiaal gewoon was om lokaal in te kopen en te wederverkopen, maar dat de nieuwe eigenaar (bedrijf in Nederland) de produkten zelf produceert en naar Turkije kan - en wenst te verkopen;
Het gaat nu niet om de eveneens ruim 30 jaar bestaande Behoefterun die haar werk al of niet goed doet in deze, maar het gaat om de bepaling van de de logistieke parameters zoals Bestelniveau en alles waarmee de Behoefterun werkt. Als Nederlandse eigenaar weet je eigenlijk niets of te weinig van het Turkse bedrijf, en het enige wat je kan zien is welke vooraad men op dit moment heeft c.q. aanhoudt (als je dat al goed kan zien), welke verkooporders men zoal heeft alsmede wat voor een inkopen men doet. Je weet ook de ruimte in de magazijnen aldaar.
Je doel is om te komen tot een verantwoorde voorraad, waarbij het vooral gaat om te transporteren batch groottes, het wilen vermijden van de duurdere lokale inkoop, het inzicht in de impact op je eigen organisatie (Nederland), de voorraad die je zelf (extra) moet gaan aanhouden en de ruimte die je daarvoor hebt en uiteraard je eigen batchgroottes en hoe die te kombineren met de verdere eigen behoeftes (waaronder ook die van nog andere landen).
De nieuwe funktionaliteit is aldus bedoeld om deze inzichten te bieden, om vervolgens de betreffende logistieke parameters op juiste wijze te kunnen instellen. Eventueel kan de voorgestelde funktionaliteit later zelf als "Behoefterun" gaan fungeren.
Situatieschets
In de voor ogen liggende situatie beschrijven we een implementatie van Profit, waarbij het in eerste instantie om een tweetal bedrijven gaat. Ten eerste een Turks bedrijf, die over de verkopen-/leveringen in Turkije gaat, en ten tweede een Nederlands bedrijf, al waar de produkten worden geproduceerd.
De produkten die Turkije verkoopt:
- kunnen geleverd worden uit voorraad
- kunnen worden ingekocht bij een producerend Intercompany Bedrijf
- kunnen ter plaatse (in kleine hoeveelheden) gemengd (= milde vorm van produktie) worden
- kunnen lokaal worden ingekocht bij een plaatselijke Leverancier
- kunnen worden ingekocht bij een voorraadhoudend belendend Intercompany Bedrijf zijnde een bedrijf zoals het Turkse bedrijf zelf
Lokaal inkopen zullen we liever niet willen doen, immers, daarmee geven we geld uit handen. Toch kunnen andere opties afvallen, bijvoorbeeld omdat inkopen bij een IC bedrijf te lang zal gaan duren.
Om aan een levertijd van slechts een paar dagen te kunnen voldoen, zal Turkije zo veel mogelijk "uit voorraad" moeten leveren. Die voorraad zal dus hoog genoeg moeten zijn om te kunnen voldoen aan de gemiddelde vraag naar de verschillende produkten. Het produkt wat we verkopen betreft verf. Verf hebben we in vele verschillende kleuren, en we kunnen moeilijk zeggen dat we van iedere kleur wel even één of twee pallets op voorraad aanhouden, immers, daar hebben we simpelweg niet voldoende palletplaatsen voor (los van de investering in produkt die daar voor nodig zou zijn). Dit moet dus zo optimaal mogelijk gebeuren, met als eerste vraag 'hoeveel moeten we van welk produkt op voorraad aanhouden?'.
In de opbouw van het Artikelnummer wordt onderscheid gemaakt naar Artikelen die door ons zelf (of een zusterbedrijf) zijn geproduceerd en Artikelen die "lokaal" zijn ingekocht. Met als uitgangspunt dat we een Artikelnummer hebben die we 502A0020 zouden willen noemen (met daarin markt, kwaliteit, kleur e.d. verwerkt) wordt dit Artikelnummer verder uitgebreid met op een 5e positie een letter die de afkomst weergeeft:
D = versie die door ons zelf (of een zuster-/dochter bedrijf wordt geproduceerd)
Z = versie die lokaal is ingekocht
Dus :
502A
D0020
502A
Z0020
Nb: In praktijk zijn er nog veel meer versies zoals een 502A
M0020, 502A
F0020 of 502A
L0020; die zullen we u voor nu besparen.
Ook: De betreffende artikelnummering is geen voorstel of must/idee van Profit; het betreft de methode van nummering van de klant die Profit in deze gebruikt.
We hebben nu dus twee Artikelen in ons voorbeeld: een 502AD0020 en een 502AZ0020. Beide betreffen dus hetzelfde produkt, maar de een kopen we in NL in (de D), en de ander bij een lokale Turkse Leverancier (de Z).
We maken het verhaal nog iets complexer. Het Nederlandse bedrijf heeft ook Externe Magazijnen in diverse buitenlanden, waaronder Spanje en Griekenland. Op die manier ontstaan er ook situaties dat Turkije een behoefte heeft aan een produkt maar dat Nederland dit niet zelf op voorraad heeft, maar het wél in Griekenland op voorraad ligt. Als Turkije inzicht heeft in de voorraad van Spanje, Griekenland en Nederland kan er sneller beslist worden of ze het produkt in Griekenland moet inkopen, in Nederland, of dat het alsnog lokaal moet worden ingekocht. Op de achtergrond speelt uiteraard dat het produkt in Nederland eventueel eerst geproduceerd moet worden, welke produktie moet worden ingeplanned, al was ingeplanned, of onmogelijk op tijd kan worden gerealiseerd. Let op : dit laatstgenoemde is feitelijk een verdere stap, nog buiten de scope van deze handleiding en de nu bestaande funktionaliteit.
Regels
- Turkije verkoopt in eerste instantie altijd de AD variant (502AD0020); immers dan verdient ook NL aan de verkoop
- Als het niet anders kan (bijv. levertijd kan niet worden gehaald) mag er lokaal (AZ - 502AZ0020) worden ingekocht
Als we het produkt ooit eens lokaal hebben ingekocht, en er ligt nog AZ op voorraad, maar we hebben gesteld dat we altijd AD moeten verkopen, dan zou daar uit volgen dat de AZ tot in lengte van dagen blijft liggen. Hieruit volgt:
- als er nog AZ op voorraad ligt (of voldoende op aankomende Inkooporder staat) dan moéten we AZ verkopen
- als er géén AZ op voorraad ligt (of is ingekocht) dan mag er geen AZ worden verkocht
Berekenen Veiligheidsvoorraad & Bestelniveau
Via Hoofdmenu-1-1-1-6-1-1 is nu een klantspecifieke berekening van de Veiligheidsvoorraad en het Bestelniveau opgenomen. Deze rekent op zich via de oude formules (uit de helptekst) de Veiligheidsvoorraad en het Bestelniveau uit, maar anticipeert op talloze situaties die er in de loop der 30 jaren in het pakket bij zijn gekomen, en elimineert die uit deze berekening. Denk bijvoorbeeld aan het feit dat als wij een Verkooporder uitbesteden aan een Leverancier of een Intercompany bedrijf die we vervolgens rechtstreeks laten leveren, het feitelijk geen verkoop is waar
wij voorraad voor hoeven aan te houden. Tevens wordt er een Excelsheet opgebouwd welke inzichtelijk maakt hoe we aan welke bedragen zijn gekomen. Op die manier kunnen we de berekende data ook kontroleren. De berekening achter deze tool baseert zich op SQL Queries op de Advantage Database Server.
N.b.: Profit zelf kan worden aangegeven of
- de Berekende Bestelniveau en Veiligheidsvoorraad overschreven moet worden uit de berekening (en verdere invullen) van de Excelsheet;
- de Berekende Bestelniveau en Veiligheidsvoorraad moeten worden teruggelezen uit de Profit database i.p.v. opnieuw berekend moeten worden door de Excelsheet.
Het is aldus mogelijk om een eenmaal door de Excelsheet berekende Bestelniveau en Veiligheidsvoorraad niet opnieuw te laten berekenen omwille van a. het al tevreden zijn met een eerdere berekening of b. het in de Excel overschreven hebben van de berekeningen die intussen in de Profit database staan.
Merk op dat in alle geval de teruggeschreven waarden in de "Berekende" velden in de Profit database nog moeten worden geëffektueerd alvorens ze hun werking krijgen in de gebruikelijke Behoefterun.
Allereerst wordt de
Veiligheidsvoorraad berekend volgens de formule:
Wortel van ((( X * Y ) - ( Z * Z )) / ( X * ( X - 1)))
waarin geldt:
(X) Het aantal maanden waarin afname heeft plaatsgevonden
(Y) De som van de kwadraten van de afname
(Z) De kumulatieve afname
Daarna wordt het
Bestelniveau berekend volgens de formule:
Bestelniveau = Veiligheidsvoorraad + (Gemiddelde afname * Produktie-Inkooptijd)
waarin geldt: Gemiddelde afname = afname / (aantal maanden * 20)
De Excelsheet (die automatisch wordt getoond nadat de berekeningen zijn gedaan) is opgebouwd in een aantal blokken met data.
In het eerste blok worden de gegevens van de Artikel-/Verschijning, de Werkelijke Inhoud etc. weergegeven:
Daarna volgt een blok waarin de verbruikcijfers van de afgelopen 12 maanden worden getoond.
Opmerkingen:
- De verbruikcijfers worden bepaald op basis van de Verkopen (LOVR) alsmede het verbruik in Produktieorderregels (LOPR) in de afgelopen 12 maanden. Dit, in tegenstelling tot de standaard versie van de berekening, die haar data bepaalt op basis van de Faktuurregels.
- Leveringen op Externe Verplaatsopdrachten tellen niet mee in de bepaling van de verbruikcijfers.
- Leveringen uit Externe Magazijnen worden eveneens uitgesloten van deze berekening; Externe Magazijnen kunnen binnen Profit met zgn. "Magazijnbehoeftes" werken, en mogen hun eigen Bestelniveau hebben. Zo kan gelden dat we in ons Nederlandse Magazijn een ander Bestelniveau willen hanteren dan in ons Spaanse Magazijn. De Veiligheidsvoorraad en Bestelniveau van de Artikel-/Verschijning zijn gebaseerd op de verkopen die we vanuit onze interne magazijnen leveren en derhalve tellen de Externe Magazijnen hier niet mee. Een berekening van Veiligheidsvoorraad en Bestelniveau per Extern Magazijn is niet ontwikkeld.
- Artikel-/Verschijningen waarvan de Afname zich beperkt tot 1 Verkooporderregel, worden betiteld als Incidentele Verkoop en zullen niet leiden tot de berekening van een Bestelniveau
Daarna volgt een blok waarin de berekening van de Veiligheidsvoorraad wordt verklaard. De Veiligheidsvoorraad wordt in Aantal Eenheden en in Aantal Verschijningen getoond:
Het volgende blok toont de berekening van het Bestelniveau. Alhier wordt ook de Voorkeurs Leverancier getoond, opdat visueel kan worden gekontroleerd of het letter die aangeeft wat de 'afkomst' van het produkt is (bijv. de 'Z' van de 'AZ' die een lokale Leverancier impliceert) overeenkomt met wat er bij de Artikel-/Verschijning is gedefinieëerd.
Nb: In bovenstaand blok is hard geprogrammeerd dat de Produktie-/Inkooptijd bij het eigen bedrijf 6 dagen in beslag neemt, en een inkoop bij een lokale Leverancier 2 dagen.
Daarna volgt een blok met data welke op zich niets met een Veiligheidsvoorraad danwel Bestelniveau te maken heeft, maar, op basis van de Palletinformatie (aantal lagen per pallet en aantal Verschijningen per palletlaag) het Bestelniveau omrekent naar een aantal palletplaatsen. M.a.w. als we voor iedere Artikel/Verschijning in onze Excelsheet precies dat op voorraad leggen wat er in het Bestelniveau is aangegeven, hoeveel Palletplaatsen zou dat dan in beslag nemen. Het grande-totale onderaan het overzicht zou kunnen worden afgezet tegen het beschikbare aantal palletplaatsen met mogelijk als conclusie dat hetgeen we willen helemaal nooit zal kunnen passen in het magazijn.
Dit blok heeft ook weer raakvlakken met het volgende blok, welke diezelfde pallet informatie toont, maar nu op basis van de huidige voorraadhoogte. Zo kan het zijn dat we 2 pallets nodig hebben kwa Bestelniveau, maar dat er in praktijk 5 pallets liggen.
Hard geprogrammeerd, wordt hier ook de voorraad getoond zoals deze in Nederland, Spanje en Griekenland ligt. Ook wordt aangegeven wanneer het betreffende produkt voor het laatst geproduceerd werd. Dit kunnen we weer gebruiken om te beoordelen dat het om 'oude' voorraad gaat.
Let op : Het navolgende suggereert dat we vanuit deze "omgeving", zijnde de Excel maar tevens zijnde een VTV scherm wat verderop wordt behandeld, zouden kunnen gaan inkopen. Dit is per sé niet het geval, ook al kunnen we ons voorstellen dat er een keer een "handige toets" komt die automatisch een hoeveelheid inkoopt die we inde Excel / VTV voorgsteld zien. Dit is en blijft een handmatige aktie zonder verdere intelligentie. Het zal uiteindelijk de Behoefterun zijn die voor de volledige geautomatiseerde bestellingen zorgt. De Excel en ook VTV zijn dus nog steeds alleen voor het benodigde inzicht en hoe de logistieke parameters moeten worden ingesteld.
Al met al hebben we nu een mooie Excel die ons van allerlei informatie voorziet, maar, zonder een Verwachte Technische Voorraad kunnen we de lijst niet anders gebruiken dan ter beoordeling van dat Bestelniveau. Er zijn derhalve nog twee blokken opgenomen met de VTV in aantal eenheden en de VTV in aantal Verschijningen. Hieruit kunnen we nu informatie halen dat er weliswaar een Bestelniveau is berekend, maar dat er geen behoefte (orders) zijn voor dit produkt. Of andersom, dat er een behoefte is, maar deze al door bijv. een Inkooporder is gedekt.
De VTV informatie wordt dan weer gebruikt om iedere Excelregel in een bepaalde kleur op te nemen. In de Legenda wordt uitgelegd welke kleur representatief is voor welke situatie. Merk hierbij op dat er ook een kleur is die impliceert dat het om kleine hoeveelheden gaat die Turkije best zelf kan produceren (uit pasta's) op een lokale mengcomputer. Deze uitzondering wordt gemaakt om niet voor ieder produkt waar ooit een blikje van is verkocht er voor te zorgen dat er meteen een hele pallet op voorraad van moet worden aangehouden. Alles wat hier ontwikkeld is betreft een kompleet spel om te bepalen hoeveel voorraad we van welk produkt moeten aanhouden, binnen de beschikbaarheid van een beperkt aantal palletplaatsen.
Raadplegen Artikel-/Verschijningen met Bestelniveau
We hebben dus AD en AZ versies van onze Artikelnummers. De eerste (AD) betreft een produkt welke Turkije inkoopt bij een Intercompany (zuster) bedrijf, de laatste (AZ) betreft een produkt welke lokaal bij een plaatselijke (Turkse) Leverancier wordt ingekocht. In het kopje "Regels" hebben we al kunnen zien dat áls er nog voorraad aanwezig is van de AZ versie, we dié als eerste zullen moeten verkopen. Is er géén voorraad van een AZ, dan zullen we AD moeten verkopen. Ook die AD versie hoeft in Turkije niet op voorraad te liggen, en zal dan moeten worden ingekocht bij NL. Maar, voor hetzelfde geld heeft NL geen voorraad en bijv. Griekenland wel, zal zullen we de voorraad juist uit Griekenland willen betrekken.
In 2009 hebben we voor een klant al eens een Funktie "Raadplegen Artikel-/Verschijningen met VTV gegevens" mogen ontwikkelen. Dat scherm berekent de Verwachte Technische Voorraad (VTV) van een Artikel-/Verschijning en toont de resultaten in een soort Raadpleegfunktie op het scherm. Het berekenen van de VTV van een Artikel neemt tijd in beslag, en ook al is dit maar een halve seconde, als we 20.000 Artikel-/Verschijningen te tonen hebben, komt dit neer op 10.000 seconden = 166 minuten = ruim 2½ uur om de data voor ons Grid op te bouwen; dat werkt dus niet!
Het bijzondere aan het ontwikkelde scherm is dan ook het uitgaat van het inzetten van een werkstation die zich puur en alleen met één ding bezig houdt: VTV Berekeningen. Zodra ze eenmaal de VTV van een bepaalde Artikel-/Verschijning berekend heeft, slaat ze de resultaten van die VTV op in een tabel op het netwerk, opdat andere tools (zoals dit VTV scherm) daar de laatst berekende data uit kunnen putten.
Bij Parameters Artikelen (Hoofdmenu, F5, F5, C, Tabblad #5) kunnen we aangeven of we VTV berekeningen willen opslaan op het netwerk, en zo ja, hoeveel dagen we dit vooruit willen opslaan. Hoe groter het aantal dagen is wat we hier invullen, des te meer tijd zal de VTV berekening en het opslaan van haar data in beslag nemen; immers, het VTV resultaat wordt per datum opgeslagen. 14 dagen vooruit betekent dus dat er een faktor 14x zoveel record geschreven moeten worden. Welke waarde u hier moet invullen hangt van uw praktijk situatie af.
Indien de parameters zijn ingesteld zullen we een werkstation moeten vrijmaken voor een dedicated job 'VTV Berekeningen maken'. Via Hoofdmenu-1-1-1-2-3 gaan we naar Massaal Herberekenen VTV gegevens. Willen we deze slechts een keer testen, dan hoeven we hem niet als 'Continue Proces' op te starten, maar, bij Continue Proces = Ja, zal de funktie continue blijven pollen naar Artikelen waaraan iets is gewijzigd om vervolgens de VTV opnieuw te berekenen. Is de VTV van een Artikel eenmaal berekend, dan wordt dit bij het Artikel geregistreerd, en komt dit Artikel pas weer aan de beurt voor een nieuwe VTV berekening als "iets" triggert dat de VTV opnieuw berekend moet worden; dit kan het plaatsen van een order zijn, of bijv. een verandering in de voorraadhoeveelheid.
Middels een 'wachttijd' kunnen we aangeven hoe lang het continue proces moet wachten alvorens ze zichzelf weer opnieuw opstart. Hoe korter deze termijn gehouden wordt, des te aktueler de VTV resultaten zullen zijn (immers, uw Artikel komt eerder in aanmerking om opnieuw berekend te worden). Vanzelfsprekend houdt dat ook in dat het systeem dan vaker staat te 'pollen' naar wijzigingen, wat meer 'kracht' vergt van de computer. T.b.v. automatische backups kunnen we aangeven hoe laat het proces 's avonds haar VTV berekeningen moet staken, en hoe laat de run weer hervat mag worden. In bovenstaand scherm staat dat ingesteld op 23:00 stoppen en om 04:00 weer verder gaan.
Via Hoofdmenu,1,1,1,2,6 vinden we een tool waarmee we voor een op te geven range Artikelen expliciet de trigger die er voor zorgt dat de VTV opnieuw berekend moet worden kunnen aanzetten. Deze optie zal de 1e keer gebruikt kunnen/moeten worden.
Bovenstaande funktionaliteit was dus al ontwikkeld voor "Raadlegen Artikel-/Verschijningen met VTV", en naast die funktie is er nu een nieuw overzicht ontwikkeld "Raadplegen Artikel-/Verschijningen met Bestelniveau". Die funktionaliteit starten we op vanuit scherm LOVABNTK (Hoofdmenu-1-1-1-2-2-2). Hier kunnen we een aantal selekties opgeven (desnoods via Profit-DynScreen te vullen) t.b.v. het navolgende VTV scherm.
Na F1 wordt er een nieuw Form opgebouwd. Bovenin het scherm treffen we een aantal rubrieken aan waarmee we wat settings kunnen wijzigen, vervolgens hebben we twee Grids. Een eerste waarin de Artikel-/Verschijningen met hun VTV gegevens worden getoond, een tweede met daarin het VVV (Verwacht Voorraad Verloop) van het geselekteerde produkt.
VTV gegevens:In het bovenste Grid treffen we per Artikel-/Verschijning de resultaten van de VTV berekening aan, alsmede het Bestelniveau wat is ingevuld bij die Artikel-/Verschijning. Middels kolom 'Max.Bh.Dtm' wordt de hoogste behoeftedatum weergegeven. Op basis daarvan kan worden gekonstateerd dat er meer data is dan wij nu opvragen. Denk daarbij aan het feit dat wij het VTV scherm "per morgen" opvragen, maar Profit hier toont dat er volgende week ook behoeftes zijn.
Legenda:Afhankelijk van het VTV resultaat krijg de regel in het scherm een ander kleurtje. In de Legenda vinden we de mogelijke kleuren terug:
Groen zegt dat we veel meer op voorraad hebben (verwachten) dan het Bestelniveau; we hoeven dus niets te doen.
Oranje geeft aan dat de VTV onder het Bestelniveau ligt. Wat dat betreft zouden we dus voorraad moeten gaan aanvullen, maar aangezien de VTV groter is dan 0, zal er nog niet direkt iets verkeerd gaan als we dat niet onmiddellijk inkopen.
Rood geeft aan dat de VTV onder het Bestelniveau ligt, en dat de VTV negatief is. Ofwel, als we nu niet onmiddellijk ingrijpen, zullen we iemand "nee" moeten verkopen.
Geel geeft aan dat de Aktiefperiode van dit produkt zodanig is ingevuld dat de voorraad leegverkocht moet worden; ze staat op 'uitloop'.
Verwacht Voorraad Verloop:Als we in het bovenste grid een Artikel-/Verschijning selekteren, dan wordt in het onderste grid een Verwacht Voorraad Verloop getoond. De in het onderste grid getoonde informatie zou feitelijk de specifikatie betreffen van de VTV specifikatie die we in het bovenste grid zien. Het VVV toont op zich altijd alle data t/m 31-12-9999, maar, alle regels die buiten de opgegeven datum scope vallen, zullen hier een gedisablede kleur krijgen. Ofwel, vragen we de VTV op t/m vandaag, dan zal alles vanaf morgen disabled zijn.
Nb: Merk op dat de VTV berekening hier ook op zoek gaat naar Intercompany Verkooporders die vanuit onze voorraad geleverd zullen moeten gaan worden, maar nog niet bij ons zijn ingekocht. Ofwel, als NL een Verkooporder heeft aan een Debiteur, en die order is ingevuld als zijnde "deze zal aan Turkije worden gaan uitbesteedt", dan staat deze al in het VTV van Turkije nog vóórdat de order daadwerkelijk is uitbesteed aan Turkije.
Settings:Linkerdeel ArtikelnummerBovenin het scherm kunnen we een filter leggen op het linkerdeel van de te presenteren Artikelnummers. Vullen we hier "202" in, dan toont het overzicht alleen nog maar de Artikelnummers die beginnen met 202. Door zo'n filter zal het scherm een stuk sneller kunnen worden opgebouwd, immers er hoeft minder data berekend en getoond te worden.
Herberekenen indien nodig J/NAls "Herberekenen indien nodig J/N" op "Ja" wordt gezet zal uw werkstation, als ze een Artikel raakt waarvan de VTV berekening nog niet is opgepakt door de PC die de VTV berekeningen voor haar rekening neemt, on-the-fly (ter plekke) alsnog de aktuele gegevens berekenen. Middels deze optie heeft u altijd de meest aktuele data, maar, let op, hierdoor gaat uw werkstation deze berekeningen uitvoeren wat de hele schermopbouw niet ten gunste zal komen.
Weergeven indien geen VTV J/NStandaard worden alleen VTV gegevens berekend en opgeslagen van Artikelen die "in gebruik" zijn. Artikelen waarvan voorraad is of waar orders voor zijn. Artikelen waar geen orders voor zijn (ofwel, waarvan het VVV een leeg grid zou opleveren) worden niet getoond. Middels deze rubriek kan worden aangegeven dat het Grid toch ook moet worden aangevuld met die kombinaties Artikel-/Verschijningen. Het op "Ja" zetten van deze rubriek triggert de mogelijke opname van een hele boel extra Artikel-/Verschijningen.
Alleen onderschreden BestelniveauAls rubriek 'Alleen onderschreden Bestelniveau J/N" met "Ja" wordt beantwoord, zullen alleen die Artikel-/Verschijningen worden getoond waarvan de VTV onder het Bestelniveau uit komt. Ze elimineert dus a.h.w. alle groene regels uit het overzicht, en toont de Artikelen die kwa voorraadhoogte zullen moeten worden aangevuld.
Alleen VTV < 0 òf VTV > 0Middels de navolgende rubrieken kan een filter worden gelegd op het enkel tonen van Artikel-/Verschijningen waarvan de VTV negatief is, of juist niet.
Expliciet verversenRechts boven het VTV Grid vinden we een button 'Verversen'. Als we hier op clicken wordt de data op ons scherm expliciet geaktualiseerd. Deze knop kunnen we gebruiken als we bijv. geen andere data willen opvragen, maar de data die al op het scherm staat willen vernieuwen.
Bovenstaande biedt ons op zich al inzicht in de VTV gegevens van onze Artikelen. We kunnen haar afzetten tegen het Bestelniveau (berekend met de eerder genoemde tool, danwel handmatig kwa waarde ingevuld). Het biedt al een basis om inzicht te tonen van welke Artikel-/Verschijningen we te weinig voorraad hebben en hoe kritiek dat dat is. Maar... we gaan nog een stapje verder...
Alternatieve ArtikelenAls we in het VTV Grid een Artikel selekteren, dan wordt de control 'Alternatieve Artikelen' enabled:
Vinken we de rubriek 'Alternatieve Artikelen' aan, dan zal het VTV scherm in een iets andere modus komen, waarin ze alleen nog maar alle 'Afkomst' varianten toont van het geselekteerde produkt. Ofwel, ze toont dan zowel de AD als de AZ (maar eventueel ook een AM, AL, AF etc.) We kiezen dus a.h.w. ons produkt, en zien in welke varianten dit produkt beschikbaar is.
Nb: Merk op dat door deze selektie alle 202A?0275 Artikelen in één overzicht getoond worden, waar er anders nog duizenden Artikelen zouden kunnen staan tussen de 202AD0275 en de 202AZ0275.
De oplettende lezer zal zijn opgevallen dat het Grid nu ook is uitgebreid met een kolom die de voorraad toont uit ons Nederlandse Intercompany Bedrijf. Hiermee kijken we rechtstreeks in de voorraad van ons Nederlandse Intercompany Bedrijf; zo kunnen we zien of Nederland het door ons gewenste produkt al dan niet op voorraad heeft (waarmee overigens nog niet is gezegd dat hetgeen op voorraad ligt ook 'vrij beschikbaar' is; dat wellicht in een volgende versie op te lossen).
Voorraadhoogte uit andere Bedrijven tonen
Waar we in de berekening van de Veiligheidsvoorraad en het Bestelniveau 'hard' de voorraadhoogte uit Nederland, Spanje en Griekenland hebben opgenomen, wordt e.e.a. in deze tool volledig dynamisch bepaald! Het scherm bepaalt zélf van welke lokaties er voorraad getoond moet worden. Dit werkt als volgt:
Tot op heden hebben we het in dit topic over twee bedrijven gehad: Nederland en Turkije. In praktijk is er nóg een bedrijf aan de order: Italië!
De voorraad in Italië is in bovenstaande schermprint niet opgenomen als voorraad kolom, simpelweg omdat "Turkije niet inkoopt bij Italië"; de basis heeft dus te maken met "welk van de Intercompany Bedrijven die we in Profit zijn geregistreerd zijn in Turkije als "Crediteur" opgenomen, immers, als Italië niet als Crediteur is opgenomen zullen we niet kunnen inkopen bij Italië en dus heeft het geen zin om in de voorraad te kijken van Italië. Andersom, we hoeven maar in het Turkse Bedrijf ons Italiaanse Intercompany Bedrijf als Crediteur op te nemen, en de voorraad van Italië wordt zichtbaar.
En om hier een stapje verder te gaan, heeft het niet zo zeer te maken met de Crediteur, maar eerder met zijn Ophaaladressen. Bij een Ophaaladres van Intercompany Crediteur kunnen we nèt even iets meer invullen als bij een Ophaaladres van een normale Crediteur. Zo kunnen we afdwingen dat áls we iets in Nederland kopen, vanaf welke Raapvloer dit geleverd moet worden in het Intercompany Bedrijf. Die mogelijkheid stelt ons dus ook in staat om van Turkije in te kopen bij Nederland, en Nederland dit te laten leveren vanaf Raapvloer "Spanje" of "Griekenland". Daarna geldt weer dat ómdat we kunnen inkopen uit de voorraad van Spanje, we ook de wens zullen hebben om in de voorraadhoogte van Spanje te kunnen kijken.
Hoewel we de definities van deze Ophaaladressen al konden maken, zijn deze nu uitgebreid met de mogelijkheid een korte omschrijving op te kunnen geven, zoals deze boven de voorraadkolom in het VTV Grid kan worden opgenomen. Op die manier kan Turkije zelf een duidelijke omschrijving verzinnen die representatief is voor die voorraad kolommen; desgewenst in het Turks.
Stel dat we bij ons Nederlandse Intercompany Bedrijf nog een aantal Ophaaladressen opnemen (en vanuit dat bedrijf te leveren vanaf diverse Externe Magazijnen als Raapvloer) dan biedt het Ophaaladres nu de mogelijkheid hier korte omschrijvingen aan toe te kennen:
Met dat we deze Ophaaladressen hebben gedefiniëerd en terugkeren naar het VTV scherm, dan zorgt het feit dat we nu formeel kunnen inkopen vanaf deze Lokaties, er kolommen worden opgenomen met de voorraadhoogte van die Lokaties, en omschreven zoals is ingericht bij die Ophaaladressen.
Ongeacht RaapvloerDat een Inkoop op Ophaaladres #4 (Spanje Madrid) vanuit het Intercompany Bedrijf moet worden geleverd vanaf Raapvloer "SM" is op zich wel duidelijk. Alle voorraad die op Lokaties ligt welke (kwa linkerdeel) beginnen met "SM" tellen mee voor de voorraadhoogte van "SM". Kijken we bij Ophaaladres 0, dan staat daar géén Raapvloer ingevuld!
De Raapvloer leeglaten kan niet impliceren dat we van "alle Lokaties" mogen leveren, immers, dan zou ook voorraad uit Spanje in aanmerking komen. Sinds kort kunnen we expliciet aangeven uit welke Magazijnen we Verkooporderregels mogen leveren waarvan de Raapvloer niet is ingevuld. Dit zullen we moeten doen om in één klap alle uitzonderingen uit te kunnen sluiten; denk maar aan het niet mogen afboeken van voorraad op Klantlokaties, van Ophaalkaarten, Dositainers, Vulstations etc.
Deze instelling moeten we doen in het bedrijf van waaruit geleverd wordt; "Nederland" dus in ons voorbeeld, immers daar zal een Leverorder worden geplaatst om te leveren vanaf Raapvloer <leeg>.
Als we in Turkije het VTV scherm oproepen, weet het VTV scherm dat we bij Nederland in kunnen kopen, dat dit gebeurt via Raapvloer <leeg>, bepaalt ze welke Raapvloeren er in Nederland gedefinieerd zijn als "Dekkend voor Verkooporderregels waarvan de Raapvloer leeg is", en zal de voorraadhoogte die in het VTV scherm getoond wordt worden bepaald door de som van alle voorraad (van de betreffende Artikel-/Verschijning) die in dié Magazijnen ligt.
Praatplaat
Alle hierboven beschreven programmatuur is wat pragmatisch ontwikkeld. Het geheel is a.h.w. een soort praatplaat waarbij de ontwikkeling van de ene stap weer idee-tjes vormt voor de verdere aanpak. Ondanks dat we Turkije met bovenstaande schermen tools bieden om in te zien hoeveel er moet worden ingekocht, welk Artikel (AD/AZ) er moet worden verkocht, wat de voorraad stand van alle Intercompany Bedrijven is, is het geheel nog niet "af" (al was het maar omdat het scherm geen mogelijkheid biedt een Intercompany Inkooporder te genereren). Toch tonen de schermen wel het potentieel en zal dit topic als praatplaat kunnen dienen om te kijken hoe we er straks mee verder gaan.
