Zodra we ergens een Entiteit in het systeem toevoegen, zal e.d. scherm bestaan uit meerdere fysieke schermdelen. Eerst een schermdeel waarin om de toe te voegen Sleutelvelden wordt gevraagd, en in de volgende schermdelen de attributen. Zodra de Sleutelvelden bekend zijn, worden deze direkt aan de database toegevoegd, ter voorkoming dat een andere Gebruiker dezelfde Sleutelgegevens kan gaan toevoegen.
Stel dat we een Arikel gaan toevoegen, dan zal ook daar de sleutel (bedrijf + artikelnummer) direkt aan de database worden toegevoegd. Maken we vanuit Toevoegen Artikelen een zijstap naar een andere Funktie, bijv. Raadplegen Financiële Groepen, dan is "Toevoegen Artikelen" niet formeel meer aktief. De zojuist toegevoegde sleutel wordt dan direkt weer verwijderd, omdat het immers niet zeker is dat we na de aanroep van de zijstap weer terugkeren in "Toevoegen Artikelen", en dan alsnog de mogelijkheid krijgen om een eventueel onterecht toegevoegde sleutel te verwijderen.
Zo zou bijv. Raadplegen Financiële Groepen met
F10__ kunnen worden verlaten, in welk geval we terugkeren naar het Hoofdmenu, zonder dat LOARTV nog een kans zou krijgen de sleutel te verwijderen.
De Faktuurkontrole wijkt af van normale Toevoegfunkties. Immers, waar een normale Toevoegfunktie feitelijk uit één Funktie bestaat, wordt de Faktuurkontrole uit meerdere funkties opgebouwd, en pas als de laatste stap doorlopen is, is de Faktuur geboekt.
Als eerste boeken we een Ingekomen Faktuur gebruik makend van ADFITV, deze roept vervolgens een Raadpleegfunktie aan, van waaruit het ingevulde Faktuurbedrag kan worden afgeletterd op Inkooporders of Ontvangsten.
Vanwege de zijstapjes die gemaakt werden, waardoor ADFITV niet meer aktief werd, werd de in ADFITV vastgelegde sleutel weer verwijderd. Bij het Goedkeuren van de Faktuurkontrole werd de Faktuur dan daadwerkelijk in het systeem opgenomen.
Echter...
Gedurende het moment dat de Faktuurkontrole aktief was, en het Faktuurbedrag werd afgeletterd op de Inkooporders, bestond de situatie dat er formeel nog geen Faktuur geboekt was. Vervolgens kon op een ander werkstation de betreffende Faktuur alsnog een keer worden geboekt!
Hoewel deze situatie ook bij U kan zijn opgetreden, is de kans erg klein. Immers, om een Ingekomen Faktuur te boeken zal de Faktuur benodigd zijn, en dat document kan maar bij één iemand tegelijk liggen. Daarnaast worden documenten veelal van een Boekstuknumer voorzien, en zou aan de hand van de aanwezigheid van het Boekstuknummer gekonstateerd kunnen worden dat het document al geboekt is.
Toch blijkt e.e.a. nu in praktijk een keer verkeerd te zijn gegaan, en wel in de toevallige situatie dat één persoon op twee werkstations tegelijkertijd aan het werk was, schijnbaar even is afgeleid, en dezelfde Faktuur 2x heeft ingeboekt.
Een lastige bijwerking van het op deze manier kreëren van een dubbele sleutel, is dat het 2e record in principe nooit gewijzigd kan worden.
De Betalingsrun konstateerde dan ook dat er een openstaande Faktuur aanwezig was, en nam deze op in het betalingsvoorstel. Zodra de betaling echter verricht was, werd de Faktuur van de betreffende Crediteur gelokaliseerd (doch deze vond altijd het 1e voorkomen), en werd geregistreerd dat de Faktuur betaald was. Omdat bij een zoek opdracht altijd het eerste voorkomen gevonden wordt, kreeg steeds de 1e Faktuur een status 'betaald' en bleef de 2e gewoon open staan. Gevolg was, dat deze gewoon weer in een volgende Betalingsrun werd opgenomen, en in een volgende...
Met ingang van deze Releasenote blijven de sleutelgegevens van de Faktuur die wordt toegevoegd aanwezig, tot bijv. het moment dat de Faktuurkontrole wordt afgebroken. Op deze manier wordt voorkomen dat er op 2 PC's tegelijk een Faktuurkontrole geboekt wordt voor dezelfde Faktuur.
| Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz |
| ADFITV | Boeken Ingekomen Fakturen | 14-10-2009 | 29-12-2009 |
| LORIGK2 | Afsluiten Faktuur | 13-10-2009 | 30-12-2009 |
