Met ingang van deze Releasenote is de berekening van Behoeftes ongeacht de Verschijningsvorm aan Koop-artikelen drastisch veranderd. Behoeftes in ------- werden v.w.b. Koop-artikelen altijd al uitgesteld tot de laatste Behoefterun doorloop. Dit gebeurde, omdat er anders situaties konden ontstaan waarbij op meerdere niveau's een behoefte ontstond aan het produkt, en de behoefte op het lagere niveau, de vorige onderuit haalde.
Om dit met een klein voorbeeld duidelijk te maken: Stel we hebben een eindprodukt E1 die behoefte heeft aan aan halffabrikaat H1 en o.a. een grondstof G1. Het halffabrikaat H1 behoeft dezelfde G1 en heeft een produktietijd van 2 dagen.
Zou de behoefte aan Koop-artikelen nu niet worden uitgesteld t/m het laatste niveau, dan zouden we eerst een behoefte krijgen aan G1 vanuit niveau #1 en deze dekken mét Bestelniveau en EOQ, om vervolgens op niveau #2 (de uitwerking van het halffabrikaat) te moeten konstateren dat we nogmaals G1 nodig hebben, maar nu 2 dagen eerder, waarbij wéér de EOQ aan de orde is, en deze bestelling er misschien wel voor zorgt dat de andere niet meer nodig was.
Nb: Voor Produktieartikelen geldt in theorie precies hetzelfde, maar die worden vooralsnog per niveau afgehandeld. Dit kan weinig anders, immers, we zouden niet eens aan niveau #2 toekomen als we niet eerst niveau #1 mogen uitwerken.
Behoeftes aan ------- die in slechts één Verschijningsvorm zouden kunnen worden besteld (omdat er maar één Verschijningsvorm aan het Artikel gekoppeld is waarbij "Afnemen Inhoud" op Ja staat, én welke Aktief is én welke ook kan worden ingekocht (omdat er een Leverancier is opgenomen) worden nu omgezet in behoeftes géacht die ene Verschijningsvorm.
Uitzondering op de regel is de situatie waarbij een Artikel twee Verschijningsvormen kent (zak 10 Kg en zak 15 Kg) en de laatste op niet-aktief staat (omdat er voor een andere Leverancier is gekozen die het produkt goedkoper levert, maar we het wel per 10 kg moeten bestellen).
In die situatie geldt weliswaar dat we alleen nog kunnen inkopen in zakken van 10 kg, maar, als we nog voorraad hébben in zakken van 15 Kg, of indien er al Inkooporders staan met bestellingen van dit produkt in zakken van 15 Kg, dan moet die voorraad eerst opgesoupeerd worden. Hierdoor zal nu een deel van de behoefte in ------- worden gedekt door de op voorraad liggende zakken van 15 kg, en een eventueel tekort zal daarna worden gedekt door zakken van 10 kg.
Ook is er kwa afhandeling van Onderschreden Behoeftes e.e.a. veranderd!
Jaren geleden werden Onderschreden Behoeftes als Behoefte records "per vandaag" opgenomen, daarmee "per vandaag" triggerend dat deze Artikelen door de Behoefterun werden verwerkt waarbij meteen werd gekonstateerd of/dat het Bestelniveau was onderschreden. In deze Releasenote is dit volledig op zijn kop gezet, en wel om de volgende redenen.
Allereerst geldt dat als wij vandaag bij een Artikel-/Verschijning (waarvan we géén voorraad en/of orders hebben) een Bestelniveau opnemen, we (uiteraard) per direkt "in de min gaan". Vanaf het moment dat we zeggen dat we 100 blikken op voorraad willen aanhouden terwijl we helemaal geen voorraad hebben, komen we direkt onder het Bestelniveau uit en zal er besteld moeten worden.
Als we 14 dagen Inkooptijd hebben, dan gold dus eigenlijk dat we dit produkt 14 dagen geleden al hadden moeten inkopen! Op zich is dat natuurlijk waar, maar, iets in het verleden inkopen kan natuurlijk niet. Alleen al door dit Bestelniveau toonde de Behoefterun een heleboel Besteladviesregels die in het verleden lagen. Het deel hierin wat afkomstig is uit onderschreden Bestelniveau's is daarin nu geëlimineerd, door deze Onderschreden Behoeftes verder in de toekomst te leggen, zodat als daarna de Inkooptijd er af wordt gehaald, we "ongeveer" op vandaag uitkomen. "Ongeveer" klinkt dan al weer raar, maar heeft alles te maken met hoe we onze kalenders definieren, en hoe weer andere parameters staan ingesteld hoe de Produktie-/Inkooptijd moet worden afgehandeld. Zo zal Produktie-/Inkoop methode #2 en #3 stellen dat we de Inkooptijd aftrekken van de Behoeftedatum, en dan in de kalender kijken naar de eerst vorige dag.
Nb: En met dat ik dat schrijf, kan al weer het volgende vraagteken worden geplaatst, immers, als een Leverancier alleen op dinsdag en donderdag levert, zou juist eerst de Behoeftedatum moeten worden omgezet naar de eerst vorige dinsdag/donderdag, en zou je 5 dagen daarvoor je bestelling willen plaatsen. De wijze waarop e.e.a. beoordeeld wordt hangt dus mede af van de manier waarop e.e.a. wordt gebruikt. De Kalender van een Leverancier is oorspronkelijk bedoeld als Kalender met openingstijden van die Leverancier, maar net als dat je zélf routes plant en bepaalde Afleveradressen niet iedere dag aan doet, zou dat ook voor de Leverancier mogen gelden.
Door deze aanpassing is een groot deel van de Behoeftes in het verleden "verleden tijd" :-)
Het is overigens nog steeds mogelijk dát er Behoeftes in het Besteladvies komen te staan met een negatief aantal dagen, maar, dan zou het zo moeten zijn dat dit ook echt zo is. Een Verkooporder die vorige maand geleverd had moeten worden kán niet per vorige maand geleverd worden; de Leverdatum had bijgesteld moeten worden naar een realistische waarde.
Iets wat erg simpel klinkt (zet gewoon alle Besteladviezen in het verleden op vandaag) is kwa berekening toch een stuk complexer. Bedenk ook dat we te maken hebben met situatie waarbij de Gebruiker zal Behoeftes in het verleden heeft! Verkooporders die vorige week al de deur uit hadden gemoeten, maar waar toen geen voorraad voor was, maar waarbij ook niemand de Leverdatum heeft opgeschoven. We kunnen nu wel simpelweg in het Besteladvies een behoeftedatum uit het verleden op "vandaag" zetten, maar daarmee is de behoefte "per vorige week" niet gedekt. Merk ook op dat veel Gebruikers het negatief aantal dagen in het Besteladvies (waar ook een speciale Raadpleegfunktie voor is ontwikkeld)
juisT inzichtelijk maakt welk van de produkten "nu eindelijk eens als eerste aan de beurt is" (omdat ze zoveel dagen in de min ligt) en welke informatie we kwijt zijn als we alles op vandaag (0 dagen) zetten. Dit deel (dus de behoeftes die niet het gevolg zijn van onderschreden Bestelniveau's) kan dus alsnog tot negatieve behoeftedata leiden.
Een volgende aanpassing in de afhandeling van de Onderschreden Behoeftes, is dat deze nu voor Koop-artikelen pas achteraf worden toegepast. De Behoefterun berekent nu eerst wat er echt nodig is (waarbij voor die Artikelen per de datum waarop het produkt behoeftig is dit al tegen het Bestelniveau wordt afgezet). Pas daarna volgt in de extra doorloop de afhandeling van de Onderschreden Bestelniveau's voor enkel nog die Artikelen die in de Behoefterun zelf nog niet waren verwerkt (omdat er geen orders voor waren).
Dan tenslotte nog een performance aanpassing welke tot uiting komt als we een Behoefterun draaien met een filter op "enkel grondstofbehoefte, of de Koop-artikelen uit de lopende orders". Zodra rubriek Behoefterun Artikelen */E/I/G/R/K met "G" of "K" wordt gevuld geven we al aan dat alle behoeftes aan bijv. Eindprodukten en Halffabrikaten zelf moeten worden overgeslagen. Het Besteladvies zal dus nimmer Produktieartikelen bevatten. Daarmee is het ook niet zinvol om alle Produktie Artikel-/Verschijningen te doorlopen om te kijken of deze onder het Bestelniveau uitkomen, immers, de Produktieartikelen worden toch niet verwerkt in de Behoefterun; het kontroleren hierop nam alleen maar onnodige tijd in beslag.
| Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz |
| LOBHC8B3 | Omschrijving (nog) niet bekend | - - | 13-05-2019 |
| LOBHGN | Omschrijving (nog) niet bekend | 10-05-2019 | 10-05-2019 |
| LOBHGNVI | Omschrijving (nog) niet bekend | 08-04-2019 | 13-05-2019 |
| LOBHOB | Omschrijving (nog) niet bekend | 21-09-2016 | 14-05-2019 |
| LOBHOBMS | Omschrijving (nog) niet bekend | 10-05-2019 | 10-05-2019 |
| LOBHOBOB | Omschrijving (nog) niet bekend | - - | 14-05-2019 |
| LOBHOBTD | Omschrijving (nog) niet bekend | 09-05-2019 | 14-05-2019 |
| LOBHOI9 | Omschrijving (nog) niet bekend | 25-04-2019 | 14-05-2019 |
| LOOFT | Omschrijving (nog) niet bekend | 25-04-2019 | 13-05-2019 |
| LOPBGNF1 | Omschrijving (nog) niet bekend | 04-01-2019 | 10-05-2019 |
| LOPBIVGN | Genereren Produktiebehoefte | 08-05-2019 | 14-05-2019 |
| LOPIGN | Omschrijving (nog) niet bekend | 10-04-2019 | 10-05-2019 |
| LOPIGN2 | Omschrijving (nog) niet bekend | 10-05-2019 | 10-05-2019 |
| LOPIGN5 | Omschrijving (nog) niet bekend | - - | 10-05-2019 |
| LOPITDB2 | Omschrijving (nog) niet bekend | 13-12-2016 | 10-05-2019 |
