GNOME Bugzilla – Bug 433081
It seems to me, multi currency is becoming crazy
Last modified: 2018-06-29 21:33:51 UTC
Please describe the problem: pls. have a look in the later attached file. there seems nearly nothing right. 1. the accounts are not balanced 2. the transactions from cash_IN to goods_from_india are not shown in the general ledger 3. the transactions show something else than I entered in general ledger Steps to reproduce: 1. open a new file and create accounts asset->cash_IN and expense->goods_from_india both in foreign currency INR the following is done in general ledger: 2. open with cash 1000 in default currency; then exchange from cash to cash_IN assuming rate of 60 3. try to buy a few indian goods with indian money: new transaction; 1. pos: expense:goods_fromIndia: 100 / - in the exchange rate again assume 60 2. pos: expense:goods_fromIndia: 200 / - 3. pos: assets:cash_IN: -/ 300 finish Actual results: Expected results: instead of having goods_from_india 300 / - I get a Orphan-USD of 200 Does this happen every time? as they say in India "all same, same, but different" I got it in svn r15995 and 2.0.5 Other information: It seems related to bug #387539 and possible #432764, #406127
Created attachment 86941 [details] crazy by 2 currencies in the first xchange rate dialog I entered the 60, in the later i thought, I could confirm by hitting <enter>
Created attachment 86942 [details] same actions, but different result In this case I explicitly confirmed the exchange rate by clicking OK and got a better result - only 100 imbalanced.
Can you still reproduce this in 2.2.6? I see the strange results in the second attachment, but when I re-enter the transaction in 2.2.6 it all looks good.
OK, I am trying to remember the aspects of this case and use svn r17462M. A. Opening the uploaded files 1. Attachment 1 [details] a) after opening the file looks as described in Comment #1 .0 The price editor shows beautiful and correct 1/60 .2 G/L shows correctly all entries in domestic currency, while INR accounts show their equivalent .3 only in INR accounts the INR->INR txn "Buying in India" split 1 goods_from_india shows no value, while it should be 100 domestic = 6000 INR, resulting in .1 account page imbalanced. b) while refreshing that txn from G/L .1 replacing Orphan-USD by goods_from_india works, but IDR accounts show USD ammounts after that edit. This is the invers effect of Bug 547335 #5 1., while effect 2. we cannot see her as both currencies have 2 decimals. .2 Funny: moving the split w/o value from goods_from_india to some domestic account and back toggles the value between 6000 and empty. Having a quick look in the data file shows: <split:value>10000/100</split:value> <split:quantity>0/100</split:quantity> 2. Attachment 2 [details] The only difference, which I see: this has no orphan-USD, both splits are correctly assigned to goods_from_india. Now I can explain one part of my confusion, when I filed attachment 1 [details]: If you first enter the credit split, and use <enter>, GC inserts a debit to orphan-<domestic_currency>. May be, you doesn't see that or you select another account, but under some circumstances, I assume again depending on the used key, the selection switchs back to orphan... Because of my trouble with currencies I didn't see that and the confusion became complete. Should I file an enhancement request "Pop up a warning, if there are imbalanced or orphan splits"? B. recreating the files should result in Bug 547335 #5. Because I didn't find open currency specific issues, which are not covered in Bug 547335 #5, I tend, to depend this on that. But if you prefer, I can open a new bug for Bug 547335 #5.
I think there are not the same issues here as in bug 547335 #5 because the currencies here are USD and INR, and both have the same "smallest fraction" (1/100).
Re comment 4: I'm not really worried about (A) since the files were created by an old version. For (B), at least the latest code should not create bad data when the "smallest fraction" is the same. For differing smallest fractions we have bug 406127 and bug 408444. So I think we can close this bug when r17452 is backported. If you want to add an enhancement request for a pop-up warning in the register, sure, go ahead. I'm not sure how quickly that would get done though. Since it involves changing account register code, it probably wouldn't be done by me.
Re comment 5: because we have here the same smallest fraction, one half of bug 547335 is invisible here, while the other is visible. Re comment 6: ACK. The RFE is now filed as bug 548357.
Is there some remaining part of this bug that is not already covered by bug 406127, bug 408444, bug 547335, bug 548357, or bug 548678? If not, then I see no reason to keep this bug open once r17452 is backported.
Everything, what I see, is covered by the other bugs. So you can close it after the backport. Thanks.
OK, removing the dependency on bug 547335 so we can do that. Thanks.
(In reply to comment #8) > If not, then I see no reason to keep this bug open once r17452 is backported. I am not sure I know what commit you actually mean... It is definitely not r17452 :)
The fix for the underlying bug 547335 was r17462.
Thanks Frank! You knew that already, r17462 has been applied to branches/2.2 as part of r17519 :-)
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=433081. Please update any external references or bookmarks.