Heart-Profit ERP

Per heden is gekonstateerd dat Terugdraaien Produktieorder (funktionaliteit welke, zie helptekst, slechts onder zeer strikte kondities mogelijk is) niet werkt indien de afgeboekte materialen in de Produktieorder 'Her te gebruiken Emballage' impliceert.

M.i.v. deze Releasenote is formeel een kontrole opgenomen die konstateert dat de afgeboekte materialen Her te gebruiken Emballage impliceert,  en terugdraaien dan niet meer toestaat.

Middels aanvullend maatwerk zou deze situatie (mogelijk) alsnog werkbaar gemaakt kunnen worden. Hiertoe zal eerst moeten kunnen worden herkend dát er Emballage leeg geraakt is tijdens het afboeken van deze Produktieorder.  
 
 

Funktie	Omschrijving	Dtm.Vl.Wyz	Dtm.L.Wyz
LOPOTDVW	Omschrijving (nog) niet bekend	09-11-2005	06-06-2007

Ik hoop dat dit een parameter gestuurde aanpassing is....

AD heeft deze functie speciaal laten maken (lang geleden) en gebruikt voor > 90% niet geserienummerde hergebruik emballage voor de opslag van semi bulk grondstoffen.
Het uitschakelen van deze functie betekent dat wij een verkeerd geboekte PO niet meer kunnen terugdraaien en dat de gewenste tracebility voor grondstoffen en eindproducten niet meer is te realiseren.

Dan weet je ook als geen ander onder welke strikte regels dat maatwerk gemaakt is (zie helptekst), en had je wel eens mogen konstateren dat dit al die jaren dat je het gebruikt hebt niet werkte ! Toch?

Een parameter gestuurde aanpassing is het in ieder geval niet. Hoe zou dit moeten heten? "Wil je het bewust in de soep laten lopen of niet J/N"?

Nee,
Maar wij hebben deze programmatuur specifiek laten maken.
En we kennen de (on)-mogelijkheden

Nu bouw je een controle in op een punt waar wij (heart en ad) ons juist tijdens de ontwikkeling al van bewust waren en welke als acceptabel is opgenomen.
Als dit betekent dat de functie voor AD niet meer werkbaar is wordt ik daar niet blij van.
(zie ook helptekst)
Voor AD is de tracibility van de "Grondstoffen" belangrijker geacht dan de tracibility van de gebruikte "containers", welk voorbehoud ook duidelijk in de helptekst is opgenomen.

Wij werken veel voor organisaties waar het van essentieel belang is dat er een 1:1 registratie is van de verbruikte batches grondstoffen en het uiteindelijke materiaal ivm schadeclaims e.d.

Ik kan echt niet als iemand computertechnisch een verkeerd batchnummer grondstof afboekt zeggen "jammer dan". De optie om een PO terug te kunnen draaien is specifiek voor dat soort situaties gemaakt.

Nope. Dit was toen natuurlijk niet bekend, anders had het (minimaal) expliciet in de helptekst gestaan.
We maken natuurlijk nooit dingen waarvan we vooraf al weten dat het 100% zeker fout gaat.

Daar kan ik inkomen, neemt niet weg "dat het dus maar klakkeloos fout moet/mag gaan".


Het voorbeeld beschrijft de situatie dat als je een x aantal kilogram uit een kuip afboekt, en je daarna de PO terugdraait, het systeem dit aantal kilogram klakkeloos op voorraad terug zal leggen, zonder zich af te vragen of er destijds misschien een kuip is leeggeraakt.

Het wordt wel een heel ander verhaal indien jij vaten naar blikken gaat omvormen, de leeggeraakte vaten kan hergebruiken, het afboeken van de vaten lege vaten terugzet op voorraad, maar het terugdraaien van de PO dit niet terugdraait.
Je administratieve voorraad van emballage moet ondertussen barsten van de lege vaten waar die er in werkelijkheid niet zijn.



Nope; al was het maar omdat de aanbieding die je kreeg ooit al eens voor een ander gemaakt was maar toen niet afgenomen was. Het is bedoeld om te kunnen korrigeren. Als jij dat verder al doet bij het afboeken van een verkeerde batch, prima, maar daar is het natuurlijk niet expliciet voor gemaakt  :wink:

