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 144885 - problem with a double currency txn when adding a split
problem with a double currency txn when adding a split
Status: RESOLVED INCOMPLETE
Product: GnuCash
Classification: Other
Component: Register
2.0.x
Other Linux
: Normal normal
: ---
Assigned To: David Hampton
Chris Shoemaker
: 153321 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-06-23 18:36 UTC by Paolo Benvenuto
Modified: 2018-06-29 20:44 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Paolo Benvenuto 2004-06-23 18:36:58 UTC
gnucash --nofile

create a USD account: usd

create a DOP account: dop1

create a second DOP account: dop2

open usd register

trasfer USD 1000 to dop1 with exchange rate 45 and save the txn

go to the dop1 account and select the txn

split it

change the dop1 amount from 45000 to 40000 and give arrow down: the 40000 in the
dop1 account converts to 40000,05 (still an approximation error?), and a 4999,95
appears in the new split.

go to the new split and set the account to dop2: the new split amount desappears!!!

Hitting enter, gnucash asks to manually balance the txn!!!

Since then all is very weird in the dop1 register.

The exchange rate has changed to 45,000506 too (the approximation error of bug
#106332 is still pending???)
Comment 1 Paolo Benvenuto 2004-09-26 01:33:19 UTC
It seems so.
Comment 2 Christian Stimming 2004-10-05 07:53:24 UTC
*** Bug 153321 has been marked as a duplicate of this bug. ***
Comment 3 Christian Stimming 2006-09-04 11:45:49 UTC
Does this issue also occur in the 2.0.x versions? Development on 1.8.x has
stopped, so please upgrade to 2.0.x (most current is 2.0.1) and see whether
this problem still occurs.
Comment 4 Paolo Benvenuto 2006-09-04 18:14:43 UTC
The bug is still present, although I can't see the final change of the exchange rate.
Comment 5 Paolo Benvenuto 2006-09-04 18:16:21 UTC
Bug still present in 2.0.1
Comment 6 Paolo Benvenuto 2007-09-23 17:38:02 UTC
In 2.2.1 the bug is something different:

when in dop1 register I change the dop1 value, the new split is created with a exchange rate of 1, while it should be the same as for dop1, i.e. 45.

Another issued is still pending: notwidthstanding the inputted exchange rate of 45, this value isn't respected, i.e. receive an aproximation when the 3rd split is created.
Comment 7 Charles Day 2008-08-12 22:40:23 UTC
I just tested with up-to-date source code (r17463) and this all seems to work correctly now.

The figure of 40000.05 is correct because, using the split's existing exchange rate of 45, it is not possible to get an even number of USD cents. This is because DOP 40000 / 45 = USD 888.888888888 (forever) which is not decimal. Rounding to the nearest penny gives USD 888.89 * 45 = DOP 40000.05.

On the 4999.95 line, I didn't have any problems. I just chose an account and pressed Enter. The exchange rate dialog came up and the exchange rate was exactly 1/45. I clicked OK, then pressed Enter again (maybe twice). The transaction is completed and it looks OK to me.

If you want to have exactly DOP 40000 in that split, I think you can type "40000" then click "Actions->Edit Exchange Rate" and round off the USD amount.
Comment 8 Charles Day 2009-03-10 18:31:19 UTC
Can you reproduce this problem in 2.2.7 or higher?
Comment 9 Paolo Benvenuto 2009-03-10 19:17:15 UTC
> go to the new split and set the account to dop2: the new split amount
> desappears!!!

That's doesn't happen any more.

The approximation error keeps on.

Weird things keeps happening in the accounts after making all the stuff

Comment 10 Charles Day 2009-03-10 19:46:10 UTC
Do you still see the approximation error, given the explanation in comment 7? I didn't see any. Thanks for the quick response.
Comment 11 Paolo Benvenuto 2009-03-10 19:49:02 UTC
the approximation error: Derek told me once that exchange rates are treated as fractions: 1/45 remains 1/45, not 0,022222222 (forever). Is it still true that?
Comment 12 Charles Day 2009-03-10 22:40:25 UTC
It depends what you enter. You can:
1. Fill in an "exchange rate". You can enter a decimal like 0.0234 or a fraction like 6/7. The "to amount" will be computed and rounded off according to the "smallest fraction" setting.
2. Fill in an exact "to amount".

Now that there is a "from amount" and "to amount", the two are divided and the resulting exchange rate is stored in the price editor. It will be stored as a fraction only if the division result is non-decimal.

If you later edit the transaction and want to change the exchange rate, you will see the same thing. The "from amount" and "to amount" are divided and the exchange rate is displayed as a fraction only if the division result is non-decimal.

Is this not what you expect?
Comment 13 John Ralls 2018-06-29 20:44:24 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=144885. Please update any external references or bookmarks.