GNOME Bugzilla – Bug 547335
In new TXNs the price now is always 0 (Continuation of Bug 432764)
Last modified: 2018-06-29 22:08:31 UTC
Please describe the problem: While the price editor now gives exact results, it has now become impossible, to enter new transactions to foreign currencies with exchange rates <> 0. Steps to reproduce: See http://bugzilla.gnome.org/show_bug.cgi?id=432764#c5 ff. Actual results: account page imbalanced, 1 account showing a 0 valued transaction, price editor shows an entry with price 0 Expected results: a balanced account page, both accounts showing the same equivalent in the transaction, an entry <> 0 in the price editor Does this happen every time? Until now, I found no way to enter new transactions to foreign currencies. Other information: I assume a small typo somewhere around http://svn.gnucash.org/trac/changeset/17441.
Interesting. I can reproduce this. I wonder if it is the same as, or closely related to, bug 139651 and bug 433081 (which is also one of yours.) The keystrokes are also important. As I think you indicated somewhere, tabbing through all fields causes the exchange dialog to show twice, whereas hitting enter shows only once. But that might be a separate bug that doesn't affect the math. I'll start investigating...
OK, the problem is related to the changes I made in r17451 for bug 543780. I'll see how I can adjust this to fix both problems. I think bug 406127 is related to the same part of the code, so I'll see if I can resolve that too.
Fix committed as r17462. Requesting backport for 2.2.
Thanks for finding this one, Frank! I'm afraid this doesn't fix bug 406127. But bug 139651 seems to be fixed again. Can you verify that your bug 433081 is fixed?
My first impressions of r17462: Entering new txn works really fine. If there is an entry in price db, I get this as suggestion. Nice! 0. In some trials on editing the broken txn from before this patch, I got some strange results, where I couldn't really determine the conditions to reproduce them. But I think, this is not really important. There was no official release with that behavior and in case of doubt, the user can delete and add the txn again. 1. More important is, that the currency shown in G/L is depending from where you started the transaction. Starting from the foreign account leads to an entry in foreign currency. As G/L shows no currency, this is a little misleading. I assume, and at least the german GAAP are so, that G/L should always show the entries in domestic currency. 2. Another small issue: in the cash_EUR account in the txns to cash_ID the balance entry shows no cents, while cash_ID shows them. Should be the other way: EUR has cents, IDR not.
Re comment 5: Once r17462 is backported, I think we can close this bug. For number 1, I think this is a completely separate problem with the G/L, so please create another bug report for it. I think someone else will need to fix this. There are a few other problems with the G/L as well. For number 2, I see the problem if I enter the transfer from the EUR register but not if I enter the transfer in the IDR register. Interesting. I'm not sure this has anything to do with the Price Editor or exchange rate dialog though. If you think it is not a duplicate of bug 406127, please open a separate bug for this. Thanks.
FYI: When searching for number 1, I found bug 106873 (Transaction currency in general ledger). When doing some trials on that, I decided to open bug 548678 (base currency between account hierarchy view and general ledger [can] differ). We have at least the following, possible different currencies: locale, derived from LANG, default, set in preferences->accounts report, set in preferences->reports account, as edited. We have at least 2 different behaviors: general ledger uses default currency, account uses the first selected account currency, (business stuff untested, in theory there is additional a customer/vendor/employee currency).
I think, bug 534618 describes also the symptom of Comment 5 1. Sorry, I lost somewhat the overview, because I ran in different issues.
Re comment 8: Please forget this comment, I didn't read right.
(In reply to comment #6) > Once r17462 is backported, I think we can close this bug. Done in r17519. Thanks a lot.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=547335. Please update any external references or bookmarks.