Resumer: Ik zal de blokkade wijzigen in een waarschuwing. Dan kiest de gebruiker er zelf maar voor of ze het bewust fout wil laten gaan (lees: de verschillen in voorraad emballage op de koop toeneemt). Ze zal er in ieder geval wel iedere keer op worden gewezen. Na de melding behoor je niet verder te gaan; doe je dat toch, dan accepteer je de verschillen.

met dank voor deze "oplossing"
Dat de emballage boekhouding scheef liep wist ik al.

Alleen ik had deze nog niet gevonden.
Wel bij omvormen... =)

Zal in ieder geval hier nog eens dieper induiken.
Als het ooit ter sprake zal komen? Kan heart dit in de toekomst mogelijk wel formeel ondervangen (dus boekingen op PO 1:1 terugdraaien?)

Zie je wel.  :wink:


Natuurlijk, doch zal tijd (en dus geld) kosten; en "zo zou het nu al moeten worden opgelost".

Aha. En sinds wanneer doen wij dat soort dingen ? ... zonder overleg ?
Dat doen we dus NIET.

Is het intussen veranderd in een Waarschuwing ... maak maar weer ongedaan.

Ga ik intussen een tekstsearch doen naar de tekst van ene mdekraa die niets aan z'n gebruikers wil overlaten.

Heel iets anders is, is dat dit natuurlijk sowieso de oplossing niet is. Niet met bedrijfsparameter en niet zonder en niet met waarschuwing, niet zonder, en ook niet met foutmelding. Echter ...

Er resteert niets anders dan een foutmelding.
Als dat zonodig niet acceptabel is, dan kan er een Bedrijfsparameter komen waarmee het Terugboeken helemaal niet wordt toegestaan, dan wel wordt toegestaan met foutmelding in de betreffende situatie.

N.b.: Waarmee is dus ook geenszins aangeef dat de foutmelding acceptabel is.

En nu ?

Is gebeurd.

Is er nou niet iets te verzinnen voor dit soort zaken dat er een redelijk degelijke handleiding komt voor wat te doen in zo'n situatie ?

Dit dus i.v.m. mijn eigen ontevredenheid dat zoiets schier onoplosbaar zou zijn ...

Misschien een optie om deze functie zelf eens tegen het licht te houden?

De wens om een fout te kunnen corrigeren is op zich legitiem, analoog aan verwijderen inkoopontvangst en inkoopfacturen bijvoorbeeld.

Het probleem wordt veroorzaakt doordat niet alle functionaliteit welke aanwezig is in het afboeken en gereedmelden productieorder is opgenomen in deze in begin 2001 ontwikkelde functie; hoe complex deze dan ook op zich mag zijn (gezien het factuurbedrag van 2001).

Je mag gelijk hebben, maar eigenlijk is het niet zo;
Je moet dit denk ik meer zien in het licht van asynchrone processen (ik hoop eigenlijk dat je het nu niet meer kunt volgen :smile:) die niet asynchroon kunnen worden teruggedraaid. Maar ook niet "synchroon" omdat er intussen van alles is gebeurd. Dus :

Het omkeren van transakties is helemaal niet moeilijk, alleen het màg niet altijd, en de situaties waarin het niet mag zijn vaak niet eens in absolute zin te achterhalen.
Het is ook niet voor niets dat we er nu pas achter komen dat het met die Emballage niet goed gaat, wat feitelijk komt omdat bij het normale opboeken/afboeken het wat te, zeg, objectgericht gebeurt. Dus, dit is ooit gemaakt, maar intussen onzichtbaar.
Geeft niets als het ook weer onzichtbaar terug zou mogen, maar dat is nu net niet het geval. Dus, dit gebeurt ook niet, en vervolgens krijg je het expliciete van het rekening moeten houden met - waarbij je niet weet waarmee je rekening moet houden.
Vergelijk dit met het crediteren van bijvoorbeeld een Verkooporder, wat niet veel meer is dan àlles omdraaien wat er voorheen is gebeurd, en wat daar ook mag, omdat je er niets mee kunt verprutsen.

Ga het zojuist gereedgemelde produkt maar ergens ingooien, en je snapt meteen al dat je de order van dat gereedgemelde produkt niet meer terug kùnt draaien, ook al met de wetenschap dat je het daarna weer opnieuw zult opboeken. Je kunt gewoon geen kant uit met de Kostprijs van die volgende order ...

