Specifieke situatie is te complex om uit te leggen gezien het aantal faktoren wat een rol speelt om dit te kunnen reproduceren, maar, ik het kort komt het eropneer dat zodra er een Behoefterun van één Artikel werd gedraaid, er een ander resultaat werd getoond dat indien er een totale Behoefterun werd gedraaid.
Hoewel e.d. situatie bij een grondstof welke in produktie gebruikt wordt best zou kunnen optreden (waar overige eindprodukten niet verwerkt worden, zal ook de daaruit ontstane behoefte aan grondstoffen niet meetellen), betrof het in dit geval puur een handelsgoed.
De fout werd veroorzaakt doordat er bij het ontstaan van een behoefte vanuit Produktie, danwel bij een behoefte ongeacht de Verschijning, danwel een Verschijning die moet worden omgevormd uit een andere, er altijd een nieuwe doorloop v/h Behoefterun wordt gegenereerd. Zodra het om een Koop-behoefte gaat, vond die extra doorloop niet plaats, immers, waarom? Koopbehoeftes geacht de verschijningsvorm zouden in één doorloop gedekt moeten kunnen worden.
De extra doorloop die hier ontbrak leidde tot een extra bestelling, welke op zich ook weer een fout (of beter, dé fout) betrof. Bij het toepassen van rubriek "Aantal dagen salderen Behoefte" wordt dit aantal dagen toegepast op de éérst gevonden behoeftedatum waarop het Artikel onder het bestelniveau raakt. Nu kan er echter een situatie ontstaan waarbij er normaal gesproken met 4 weken salderen een behoefte gedekt wordt door iets wat over 3 weken binnenkomt, doch dat om een andere reden er alsnog een bestelling in het verleden gegenereerd wordt, waardoor in een volgende doorloop het "vooruit
kijken" niet meer funktioneert. Zie een volgende Releasenote.
| Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz |
| LOPIGN | Omschrijving (nog) niet bekend | 03-05-2005 | 03-05-2005 |
