GNOME Bugzilla – Bug 759859
Reconcilation does not convert transactions' currency to the main one making reconcilation impossible.
Last modified: 2018-06-29 23:45:16 UTC
What happens: If an account has subaccounts with different currency then the reconcilation view does not convert the currency of unreconciled transactions. This influences the calculation of balance difference which is then unlikely to be zero, which blocks the reconcile. What should happen: Reconcilation view should convert transaction's currency to a common one. Steps to reproduce. 1. Create account A with currency USD and subaccounts A0, A1 with currencies respectively: USB, CHF. 2. Add a transaction to A0 for 1.0 USD and a transaction to A1 for 1.0CHF. 3. Try to reconcile account A. You will see that reconciling A1's transaction adds exactly 1.0 USD to reconciled balance instead of 1.0 CHF (or equivalent converted ammunt).
That's debatable because you'd have to have the exact prices the institution used on the statement either already loaded in the price editor for the opening and closing dates of the statement or entries that collected those prices as part of the reconciliation data dialog. Most people reconcile security or forex accounts separately, each in their native commodity. After all, your CHF forex account contains CHF, not USD. It's value in USD varies constantly, so reconciling in USD is not particularly useful. Does your forex broker really issue statements showing only the USD values of your forex accounts?
John, thanks for the comment. Do you agree that, currently, the reconciliation of an account that contains subaccounts with unreconciled transactions with different currencies is broken? I think that yes, because it is impossible to do due to the fact that reconcile view uses currency conversion in calculating reconciled balance, but not using it for ending balance. To motivate a need for the fix, here's my use-case: I have multiple bank accounts with different currencies. As I make some transactions through the month I like to reconcile it all quickly. Having to click on each and every account to reconcile is bothersome - instead I would just click on the main Assets account, check, and reconcile. So the choice here is to decide whether it is really a bug and then how to fix it? Perhaps you may not want any fix, then, perhaps, Gnucash should complain to the user that reconciling accounts with different currencies is impossible, instead of leaving the user clueless with this weird behavior. Let me know what you think.
(In reply to grzegorzmilka from comment #2) > John, thanks for the comment. > > Do you agree that, currently, the reconciliation of an account that contains > subaccounts with unreconciled transactions with different currencies is > broken? > I think that yes, because it is impossible to do due to the fact that > reconcile view uses currency conversion in calculating reconciled balance, > but not using it for ending balance. No, it doesn't. The reconciled balance is a number that you enter in the Reconcile Data dialog. > > To motivate a need for the fix, here's my use-case: I have multiple bank > accounts with different currencies. As I make some transactions through the > month I like to reconcile it all quickly. Having to click on each and every > account to reconcile is bothersome - instead I would just click on the main > Assets account, check, and reconcile. If you have multiple bank accounts then you get multiple statements. You shouldn't reconcile them together; otherwise you're not reconciling the statements, you're reconciling the spreadsheet or whatever you use to combine the statements and convert them all to a single currency. > > So the choice here is to decide whether it is really a bug and then how to > fix it? Perhaps you may not want any fix, then, perhaps, Gnucash should > complain to the user that reconciling accounts with different currencies is > impossible, instead of leaving the user clueless with this weird behavior. > > Let me know what you think. I say it's not a bug. I have no problem with raising an error dialog that the sub accounts are in different commodities raised when the user clicks the "Include subaccounts" checkbox, and of course the checkbox should refuse to be enabled.
Created attachment 317885 [details] [review] Patch that disables subaccount reconciliation if commodities differ
Created attachment 317886 [details] [review] Patch that disables subaccount reconciliation if commodities differ v2
Created attachment 317887 [details] [review] Patch that disables subaccount reconciliation if commodities differ
I have provided a patch that greys out the "Include subaccounts" button for accounts with different commodities. A different options of implementing this would be to: 1. The method in the patch. 2. Grey out the button if there are unreconciled trasanctions for different commodities. 3. Show up a dialog that Including subaccounts is impossible for those accounts. Do you have any preference for which one would like to see? The 3. option would require internationalization, is that work-expensive in gnucash?
I actually like the idea of simply disabling the checkbox. A tooltip, which is displayed when the mouse hovers over the control, can explain that it's a requirement that all subaccounts have the same commodity. A similar note in the help manual and maybe the Tutorial and Concepts Guide is also needed. I can take care of that part. One new string isn't going to exercise our translators much.
I've committed your patch and it will go into the next software release. Once that release is available, you may want to check for a software upgrade provided by your Linux distribution. Thanks!
I'd like to re-open the debate on this issue, with the intention of possibly having it reclassified as a bug (and hopefully fixed.) First, my use case: My credit card is denominated in the (local) currency, and I use it in a country with a different (foreign) currency. When my bank sends me the statement for the transaction, they convert my purchase from the foreign to local currency, and also add a (local) surchage (as a percantage of the local purchase price). To give some concrete numbers: Say my credit card is denominated in CHF. I spend GBP 50.26 having dinner in a pub in England. Assume that, with the exchange rate at the time, that comes to CHF 73.29. My bank adds a CHF 4.50 surchage, meaning my total credit card bill for that month comes to CHF 77.79. Here's how I've tried to structure this in GnuCash (v 2.6.1, rev 76cba80+ on 2014-02-19, running on Ubuntu 14.04). The Expenses are reflected correctly; the Liabilities aren't. For the lines I've marked with <-!!!!, I expect to see CHF -77.79. Top level +--Expenses CHF 77.79 +--Bank Charges CHF 4.50 +--Restaurants CHF 73.29 +--Liabilities CHF -54.76 <-!!!! +--Credit card CHF -54.76 <-!!!! +--CHF CHF - 4.50 +--GBP GBP -50.26 I've isolated this example in the attached gnucash file. What is relevant is that I made this example by deleting all other accounts from one of my fully-fledged account files. If I create a completely new, clean GnuCash file, and just add these two transactions, the currency conversion/reconciliation seems to work. Could someone have a look at my attachment and asses, please? If I've set up the accounts or the transaction incorrectly (messed up debit/credit sides, for example), that'd be useful to know. But I think there's some old gunk, which should have been deleted, clogging up the file and confusing GnuCash...
Created attachment 328700 [details] Example gnucash file showing incorrect currency reconciliation for higher-level accounts
Your problem has *absolutely nothing* to do with this bug. Not a thing. We have a mailing list for support questions, gnucash-user@gnucash.org. Please use it. As for your problem, your price database shows GBP->CHF exchange rates of 1.00. If you remove those then the balances in the liabilities account match the Expenses. Don't reply here, use the mailing list.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=759859. Please update any external references or bookmarks.