Aldus ontstaat de situatie dat wij -na 100 keer vragen van o.a. jouw kant-, onder de zeer speciale kondities het toch maken, waarbij die kondities NIET worden afgedwongen door het datamodel (zie Kostprijs voorbeeld). En dus wordt het maar hopen dat je overal aan denkt, een speciale autorisatie om het te doen, de helptekst lezen aangaande de risico's die je loopt en blablabla ...

Het enige wat je nu nog moet bedenken is dat

a. Jij (Marco) degene bent die als eerste dit soort zaken afdwingt, waar wij het 100 keer niet wilden;
b. Jij de eerste bent die je beroept op "Ja maar het is voor ons gemaakt".

Het laatste doe ik niets mee, want ik kan er niets mee. Je zou bij wijze van spreken in het hele pakket alles tegenhouden v.w.b. Emballage. Ik hoop dat je dit voorbeeld snapt. Dus, Terugdraaien PO wilde niemand behalve jij, en omdat wij die Emballage even niet zien, maar jij wel en je je vervolgens van de domme houdt omdat we je al 100 keer hadden gewaarschuwd ...
Jij leert er dus mee leven.

Mooi, maar een ander niet en die komt er mee. Oplossing : die ander mag dat terugdraaien niet gebruiken. Trouwens, jij ook niet, want het gaat gewoon fout. Het terugdraaien is bij deze dus niet zinvol meer, en dat je ervoor hebt betaald is je eigen schuld. Je wist het van tevoren. Dus eigenlijk juist omdat jij ervoor hebt betaald, ben jij ook de klos. Hoe bedenk ik het weer ... :innocent:


Wat echter blijft is mijn eigen ontevredenheid dat we hier niet uit zouden kunnen komen. Maar ik zal je wel vertellen dat *wij* niet 20 uur gaan besteden aan iets wat jij hoort te betalen omdat je je zou beroepen op je eigen maatwerk in deze, of zelfs dat het nu fout werkt.
Maatwerk wat eigenlijk niet hoort c.q. problemen kan opleveren bij bepaald gebruik, geeft nooit ergens recht op. Nooit. Mits we het voldoende hebben aangegeven. In dit geval (excerpt helptekst LOPOTD) :


LET OP!!!
Het terugdraaien van een Produktieorder naar status "T" is aan       
strikte gebruiksregels gekoppeld, omdat e.d. funktionaliteit         
eigenlijk onmogelijk is. Door deze funktie toe te staan gaan we       
immers met terugwerkende kracht de historische gegevens aanpassen,   
met alle problemen vandien. Tevens zullen voor een goede werking     
extra zaken in een traceability moeten worden geregistreerd, welke   
enkel voor deze toepassing als 'teveel omvattend' mag worden         
beschouwd, en derhalve expliciet achterwege is gebleven.             
...
Heart garandeert niet dat deze funktionaliteit in Uw toepassing       
gebruikt kan worden, en deze funktie kan derhalve enkel "as is"       
worden uitgevoerd. Onmogelijkheden aan deze funktionaliteit zullen   
nimmer als "bug" kunnen worden aangemeld, maar kunnen (misschien)     
gerealiseerd worden middels maatwerk.                                 


Sorry ...

En het enige wat we nu hebben gedaan, is gekonstateerd dat er een ernstige malleur in zat die een gebruiker niet kan overzien maar keihard fout gaat bij die betreffende klant, waarop wij e.e.a. hebben ondervangen met een simpele foutmelding.
Ik wil je er als laatste op wijzen dat wij zojuist 80 uur hebben besteed aan het oplossen van problematiek in een soortgelijke hoek aangaande Emballage (met zeg maar gelijke konsekwenties als die jij simpeltjes accepteert als dat niet zou worden opgelost), en dus ga we dat  aan deze kant (wat de betreffende gebruiker van het 80-uur probleem eveneens gebruikt) NOOIT toestaan.
Maar dat deden we toch al niet, al leek het daar vanmorgen even op.

Ik blijft je probleem trouwens begrijpen ...

Peter



PS: Houd je nog een beetje in de gaten dat dit voor ieders goed doel is, dus ook voor jou ?
Of hadden we met z'n allen toch liever dat het pakket maar een beetje "wat an" moet doen ?

Neeo hoor, ik snap het wel.

Maar na al zo'n kleine 20 jaar in productieomgevingen rondgehobbeld te hebben weet ik ook heel zeker dat fouten gemaakt worden bij het af- en opboeken van goederen.

