|
Title: Autom. journalisering Afrondingsverschil gebeurt onder Userid Doorbk. Batchboekg Post by: Heart Informatisering B.V. on October 27, 2014, 02:41:26 pm Zodra we met Vreemde Valuta werken, kunnen we te maken krijgen met kleine afrondingsverschillen.
Neem maar eens als voorbeeld dat we een 5 blikken inkopen met een inhoud van ieder 18,925 L bij een prijs van USD 2,68 / L. De totale waarde van deze inkoop zou zijn 5 x 18,925 x 2,68 = USD 253,5950. In het Grootboek journaliseren we echter niet in meer dan 2 decimalen, en dus zal dit in het Grootboek moeten leiden tot een te ontvangen faktuur van USD 253,60. Uitgaande van een koers van 0,7880 zal dit leiden tot een tegenwaarde van EUR 199,84. De voorraad registeren we wél in meer dan twee decimalen, nl. in 4 decimalen. Dit heeft ermee te maken dat we ook klanten hebben die een miljoen items tegelijk inkopen, en een afronding van een halve cent niet nauwkeurig genoeg is bij dat soort aantallen. 1 Voorraaditem van 18,925 L zal (x $2,68) een waarde hebben van USD 50,7190 x 0,7880 = EUR 39,966572. Dat afgerond op 4 decimalen wordt EUR 39,9666 per V-item. Omdat we 5 blikken hebben ingekocht zal er logistiek 5 x 39,9666 ofwel EUR 199,83 op voorraad worden gelegd. T.o.v. de tegenwaarde van het USD bedrag hebben we nu 1 cent verschil. Helaas zullen we niet ontkomen aan dergelijke verschillen, anders dan dat we bijv. zelf er voor zorgen dat we produkten verhandelen met prijzen per Verschijningsvorm, en daarbij alleen netjes journaliseerbare bedragen hanteren. Maar, om bovenstaande gaat de Releasenote nog niet eens... Waar het wel om gaat is dat die ene cent weliswaar automatisch naar een verschillenrekening werd geboekt, doch dit gebeurde met als Userid de Identifikatie van de Gebruiker die Batchboekingen doorboekte, en niet de Identifikatie van de gebruiker die de Batchboeking aanmaakte. Resultaat was dat 1 mutatie onder 2 Gebruikers-id's in het Grootboek terecht kon komen, want voor andere funktionaliteit weer een teken was dat dit om twee gescheiden boekingen ging, van twee verschillende gebruikers, die puur toevallig op dezelfde tijd (tot op de 100e seconde nauwkeurig) waren uitgevoerd. Het terugdraaien van een transaktie zorgde er dan bijv. ook voor dat alleen de oorspronkelijke mutatie gekorrigeerd werd, en niet boeking van het auomatische afrondingsverschil, waardoor er een situatie kon ontstaan dat debet en credit niet aan elkaar gelijk waren.
|