[grisbi-bugs] [Grisbi 0001961]: rounds JPY to EUR exchange fees value incorrectly when saving gsb file to disk
Grisbi Bug Tracker
bugtracker at grisbi.org
Mar 6 Aou 17:59:52 CEST 2019
The following issue has been SUBMITTED.
Reported By: LudovicRousseau
Issue ID: 1961
Reproducibility: have not tried
Unstable Impact: Yes
Version OS: Stretch
Date Submitted: 2019-08-06 17:59 CEST
Last Modified: 2019-08-06 17:59 CEST
Summary: rounds JPY to EUR exchange fees value incorrectly
when saving gsb file to disk
I'm using grisbi for a long time now. Recently I registered a few
currency exchange debit transactions. From JPY to EUR and each time I
save+close my gsb file, and then reopen it, I get rounded exchange fee
(EXF) in my transactions. This behaviour completely messes up my accounting.
In order to be better understood, I attached to the present mail one
file named exf_bug.gsb.
This file contains 4 transactions:
1. [OK] One Initial credit transaction of +100 EUR
2. [OK] One EUR debit transaction of : -15 EUR
3. [KO] One JPY debit transaction of : -1000 JPY (-13,33EUR + 1.67EUR
4. [OK] One last EUR debit transaction of : -10 EUR
Before I close my gsb file, everything is OK in grisbi HMI.
I.e. There remains 60,00 EUR on the bank account (expected result).
If I save+close my gsb file and reopen it, grisbi shows 59,67 EUR as
remaining on the bank account (KO).
If I give a look at the echange (rate) dialog box of the transaction n°3
(upon 4), the exchange fees have been rounded from 1.67 EUR to 2.0 EUR.
And in fact, the gsb file content shows an exf="2.0" for that transaction.
Moreover, I registered older currency exchange transactions in the past
(e.g. of kind DKK to EUR).
Those DKK to EUR transactions works OK. Exchange fees are not rounded
But the one we are talking about are the first one of kind JPY to EUR
The only difference between those three currencies is :
* EUR : 2 digits max. after floating point
* DKK : 2 digits max. after floating point
* JPY : *0* digits after floating point
Following that analysis, it appears that when floating point formats of
both currency source and destination are equal, grisbi behaves great
(OK). E.g. DKK to EUR.
Nevertheless, it appears that when floating point formats of both
currency source and destination are different, grisbi behaves oddly
(KO). E.g. JPY to EUR.
So, I'm wondering if grisbi is not rounding exchange fees value based on
the currency floating point format of the source (instead of the
floating point format of the destination -- that applies in my case (as
my exchange fees are expressed in EUR and as grisbi exchange (rate)
window also seems to express them).
As I said, I would have expected that grisbi would have rounded exchange
fees value based on the currency floating point format of the destination.
Or, in order to be more cautious, I would expect grisbi to round
exhcange fees value repecting the biggest of the two max. digits after
floating point values. E.g. when exchanging JPY(0) to EUR(2) or EUR(2)
to JPY(0), always round to the biggest (0<2) : 2 digits max. after
As I don't know all grisbi usage, I would suggest the last solution not
to break the initial behaviour.
Thanks a lot in advance for your support.
This is Debian bug #933872
Date Modified Username Field Change
2019-08-06 17:59 LudovicRousseauNew Issue
2019-08-06 17:59 LudovicRousseauFile Added: exf_bug-obfuscated.gsb
Plus d'informations sur la liste de diffusion bugsreports