Per heden is gekonstateerd dat het via de funktionaliteit "Terugdraaien Produktieorder" redelijk eenvoudig mogelijk was om Voorraad te kreëren met een aantal van 0 stuks (die vervolgens met geen mogelijkheid meer uit het systeem te verwijderen waren).
De oorzaak zit hem in de funktionaliteit "Terugdraaien Produktieorder", waarvan de helptekst al aangeeft dat deze funktie feitelijk nooit ontwikkeld had mogen worden, en waarvan we ook niet garanderen dat ze kan werken (zonder wellicht uren aan aanvullend maatwerk).
De funktionaliteit is echter toch ontwikkeld, en kan in sommige situaties wel degelijk worden gebruikt, toch gaat het zo af en toe fout, waarvan vandaag een voorbeeld:
Stel dat we een Produktieorder hebben van 1000 Kg, en we dit moeten afvullen in 40 zakken van 25 Kg. Bij het opboeken van de Produktieorder boeken we per ongeluk 52 zakken op, waardoor de prijs per eenheid kompleet verkeerd is. Doel is nu dat we de P.O. kunnen terugdraaien, dan de 52 verkeerde zakken van voorraad worden afgeboekt, en dat we de handeling opnieuw kunnen verrichten.
Probleem is echter dat voor een juiste werking, er teveel variabelen meespelen die formeel geregistreerd zouden moeten worden willen we dit juist kunnen laten werken.
Bij het terugdraaien van de P.O. werd de Werkelijke Inhoud van de P.O. output opnieuw opgehaald bij de Verschijningsvorm. Leuk, voor situaties waarin we altijd precies volle zakken produceren, maar dit gaat fout zodra we daarvan afwijken.
In het konkrete voorbeeld werd dan ook 40 Kg geproduceerd in een kuip van 3000 Kg. De P.O. output bevatte eerst 40 Kg in een KUIP. Echter, bij het terugdraaien van de P.O. werd de 40 Kg opnieuw verdeeld over de standaard inhoud van die kuip, en die stond op 3000 Kg, daarmee resulterend in een Aantal Verschijningen van 0,013.
Frappant genoeg bevat de tabel "Output Produktieorder" een Aantal Verschijningen in
3 decimalen, en dit, terwijl we bij opboeken géén decimalen kunnen opgeven. Zouden we echter naar boeken gaan, dan was het aantal nog steeds 0,013 Verschijningen, welke hoeveelheid <> 0 was en waardoor de regel
niet werd afgesloten, maar, omdat een Voorraaditem géén decimalen kent bij "een Aantal", werd de 0,013 aldaar afgekapt tot een voorraad van 0 stuks !
Let op: Waarom het Aantal Verschijningen bij de Output van een Produktieorder in 3 decimalen staat ontgaat mij, maar het lijkt te maken te hebben met het gebruik van Bijprodukten.
Het opnieuw ophalen van de standaard inhoud van de Verschijningsvorm kán in theorie voor sommige gewenst zijn, maar hoeft niet. Merk ook op dat het bewust iemands doel kan zijn om (klant specifiek) een Produktieorder toe te voegen, en 1000 Kg te produceren in zakken van 25 Kg, doch waarbij slechts 18,5 Kg in iedere zak moet worden afgevuld (opdat de klant hele zakken in zijn produktieproces kan verwerken). De initiële Produktieorder zou daarmee uitkomen op 54 zakken van 18,5 Kg, met nog een restant.
In dit voorbeeld was het zo, dat na terugdraaien van de PO, de output werd teruggezet naar 40 zakken van 25 Kg, omdat de 25 Kg opnieuw werd opgehaald, precies niet wat we zouden willen, immers, de 18,5 Kg gaat verloren.
Maar ja, passen we dit wél aan, dan geldt dat als we 100 x 4 moesten produceren in blikken van 5 liter, en we per ongeluk 100 x 5 hadden opgeboekt, na terugdraaien van de produktieorder de opdracht ineens wordt "400 liter produceren in blikken van 5 liter, ofwel 80x5" en dat is ook verkeerd.
Resumer, een probleem als deze is zonder maatwerk niet oplosbaar (zie helptekst) en met een poging dit op te lossen, kreëren we al snel ellende voor een volgende.
Derhalve is de oplossing in deze Releasenote:
De nieuwe Inhoud wordt opnieuw opgehaald bij de Verschijningsvorm (zoals het voorheen ook werkte), maar, mag nooit groter zijn dan het aantal te produceren eenheden. Ofwel, indien we 40 Kg produceren in een kuip van 3000 Kg, dan zal de inhoud maximaal 40 Kg mogen bedragen, zodat er 1x40 in de output terugkomt (ipv 0,013x3000).
| Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz |
| LOPOTDVW | Omschrijving (nog) niet bekend | 08-09-2009 | 19-01-2012 |