Dat is de essentie van deze functie.
Immers wanneer iemand iets fout afboekt moet hij het kunnen corrigeren.
Zo doe je het ook bij verkeerde ontvangsten, betalinge e.d.

Deze functie is alleen daarvoor gemaakt dat de operator in staat is administratief te verantwoorden wat hij ook in de werkelijkheid heeft uitgevoerd.
Zodra je zegt dat hij na het perongeluk afboeken van 100.000 kg van een product ipv 100,000 van een product dit niet kan corrigeren dan krijg je problemen met voorraad, kostprijs eindproduct, marges, en verzin er nog maar een handvol.

Mijn verzoek is dan dus ook, kun je het gebruik wel toestaan middels authorisatie?
Dan kan ik die hangen aan een "power user"

Ik kan me n.l. heel goed voorstellen dat bij bovengenoemde voorbeeld het verschil in emballage als fout vele malen minder erg is dan de resulterende fouten in de gehele database mbt kostprijzen, marges enz.
(Eigenlijk als ik er verder over denk zit ik nou op hetzelfde niveau te discussieren als met de waarschuwing vs blokkade bij niet reeele productie winsten en verliezen  :'( waar ik dezelfde probleemstelling zie)

maar ja...

We zijn het heus wel eens.
Goed ook dat je hetgeen je het laatst noemt nog eens aanhaalt, want dat gaat lijnrecht in tegen wat je hier wilt (over gebruikers en zo).

De optie om het toch te mogen bij speciale autorisatie is misschien wel een goede.
Merk op dat je in dat geval de melding krijg met strekking : En als je op F1 drukt ZAL het fout zijn.

Wat er dan fout is moet je vervolgens zelf achterhalen, en WEET dat dat niet hetzelfde ZAL zijn als dat het was. Dit is dus weer zo'n persistente waarschuwing Marco. Dit omdat er momenteel veel wordt veranderd in de Emballage hoek (zie je ook wel aan de Releasenotes), al was het maar omdat zaken zoals onderhavig onjuist blijken (bleken).

De (eerlijk gezegd) werkelijke reden waarom ik gisteren nogal snel het voorstel van Wouter afkeurde (Waarschuwing), is omdat er best wel klanten zijn die aan het eind van het jaar (of wanneer ook) met onverklaarbare verschillen zitten, waarbij er hier een enveloppe in de bus dondert met de vriendelijke vraag of wij het willen uitzoeken. Moeten we nu gaan zeggen "zal wel aan dee gebruiker hebben gelegen die bevestigend heeft geantwoord" ? (jouw eigen opmerking feitelijk). Dat kàn toch niet ? ...
Als het systeem iets fout doet, dan moet het dat niet doen. Daarna ga je zelf wel lopen knoeien met bij/af en geen idee welke memoriaal boekingen/korrekties, en is er NIETS aan de hand.


Ik krijg intussen wel het gevoel dat we hier niet slim mee omgaan, en dat -wat het ook is- toch echt wel moet kunnen, mits het produkt nog niet was verwerkt in iets anders (e.d.).

AU,
Ik heb dus de grijze cellen van PS geactiveert, ben benieuwd naar de output...

 :smile: :smile:

Er ligt hier intussen een ontwerpje. :smile:
Eerst eens kijken of we dat hier intern kunnen afschieten ...

Wij zijn er tot onze verbazing vandaag ook achter gekomen dat iets dat regelmatig werd gebruikt opeens niet meer werkte.

Ik ben het eens met de stelling dat het pakket correct moet werken. Correct bijhouden van emballage hoort daarbij.
De emballage registratie bij ons rammelt behoorlijk en wij zijn momenteel dan ook in kaart aan het brengen waar het fout gaat met als uiteindelijk doel het sluitend te krijgen. Oorzaken zullen zowel in procedures als in stamgegevens en mogelijk dus ook in software liggen.

Aan de andere kant is het natuurlijk zo dat waar er gewerkt wordt er ook fouten worden gemaakt. En gemaakte fouten moeten daar waar nodig hersteld kunnen worden.
Vandaag heeft iemand wel de grondstoffen afgeboekt en per ongeluk 0 verschijningen met gereed product opgeboekt.
Nu zitten we dus met de gebakken peren. (in dit geval eigenlijk zonder peren)
Ik zou even niet weten hoe dit geval op te lossen.

Kennelijk is het drukken op de knop: "gereedmelden PO" een dergelijk ingrijpende actie dat terugdraaien daarvan vrijwel onmogelijk is.
In dat geval moet je dus zien te voorkomen dat er foute boekingen zitten in de PO voordat er op de knop wordt gedrukt.

Met andere woorden;
zorg dat er voldoende controles zijn op de integriteit van de ingevoerde gegevens voordat met de knop kan indrukken;
-0 gereed product mag nooit
-massa balans tussen input en output mag niet meer afwijken dan ..% -> waarschuwing
-er mag nooit meer massa uitkomen dan dat er in is gegaan
-grondstoffen verbruik dat ..% afwijkt van de norm -> waarschuwing
-inbouwen van een tussenstap? eerst afdrukken nacalculatie en goedkeuren alleen door bepaalde personen met juiste autorisatie ?

Maar dan nog zijn er wel gevallen denkbaar dat je wilt corrigeren ook al was men gewaarschuwd.
Een fout in het opgeboekte aantal gereed product of een fout in het aantal afgeboekte grondstoffen kan op zich leiden tot een foutieve registratie van de emballage en dat is nu juist wat er beoogd wordt te voorkomen. Sterker nog; nu klopt de emballage niet meer maar de grondstof klopt ook niet meer.
Een oplossing voor dit zeer actuele probleem is daarom toch wel gewenst.

Ook als de order nog niet de status G heeft is het hebben van een mogelijkheid tot correcties uitermate belangrijk.
Bij het verwerken van de productieorders via de scanner is aan de grondstoffenkant al de mogelijkheid gebruikte grondstoffen terug te boeken.
Bij de gereed product kant is die mogelijkheid er nog niet en ook daar zijn inmiddels de nodige fouten gemaakt.
Wij zitten daar dan ook met smart te wachten op de mogelijkheid om opboekingen ongedaan te kunnen maken.
Maar ook bij het boeken van de minuten op een order is de mogelijkheid van corrigeren er nog niet.
Hoewel we al wel de mogelijkheid hebben om met de scanner uren te registreren op een order durven we het niet aan om het toe te passen, domweg omdat de gevolgen niet te overzien zijn als men een fout maakt.

Thomas

Nou, niemand vertelt onwaarheden, en hooguit kan de problematiek hier en daar nog worden benadrukt. Ik bedoel : dat het eigenlijk wel heel erg komplex is allemaal.

Thomas mag er momenteel de meeste problemen mee hebben, omdat hij aan de ene kant het produktiepersoneel graag alles laat doen, maar aan de andere kant je het niet aan dat personeel kunt overlaten (hebben ze geen tijd voor zeg maar :smile:) om e.e.a. te korrigeren. Aldus is inderdaad één van de hier besproken opties om domweg ervoor te zorgen dat het niet fout kan gaan. Overigens hebben we hier nog niet aan gewerkt, omdat we toch eerst formeel de zaken moeten kunnen herstellen en wat domweg het gevolg is van het niet voor iedereen hetzelde zijn. Voorbeeldje voor Thomas : bij mdekraa kan er formeel best wel meer massa uitkomen dan erin ging, alhoewel het bij hem om minder dan een Kg zal gaan (??) maar toch. Neem je iemand die inkt of verf maakt (op de e.o.a. manier durven die jongens op 1 na het forum niet op geloof ik), dan wordt het al snel 10Kg, als het al niet veel meer is.

Wat bij Thomas weer bijzonder is, is dat hij discreet produkt maakt in feitelijk kontinu proces ! En daar heb je het gedonder, want als er nu een pallet fout wordt opgeboekt (hoe kriiiiijg je het voor elkaar !) worden er ook getriggerde grondstoffen afgeboekt die midden in de stapel van alle door output getriggerde afboekingen zitten (ja Marco, dat zul jij wel niet gebruiken, maar ook dat kan). Zo maar de boel opnieuw doen (kwa output) is ook niet wat, want op die pallet zit een sticker, en dat ding is al 23 keer heen en weer gescanned zijn al weer doosjes afgehaald die geen idee waarheen zijn vertrokken en blablabla.

Ik stop maar weer even, maar kan in elk geval aangeven dat we al eerder dan dit topic hieraan kontinu bezig zijn (anders was de Releasenote er ook niet, haha). En eigenlijk is dàt geboren omdat iemand z'n emballage beter wil hebben. Dan snapt Marco ook weer beter waarom we niet aan alles voetstoots mogen toegeven. Maar goed dat wist hij intussen natuurlijk al.
Overigens is jullie input in deze echt nooit voor niets. Zolang je maar niet gaat denken dat wij er alleen maar zijn om het oneens te zijn met alles ... wij hebben het grotere beeld (hoop ik in elk geval) en je ziet zelfs dat het ook intern wel eens dit soort gevechtjes oplevert. Allemaal nuttig, en zoals elders ook al gezegd, intern doen wij het al jaren zo (niet praten maar schrijven).

Tovi,

als je naar gaten in de emballage registratie zoekt:
Behalve deze hebben wij er nog 1 gevonden, en dat is (natuurlijk) als je omvormt zonder hier een formele productieorder aan te hangen.
In dat geval creeer je de "verpakking" uit lucht.
Het is dus zaak als je gaat zoeken dat je ook eens kritisch kijkt naar de [BIJ/AF] en [OMVORM] mutaties en dit ook met de mensen op de werkvloer eens goed onder de loupe neemt.

Wij krijgen hier nu echt problemen met kostprijzen en voorraden door het niet meer kunnen inzetten van de terugraai functie daar 60% van onze "bulk" opslag in hergebruik IBC's zit

Marco,

Met name naar aanleiding van jouw grieven in deze, hebben we voor anderen nu e.e.a. dusdanig op de rit dat de basis goed is om voor jou mee verder te gaan (http://ha1.heartprofit.nl/profit/index.php?topic=18531.0). Let wel, weken werk verder en de meeste tijd door ons betaald. Aan jou het verzoek om te kijken of je per de genoemde Releasenote nu iets kunt wat je aanstaat, met de opmerking dat er niets in zit wat rekening houdt met jouw situatie, maar het tòch zou kunnen voldoen (dat dus, gezien genoemde juiste basis die er nu zou moeten zijn).

Ik kan me voorstellen dat je in dit stadium niet weet waar het over gaat, en wat dat betreft het verzoek om een Upgade te doen, zodat we er daarna op kunnen verder borduren.

Mocht er voor jou nog maatwerk nodig zijn, houd dan svp in gedachten dat je nu wèl afbent van het handmatig moeten korrigeren van de Emballage.

Samenvattend,

OK, ik zal het gaan testen, en kijken of de functie voor ons met de in de releasenote genoemde voorbehouden een voor ons werkbare situatie geeft.

(trouwens ik ben net terug van vakantie, dus weer helemaal "bij", dus opgepast  :smile:)

Zover ik kan vinden werkt het niet:

1 - Ik kan nog steeds geen grondstof input corrigeren
2 - Als ik 1 verschijning heb met meerdere inhouden boekt het systeem alles terug, maar zet maar 1 output regel open. (Bv bij 20 hele drums en 1 restdrum)
3 - Aangezien kostprijs bij goedkeuren afboekingen bepaald wordt wordt de kostprijs ook niet goed aangepast.

Dus, helaas nee dit is geen oplossing voor ons probleem
Blijf dus nog steeds zitten met een groot probleem dat wij niet in staat zijn kennelijke productiefouten eenvoudig op te lossen. Hetgeen waarvoor wij in eerste instantie die terugboek functie hebben laten maken.

mbt jouw eerdere opmerking:
<quote>
Dus, Terugdraaien PO wilde niemand behalve jij, en omdat wij die Emballage even niet zien, maar jij wel en je je vervolgens van de domme houdt omdat we je al 100 keer hadden gewaarschuwd ...
</quote>

Ik kan me echt niet voorstellen dat de andere gebruikers alleen maar operators hebben die nooit wat fout afboeken. Dus die opmerking snijdt geen hout.

Juist omdat mensen fouten maken hebben we die functie in juni2001 voor Hfl. 2100 laten bijprogrammeren.
Immers alle andere modi om iets te corrigeren werken niet echt daar je dan achteraf corrigeert en dus de verkeerde kostprijzen en producthoeveelheiden in de statistiek en boekingen blijft zien.

Graag toch een meer constructieve oplossing waarmee we op een correcte wijze om kunnen gaan met de altijd aanwezige operatorfouten.