Created attachment 373059 [details] The book file to reproduce the problem On the Accounts page GnuCash shows the 0,01 USD in the Total column for Testtest account, however, the Total (EUR) column shows the incorrect value of 0,28 EUR for the same account. The correct value should be 0,01 EUR, and this value is actually shown in the Total (EUR) column for the Imbalance-USD account. There are no conversion 1:28 conversion rates recorded in the currency prices database for the USD/EUR pair. Strangely enough, the Total (EUR) amount is affected by the latest price of the only security in the book: when it is removed, the Total (EUR) value for the Testtest account turns into zero. Also, changing the transaction sum in the Testtest account from 0,01 USD to any other value (like 0,02 USD or 1 USD) makes the problem go away: the ratio between the values in Total and Total (EUR) start to make sense again. The gnucash book file to reproduce the problem is attached. I am running GnuCash on Debian Testing: gnucash: Installed: 1:3.3-2+b1 Candidate: 1:3.3-2+b1 Version table: *** 1:3.3-2+b1 500 500 http://httpredir.debian.org/debian unstable/main amd64 Packages 100 /var/lib/dpkg/status 1:2.6.15-1 500 500 http://httpredir.debian.org/debian stable/main amd64 Packages
Created attachment 373060 [details] Screenshot demonstrating the problem
I'm not able to make a "Total (EUR)" column appear with the default currency set to EUR. I note that this isn't a well-formed book as the Root account has no currency and there are several transactions with a single split and 0 value and amount in the Imbalance-USD account. That's probably because you deleted some accounts without specifying that their transactions should be deleted. I do see, however, the bogus €0.28 Profit in the summary bar, so that gives me something to work with. Changing the amount of the sole transaction to $0.02 changes the profit to €0.02. Either changing the date on the sole USD->EUR price to after the EL4B->EUR price or changing the EL4B price to before the USD one removes the bogus profit. That makes some sense because the Accounts page and the summary bar always work from the most recent price available.
Edit/Preferences/Report/Default Report Currency/Choose: EUR should make the "Total (EUR)" column available for you.
So it does, thanks. I don't agree that it should, report preferences should affect only reports, not the GUI.
As I sort-of expected, the problem was that .9 * -1 banker-rounds to 0, so the direct conversion to Euro is rejected and the indirect one is attempted; the indirect conversion then took any pair of prices that happened to share a commodity (any commodity!) without constraining the selection to requiring that the other two commodities in the pair matched the desired from and to ones. I've fixed both problems for GnuCash 3.4.
Thank you for the fix, John! However, after an upgrade to GnuCash 3.4 I see -0.01 EUR in Total (EUR) column for the problematic account. I guess, the correct value should be 0.01 EUR (without minus). You can use the already attached bugreport2.gnucash to reproduce the problem. I guess, the problem is not fixed completely, so, I reopen the bug.
Yup, I see it. Closer than €0.28, but still not right.
Created attachment 373263 [details] Fix round to handle numerators equal to 0 The problem was that the round function rounded up whenever the numerator was 0, and the remainder was greater than half the numerator, even when the remainder was negative.
Why did you close this bug ? Maybe I missed something but I don't remember seeing your patch committed in our source code repository.
I'm sorry, newbie's mistake.
Created attachment 373264 [details] bugfix without tabs The same patch but only with spaces instead of tabs.
Unfortunately, this fixes the issue but causes incorrect conversion in other places. I thought the integer divisions were C truncating divisions, however the divisions between GncInts follow the flooring division rule(remainder always positive), except when the result is between -1 and 0, in that case GncNumeric::prepare_conversion returns a negative remainder, so I would bet that the source of this bug is in the GncInt128::div function or somewhere related.
Created attachment 373266 [details] Fix division to return a negative remainder when dividend is negative I believe I nailed it, now. The problem was that the division function was not flaging the remainder as a negative when the dividend was a negative, I also corrected the tests that were expecting this wrong behaviour. And the other bug was in the rounding functions that did not round correctly when the quotient was 0 but the remainder was negative.
Link to pull request: https://github.com/Gnucash/gnucash/pull/502
David's pull request is merged and will be in GnuCash 3.6.
