After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 99083 - Register representation of multi currency transactions
Register representation of multi currency transactions
Status: VERIFIED FIXED
Product: GnuCash
Classification: Other
Component: Register
git-master
Other Linux
: Normal major
: ---
Assigned To: Derek Atkins
Derek Atkins
Depends on:
Blocks:
 
 
Reported: 2002-11-20 11:52 UTC by Jan Nielsen
Modified: 2018-06-29 20:21 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jan Nielsen 2002-11-20 11:52:24 UTC
Transferring from e.g a EUR bank account to a DKK bank account using
the transfer button in the toolbar correctly opens the transfer dialog
and allows for setting up the transfer correctly. However, in the
destination account the credit amount is in the original currency (in
this case EUR) and the balance is in the destination currency (as
expected). I would expect that all amounts in the destination account
would be in its currency (DKK). An example would be

EUR account

Date 		Description	Transfer       Debit    Credit     Balance
11/13/2002 .................................................         30.00
11/13/2002 Tx DKK               Bank DK         10.00                20.00

DKK account

Date
11/13/2002 ..................................................       100.00
11/13/2002 Tx DKK               Bank EUR                  10.00     175.00
                                                           ^^^^^

I realize that a _TRANSACTION_ has a "common currency".  That means
each _SPLIT_ must be denoted in the _same_ transaction currency (there
is no way to denote multiple splits in the same currency).  However,
the presentation to the user should always be in the currency of the
account.

My concern is that when my DK bank sends me an account statement, they
are most certainly not going to tell me that I deposited 10 EUR. They
will tell me that I deposited 75 DKK.  So reconciling the danish
account is going to be a nightmare where _I_ will have to subtract the
running balances to see whether I got it right (or whether they
did). I agree that the transaction is correct, but in my opinion the
danish account should _show_ the (known) danish counter value of the
10 EUR (and only the danish counter value). This is what Quicken
does in this sort of situation.

The second argument goes as follows: I make a transfer of 10 EUR from
an EUR account to a DKK account. On the transfer dialog I specify
only an approximate counter value or exchange rate based on whatever
data I have available. The result is that I end up with 75 DKK
accredited to the DKK account.  However, when I get the real account
statement from the DKK account I realize that the bank has only
accredited me 74.25 due to whatever reason they might have. As it is
now, I cannot change the credited amount to balance the account correctly
as far as I can see.
Comment 1 Christian Stimming 2002-11-25 13:02:13 UTC
Right, this s a major problem with the handling of multi-currency
environments and has been reported earlier as #97690. People are
working on that at the moment, and updates can be expected before
1.7.4 is out.

*** This bug has been marked as a duplicate of 97690 ***
Comment 2 Derek Atkins 2002-11-30 16:23:22 UTC
If the txn is balanced and has exactly two splits, you can autocompute
the exchange rate.  Do that instead of using the pricedb.
Comment 3 Derek Atkins 2002-11-30 20:52:56 UTC
Fixed in CVS.
Comment 4 John Ralls 2018-06-29 20:21:12 UTC
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=99083. Please update any external references or bookmarks.