GNOME Bugzilla – Bug 726674
Budget Report always shows some inconsistent signs
Last modified: 2018-06-29 23:28:32 UTC
After creating a budget (and verifying through the Budget Balance Sheet and Budget Income Statement that everything looks normal) the Budget Report always shows some inconsistent signs in certain categories: If you select Preferences -> Accounts -> Reverse Balanced Accounts -> None, then budgeted income amounts show positive, and actual income amounts show negative, and two lines which are the same show a large difference. Assets, liabilities, and expenses have consistent signs between budget and actual. If you select Preferences -> Accounts -> Reverse Balanced Accounts -> Credit accounts, then budgeted liability decreases show positive, and actual liability decreases show negative, and again you get a large difference where there is none. Assets, income and expenses have consistent signs between budget and actual. If you select Preferences -> Accounts -> Reverse Balanced Accounts -> Income & expense, then budgeted expenses show positive, and actual expenses show negative, and again you get a large difference when there is none. Assets, liabilities, and income have consistent signs between budget and actual. There appears to be no way to get the report to show all amounts with consistent signs at one time. Further, it seems as if the budget report ought to always compensate and work correctly regardless of which option you choose for the "Reverse Balanced Accounts" option. If I try to change the signs of the numbers in the budget to compensate, then the Budget Balance Sheet and Budget Income Statement clearly give wrong results.
Hi Paul, I just tried to reproduce your scenario but I did not succeed. I tried with example transactions - from income to asset - from liability to asset - budget for all accounts with positive numbers - preferences set to "reverse credit" In the budget report all transaction appear with positive numbers, just as the budget does. Could you attach an example gnucash file so it is easier to check what goes wrong?
Created attachment 272808 [details] Example gnucash file containing data showing bug.
Hi Carsten - I've attached an example file. Running the "Income Statement" report for calendar year 2014 shows revenues of $1,000, expenses of $750, net income of $250. Running the "Budget Income Statement" also shows revenues of $1,000, expenses of $750, and net income of $250, so we're bang on budget. Running the actual and budget balance sheets shows a similar situation, with cash of $1,000, and credit card liabilities of $750, total equity of $250. So running the actual and budgeted income statement and balance sheet indicates that the balances are exactly what I'd expect to see. But when I run the "Budget Report", and add a difference column, then: - Set to "Income & expense" I get a $1,500 difference for expenses (i.e. $750 x 2) - Set to "Credit accounts" I get a $1,500 difference for liabilities; and - Set to "None" I get a $2,000 difference for income (i.e. $1,000 x 2).
I should also note that I can make the "Budget Report" appear to work by changing the sign of the liabilities change in the budget from -750 to 750, and setting preferences to "Credit accounts" (and other preferences setting results in differences). However, if I do this, the budget balance sheet goes clearly wrong, and gives me total assets of -$500, and total liabilities of -$750, and equity of $250, instead of assets of $1,000, liabilities of $750, and equity of $250 as it should be.
Thanks, Paul. Good example and good explanation. Now I get your point and can confirm this bug. To me it appears that the sign reverse is not consistently implemented, and my impression is that it does not only affect the Budget Report, but basically all of the budget reports. Consequently, I see this as a major bug. I'll go and try to investigate for a solution - will keep you posted via this bug. I'd be happy if anyone who has permission can put this bug into status NEW.
Created attachment 273023 [details] [review] patch to be applied on top of GnuCash 2.6.2 Hi Paul, here comes a solution proposal. It is based on supporting the sign reverse preference when setting the budget value. If e.g. you set a budget positive value for an income account while have the sign reverse switched on, the value will be stored as negative value. Once the value is accessed it will be sign-reversed while the switch is still on, i.e. the value will be read as positive value again. After switching off the sign reverse preference, the value will be read as stored, i.e. as negative value. With that it goes in line with the handling of transaction values for income accounts. Nice effect from the current implementation: The budget view updates automatically when switching the preference, so no user interaction required in this case. Good! Consequence for the user: If he has the sign reverse preference switched off, he should enter negative values in the budget view for e.g. income accounts. The current patch proposal is not complete. I am not sure about the lower part in the budget view, don't really see what this is good for. Also, the reports are not completely safe yet: The Budget Report, Budget Income Statement, Budget Profit&Loss, and Budget Barchart are updated with this patch and should be fine. But the Budget Flow, and the Budget Balance Sheet are still to be done - again I miss a bit the understanding for these reports (don't use them myself), so updates on these are a bit tough for me. Anyway: Paul, can you take the patch and check if this is a good direction to go? Feedback not only from Paul is appreciated.
I have been using GNUcash for ten years and decided to set up a budget for the first time for this financial year (starting 1 April). I carefully cleaned up all the accounts and set up a budget and tried the various reports. The Budget report was OK. The Budget Flow report has a problem. While the payments section of the report shows the actual entries as +ve (which they should be), the receipts section shows them as -ve (which is wrong). I dont want to use -ve signs in the Budget as this would presumably mess up the Budget Report. GNUCash 2.6.1; Debian Testing. Phil.
Question most likely to Geert: After looking again into the Budget Flow Report and the Budget Balance Sheet Report, I would prefer the following way forward: 1. Create a new Bug for the Budget Balance Sheet When going through the code, I am not really getting all points together. I wonder if a more thorough walk-through is the more appropriate action, which I cannot do in the near time. 2. Create a new Bug for the Budget Flow Report If I get it right, this report is a sub-report from the Budget Report. It let's the user select specific budget periods and inserts sub-totals per account type. If that is it, I rather would like to introduce options into the Budget Report to get effectively the same result, and remove the budget flow report from the repository. -> The Budget Report does not show the inconsistent behaviour anymore. -> In addition budget period could be inserted, so the user cannot just pick more then one Budget Periods for the report. -> And it would mean to have one menu item less and one file less to maintain. The user can then prepare a Budget-Flow-like report by saving the wanted option configuration. 3. Use the patch from this bug as is for 2.6.4 and close this bug with reference to the new bugs. By doing so, at least those who do not depend on the Budget Balance Sheet and the Budget Flow can get rid of the inconsistent sign behaviour in near time. What do you think?
Carsten, I'm perfectly fine with creating separate bugs for the Budget Flow Report and the Budget Balance Sheet. I have had little time recently to review patches so I apologize for not checking this patch earlier. I have taken a first look at it now. If I understand your patch correctly you have chosen to store the straight or reversed values directly in the data file based on the value of reversed-accounts-incomeexpense and reversed-accounts-credit. This has important consequences: 1. The value storage is no longer consistent between the different objects in the data store. I suppose account budget values are to be compared at some point with account balances. Account balances are calculated from split amounts for splits in the given account. Split values are always stored in unaltered form, regardless of the values of the reversed-accounts-... options. The budget values on the other hand will get stored differently depending on the value of these options. 2. If this was only a data internal thing this would not really be a big problem. However it affects users in several unexpected ways: suppose the user has created a budget with the reversed-accounts-... options set. Then saves his data, plays with another book and changes the reversed-accounts-... options while there. When he then reopens his book the budgets values suddenly are interpreted backwards and the complete budget is mixed up. 3. Explicitly resetting the options is only one way this could bite: what if the data file is shared between computers and one computer has the options set one way and the other computer in a different way ? How can the user on the second computer know which budget values were intended ? This is the reason why the reversals only happen while displaying the values and not in the data itself. Can you see if you can rework your patch to do this as well ?
I am not sure whether I overlook something, but I think your doubts are covered already. To 1. "The budget values on the other hand will get stored differently depending on the value of these options" -> don't think so with respect to the first paragraph in comment 6. To 2. Mixed up behaviour does not happen. I just tried it out. To 3. I think that this is covered with 2. But you are right, that the sign of a budget is not free of misunderstanding, as the user's real intention cannot safely be determined. If the user specifies e.g. a negative expense budget value, it is not sure which direction of "cash flow" the user really has in mind, and with the application of this patch GnuCash might interpret it just the other way around. But in my eyes this cannot be compared with the handling done for the accounts. For the accounts, the user does not have to think about signs because the column (e.g. income vs. charge) are hiding this for the user. In the current budget implementation it is part of the design that the user must be aware of the meaning of the budget signs and place them correctly by him- or herself. The application of this patch might cause action (and thus confusion) to some users - but I do not really see an alternative for that in order to roll-out a fix for it.
Carsten, a long overdue reply. Thank you for your responses. You are indeed correct that the data is stored in a consistent way. I read your code incorrectly. But I still don't agree with the way you have solved this. The data in the save file may be consistent, the data in the running engine is not. None of the other objects in the engine are aware of any sign reversals by design. The engine always works with data in the correct sign and depends on this. Only the representation to the user uses sign reversals on user request. I really think it should stay this way. Not doing so makes the engine much less consistent and can lead to various unexpected bugs in future modifications because the design decision of consistent sign usage throughout the engine has been violated. When I met John while he was in Belgium, he suggested a mechanism that is used in wxwidgets. Unfortunately I forgot the name. @jralls: can you fill the hole in my memory ?
*** Bug 612214 has been marked as a duplicate of this bug. ***
Created attachment 283590 [details] [review] patch to be applied on top of GnuCash 2.6.3 I hope I got the point now :-)
Comment on attachment 283590 [details] [review] patch to be applied on top of GnuCash 2.6.3 Thanks for the updated patch, Carsten. This is indeed consistent with the gnucash design decisions, so good work ! Testing this patch I came across the following issues still: 1. Compared to the income statement there is still one sign reversal in the budget income statement, regardless of what sign reversal that is selected in the preferences: If none is selected as reversal preference the income statement will show all income accounts as negative and the income total as positive. If the sign reversal is set to income/expense, that is the case for expenses (expense accounts displayed as negative, expense total displayed as positive). So there is still some inconsistency between the reports. While mathematically inconsistent, I believe the behaviour of the income statement is the desired one. At least that's how I receive similar reports from my accountant. 2. This is a minor gui refresh glitch: if the currently active tab is a budget tab (not a report, real budget) the values in the budget don't update when you change the sign reversal preference. Switching to another tab and back does update the numbers. So we'd need to find a way for any budget tab to refresh itself whenever the preference option changes. My first option to investigate for this would be to have a budget page listen for a suitable qof event. Some more research is needed to figure out which one would be a good one though. 3. Lastly, the budget report itself (for which this bug was opened in the first place) is still misbehaving after your patch. All in all we're getting pretty close to nailing this issue :)
Regarding the gui glitch: I'm not sure how the other pages do this in gnucash. But here are two roads to check: a. you can register a callback that watches for changes in the preference option. You can use gnc_prefs_register_cb (in src/core-utils/gnc-prefs.h) for this, or gnc_prefs_register_group_cb if you want to listen to changes for all preferences in one group. You'd have to register your callback function three times - once for each of the three possible options. There should be several examples in the code you could learn from although I didn't find one specifically for the sign reversal options. b. you can redraw the plugin page when the component manager requests for this. I suspect this is how the account hierarchy page handles it. Most of our gui code registers itself with the component manager via gnc_ui_register_component. During registration it also specifies two callback functions the component manager can trigger: one to call when the gui element has to be refreshed and one to call when the gui element is to be destroyed. The one of interest here is the refresh callback. For example the account hierarchy plugin registers itself in src/gnome/gnc-plugin-page-account-tree.c:612 and uses gnc_plugin_page_account_refresh_cb as refresh callback. The refresh callback for the account tree is pretty simple. It will redraw the widget (only on forced refreshes here?). The budget plugin page does a similar thing in src/gnome/gnc-plugin-page-budget.c:437. It uses gnc_plugin_page_budget_refresh_cb as callback function. Note that this callback function is more picky about the events it handles. Perhaps it's sufficient to add what the account tree does in case there are no changes ?
Comment on attachment 273023 [details] [review] patch to be applied on top of GnuCash 2.6.2 Superseded
Hi Geert, Sorry for the long delay but at least I have a far better idea now about QOF and the implemented event system. I have found out that the gnc_Plugin_page_budget_refresh_cb is already called immediately once a change of the account preferences occures. That is why I think that an additional event subscription is not needed. Knowing this, I added an "else" clause at the end of the function to call the budget refresh. Basically the code says "if this callback function has not been called due to a registered QOF event, then refresh anyway". -> works fine So my current question is why there is a base condition that a QOF event has happened, or even more precise, if it is okay to reduce the QOF event check just to the QOF DELETION event and accept the refresh request otherwise. What is your opinion?
Created attachment 288768 [details] [review] patch to be applied on GnuCash 2.6.4 anyway, to cut a long story short: here is my next patch proposal
Hi Carsten, Thanks for the updated patch. The budget page now does indeed update upon preference change. Unfortunatly it updates too often: Each time the preference is changed the following warning is added in the trace file: * 19:08:14 WARN <gnc.gui> [gnc_configure_reverse_balance()] no reversed account preference set, using none This happens because changing the preference triggers two events: 1 event for the radiobutton that gets deactivated 1 event for the radiobutton that gets activated Ideally you should only trigger the refresh for the event emitted when a radiobutton gets activated. That will also half the number of refreshes triggered. In addition your patch results in the account hierarchy and the budget page to have consistently inverted signs for income and credit accounts. If the account hierarchy shows income accounts as positive the budget page will show income as negative and vice versa. The same so for credit accounts. And I see the same behaviour in the Budget Income Statement vs the Income statement report.
Hi All, nubie here, 2016. I am setting up Gnucash specifically to do budgeting. However, I found the same issue as above with BUDGET REPORT , namely, the signs are wrong! This seems true for my version 2.6.9 which I updated to latest 2.6.13?? and find the same problem. My test cell is entered as Liability, heading expense, automatigaally reducing 'cash in allet' by 150. this all makes sense. I create a budget, with 120 in the allocated slot. I do all budget actions, they all come out with the correct sign, WITH ONE EXCEPTION; the BUDGET REPORT shows 120 -150 -270 It has changed sign of actual figure 150, and then subtracted, giving 270 where i would have expected a difference of 30 +/- Unless I made a mistake, there is still a bug in this BUDGET REPORT I can of course artificially chane a sign someheree wlse, but this messes up other reports and titles. I did not see or toucg 'sign reversal' mentioned abouve, I took things as they are, simply. I would be very happy for comments, help, debugging as i am very interested in the budget aspect. tia
Hello All, In the Budget Flow report: - For the income section: According to the documentation, in the Budget Flow Report, the left column should show budgeted amounts and the right column shows actual amounts. In my simple understanding all amounts should be positive(Reverse Balance Accounts set to Credit accounts). However I encounter a problem: negative values are shown in the right column after entering the actual income values. These signs are confusing. Is this a known bug? Thanks
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=726674. Please continue processing the bug there and please update any external references or bookmarks.