After right clicking an account and choose "open subaccounts", the balance lists the total balance of all subaccounts. However, it only sums up the numbers without regarding to the currency it is in. Therefore it is misleading if multiple currencies are involved (e.g. when there are child income accounts in HKD, and also another one in USD).
Adding myself to cc: as I regularly transact business across USD and EUR
What is the desired behavior in this case? Should the total balance be calculated in the same manner it is in the account list (i.e., using the current exchange rate , I imagine)?
My perspective (focus group of 1) is that a financial application like gnucash should never display/report knowingly incorrect or misleading data. The rightmost column (as per OP's repro steps) has the header "Balance". Standard UI in other parts of gnucash suggest this means "running balance" and personally I also assume it is this. However, the numbers under that column are both incorrect and misleading. The formula/code to add each row's values to create a sum value in the balance column is mathematically incorrect. It is additionally misleading in that there is no caution, warning, or other indicator that this value might (and is) incorrect. So what to do about the incorrect and misleading values in the right column? I think there are several options possible. 1. The Balance column could be removed when the the open-subaccounts feature is used. There might be other actions which create similar situations, so if possible identify all situations and apply the same removal. This is a hack and can lead to missed current situations and future regressions. 2. I prefer this second option. The Balance column could be removed for any ledger where there are more than one currency in the set of sub/accounts to be displayed. That test is almost O(1). I don't know yet hope it is easy to disable the balance column in the ledger UI. This prevents gnucash displaying incorrect/misleading data while keeping the feature for single currency scenarios. If instrumentation data was available, I would use the 80/20 rule...fixes the 80% of users ?having only 1 currency? and remove that balance feature for the 20% that have multiple. 3. Use code similar to that in reports to calculating the running balance based on the currency exchange rate for that row, while also having options so the user can select the desired currency for that balance, and the logic to use for the rate to select for each row (like reports). I don't like this option because it duplicates that is already done by reports. It adds complexity of at least two new options (balance currency, rate selection). And all the new testing. I don't see a win.
Created attachment 373619 [details] Register view of non-currency "Show SubAccounts" GnuCash already does Dale's option 2 for cases where any subaccounts have non-currency commodities (e.g. stocks), so it should be pretty simple to extend that to cases where the subaccounts have different currencies from the top-level parent.
Created attachment 373620 [details] Show SubAccounts with multiple currencies However, there are other problems: The Debits and credits don't display the currency symbols and at least in this test case the split amounts in the "other" currencies aren't displayed so the view is both misleading and incomplete. There's a fourth option: Disable the "Show subaccounts" menu item when the highlighted account has children with different commodities. That might be a bit heavy-handed but it's probably the safest option because the view allows editing. Creating a transaction in that view involving multiple commodities has some pretty strange results and fixing it might take considerable effort.
I was going to take a look at this, your argument for simply disabling the option when there's more than on commodity makes a lot of sense. OR Fifth option: Should we still try to display the subaccounts (with the right currencies and no running balance), but make that view un-editable because of the multiple commodities (but that could be confusing to the user, I typically hate when something is disabled and you have no idea why). I'll go ahead and implement the fourth option, but do you think we should give 5) a shot?
I think #5 is worth trying. We already open read-only if the top-level account (should/may be any of the accounts, but I haven't looked for or tested that) is a placeholder. When we open read-only we pop a message box telling the user that. The current label goes on about placeholders so we'd want a different one in this case explaining that we can't get multi-currency edits right when we can't figure out what account should set the base currency.
My preference is Option 4. Could have a warning in the bottom tray (acknowledge is difficult to see). e.g. "Disabled due to multiple currencies - consider reports instead". Then update docs for the view subaccount feature to state the exclusion/limitation. Right-click and menubar choices are often disabled with no explicit realtime reason given. Click on any account and surf the menu bar for examples. Option 5 starts feeling like (crippled) reports again. And, adding the currency symbols for #5 is something more powerfully resolved globally. This lack of currency symbols also occurs in the ledger UI for splits involving currency exchange/trading accounts autofilling the debits/credits columns like in bug 797203 and related. A type of global fix like: if a split line can know its currency (due to the currently selected account on that split line having a currency/symbol), then the split line would show a symbol.
I have implemented option #4, and I can stop here. > This lack of currency symbols also occurs in the ledger UI for splits involving > currency exchange/trading accounts autofilling the debits/credits columns like > in bug 797203 and related. A type of global fix like: if a split line can know > its currency (due to the currently selected account on that split line having a > currency/symbol), then the split line would show a symbol. I was wondering about that. I see currency symbols shown in some places, but not everywhere and I looked for the code that does that in the cell* file, but didn't find anything (to be honest, I didn't even find the part of the code that displays the amount! despite my best efforts!). Let me try to fix that globally then. I'd appreciate a hint as to where the code is that displays amounts (i.e., turns the num/den fraction to a string)
xaccSPrintAmount in libgnucash/app-utils/gnc-ui-utils.c, I think called from gsr_redraw_all_cb in gnucash/gnome/gnc-split-reg.c. Note that the presence or absence of the currency symbol is controlled by GncPrintAmountInfo::use_symbol, set by the second arg to gnc_commodity_print_info().
(In reply to John Ralls from comment #10) > xaccSPrintAmount in libgnucash/app-utils/gnc-ui-utils.c, I think called from > gsr_redraw_all_cb in gnucash/gnome/gnc-split-reg.c. Note that the presence > or absence of the currency symbol is controlled by > GncPrintAmountInfo::use_symbol, set by the second arg to > gnc_commodity_print_info(). Awesome, thanks!
I have a solution that requires adding a boolean to the SplitRegister structure, to indicate the register has mismatched commodities. Based on that flag, the currency is or isn't displayed, and the balance column is or isn't calculated and displayed. This solution fixes the problem at hand, and might fix other mismatched currency problems (I have to read more about these). I also fixed the problem visible in the 2nd screenshot where splits amounts were not displayed. I'm going to do quite a bit of testing to check that this does not break anything, but please let me know if you think this isn't the right way to do it. Jean
I think the general approach is OK but ISTM it's already at least partly implemented since some registers already show currency symbols and the case where the with-subaccounts ledger includes accounts with non-currency commodities the balance column is already suppressed. That leads me to think that the solution should be more along the lines of refactoring/generalizing existing code rather than applying another layer of implementation. BTW, there's a gotcha hiding in the register code: There's two copies of lots of it, one for the original implementation that we're still using, the other for a reimplementation of the display as a GtkTreeView called register2. When the latter was created the author thought it would be easy and just whole files and modified only the bits that needed changing, figuring that he'd just delete the originals when everything worked. Unfortunately he got tantalizingly close but never quite got all of the bugs worked out. We've been trying to keep the two sets at least in sync so that when someone takes up register2 again the bitrot won't be too overwhelming.
(In reply to John Ralls from comment #13) > I think the general approach is OK but ISTM it's already at least partly > implemented since some registers already show currency symbols and the case > where the with-subaccounts ledger includes accounts with non-currency > commodities the balance column is already suppressed. That leads me to think > that the solution should be more along the lines of refactoring/generalizing > existing code rather than applying another layer of implementation. OK, sound like a good suggestion. I'll see whether I can find that code and see if I can generalize it. J
ripngo's PR is merged, fix will be in 3.10 and 4.0.
