Heart-Profit ERP
November 27, 2024, 10:33:29 pm *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
   Home   Help Login Register  
Pages: [1]
  Print  
Author Topic: Afrondingsverschil 1 cent bij G.O. $11285,- met koers 0,7930  (Read 787 times)
0 Members and 0 Guests are viewing this topic.
Heart Informatisering B.V.
Partner
******
Offline Offline

Posts: 27476


View Profile WWW
« on: January 21, 2015, 12:37:25 pm »

Per heden is gekonstateerd dat bij het journaliseren in USD, en een Database Valuta NLG, er afrondingsverschillen kunnen ontstaan in de journaalpost.

Toen in 1999 de euro er aan stond te komen stonden we voor twee keuzes: of overal in de database NLG naar EUR konverteren, of gewoon NLG als onderliggende databasevaluta behouden, en opgevraagde data ter plekke omrekenen. Er is voor het laatste gekozen, met twee belangrijke redenen:

a. een dergelijke konversie zou kwa uitvoering meerdere dagen in beslag kunnen nemen, en het gros van de klanten zouden hun systeem niet meerdere dagen plat kunnen leggen voor e.d. konversie

b. de tijd die nodig zou zijn om een dergelijke konversie te ontwikkelen, rekening ermee houdend dat per numeriek veld zou moeten worden uitgezocht in welke Valutakode ze 'gebruikt' wordt; zie bijv. ook een veld als Kredietlimiet die in de valuta van de Debiteur staat, en waarbij dit bij een NLG debiteur zou moeten worden omgerekend naar EUR, maar bij een USD debiteur niet gekonverteerd mag worden.

Journaliseren doen we in 2 decimalen.

Om EUR bedragen (in 2 decimalen, rekeninghoudend met een vaste omrekenkoers van 2,20371) in NLG in de database te kunnen registreren, zouden we 5 decimalen extra nodig hebben.

Bij het journaliseren in Vreemde Valuta is nu gekonstateerd dat een bedrag van USD 11.285,- bij een koers van 0,7930 in de database terecht kon komen als 11285 x koers x 2,20371. Hierdoor werd er feitelijk (in EUR) gejournaliseerd in meer dan 2 decimalen, waardoor er 'verschillen' konden ontstaan.

Per heden is een extra afronding op 2 decimalen ingebouwd, waarbij ieder bedrag die daadwerkelijk geboekt wordt, in 2 decimalen behoort te staan. Dat er meer decimalen in de database terecht komen mag hooguit het gevolg zijn van de vermenigvuldiging met 2,20371.

NB: Overigens hebben we dan ook nog eens te maken met afrondings problemen van VFP zelf, die als we 11285 x 0,7930 doen en dat afronden op 2 decimalen, terugkomt met het getal 8949,00 waar dit 8949,01 zou moeten zijn. Deze afrondingsbug zal uiteindelijk de echte oorzaak zijn van de vele centen boekingen, die de ene keer wel, en de andere keer niet optreden.

FunktieOmschrijvingDtm.Vl.WyzDtm.L.Wyz
ADBOBO      Omschrijving (nog) niet bekend    27-10-2014    21-01-2015
ADBOTV1     Journaliseren    07-11-2014    22-01-2015
ADBOTV6     Omschrijving (nog) niet bekend    28-10-2014    21-01-2015
ADBOTVW1    Omschrijving (nog) niet bekend    13-01-2015    22-01-2015
ADBOTVW2    Journalisering    19-12-2014    22-01-2015
ADBOTVW3    Omschrijving (nog) niet bekend    19-12-2014    22-01-2015
ADEUR       Omschrijving (nog) niet bekend    16-05-2008    22-01-2015
ADROUND     Omschrijving (nog) niet bekend      -  -        22-01-2015
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1 RC2 | SMF © 2001-2005, Lewis Media Valid XHTML 1.0! Valid CSS!
Page created in 0.058 seconds with 19 queries.