[GNC-dev] About budgets in 3.8, 3.9 and 3.10

Christopher Lam christopher.lck at gmail.com
Mon Apr 27 09:12:41 EDT 2020


Thank you Phil.

I'm sure you know the issue with existing budgets - they do not behave as
expected when the Estimate tool is used to pre-fill cells, when
sign-reverse isn't credit-accounts.

There is *another* issue (not documented afaik in bugzilla) about budgets:
the totals do not total budget-amounts whereby account-type is
bank/cash/loan; i.e. it only tallies account-type asset/liability/etc. I
*think* this should be fixed. Any ideas?

Derek has kindly agreed to create regular flatpak builds for me and these
builds need testing. It is very difficult to fix the above without adequate
testers using their existing budgets. The next candidate will be available
in https://code.gnucash.org/builds/flatpak/christopherlam/beta/ (after
27/4/2020)

Your YTD feature has been replicated in the existing budget report - see
General / use accumulated amounts

Summing children accounts will always be difficult because children
accounts may have an incompatible account type.

On Mon, 27 Apr 2020 at 11:34, Phil Longstaff <phil.longstaff at gmail.com>
wrote:

> Hi Chris,
>
> thanks for taking this on. I am sorry I don't have more time to commit to
> the project.
>
> I don't like the terms "Outflow to Asset" and "Inflow to Liability".
>
> For Assets, here is how I see a budget being used.
>
> If I want to plan to put money into savings (an asset), I will have a
> budget with a positive value for that month for that account.
> If I want to plan to pull money from savings (e.g. a retirement savings
> fund), I will have a budget with a negative value for that month for that
> account.
>
> For Liabilities, it is similar.
>
> If I plan to pay off part of a loan or line of credit, I will have a budget
> with a negative value for that month for that account.
> If I plan to increase the value of a loan or line of credit, I will have a
> budget with a positive value for that month for that account.
>
> In other words, positive value increase an asset or liability, and negative
> values decrease them.
>
> In this case, the room left in my budget is Income - Expenses - Assets +
> Liabilities.
>
> If I can speak to the budget report for a minute, there are 2 things I see:
>
> 1) I miss the ability to see YTD. A few years ago, I created a report which
> had 3 sets of columns: current month, YTD, and total year. I find YTD
> useful because for some accounts, I may have an idea of the total budget
> for the year, but do not know the timing. I can then either allocate the
> whole budget to one month (January? December? July?) or split it evenly
> across all months. I usually split it. An example is car maintenance. I
> know that my car will need about $X repairs for the typical year, but I
> don't know when the repairs will be. I allocate $X/12 for each month. If I
> put the entire value $X in 1 month, it gives me a skewed idea for my budget
> room for that month. Putting $X/12 for each month, it is easier to see that
> some months, income > expenses, and for other months, income < expenses,
> but for the year, it evens out. I use YTD and Total Year columns to see how
> well this evening out is working.
>
> 2) For parent rows, I would like to see the budget and actual values show
> the sum of the selected children, not all children. I may wish to produce a
> budget report for a subset of all of my expense accounts (e.g. my wife's
> and my personal expenses like clothing, haircuts, etc). The problem is that
> the "Expenses" parent line shows the actual value of *all* expenses, not
> just the ones I have selected. This is
> https://bugs.gnucash.org/show_bug.cgi?id=780382. My Scheme is not very
> good, but I will see if I can find some time to look at this one.
>
> Phil
>
> On Mon, Apr 27, 2020 at 12:10 AM Christopher Lam <
> christopher.lck at gmail.com>
> wrote:
>
> > Would anyone object to the following (last) amendment to budget totals:
> > separate the account types, and add 'Remaining to budget' line which
> > implements the budget-to-zero facility, and *will* replicate the 3.7
> > behaviour.
> > (Note the totals *will* be renamed to "Total Assets" "Total Expense"
> etc.)
> >
> > [image: budget-view.png]
> >
> >
> > On Sun, 19 Apr 2020 at 05:07, Christopher Lam <christopher.lck at gmail.com
> >
> > wrote:
> >
> > > Thank you for trying Adrien. This budget bug is proving to be a major
> > > headache. I really need more beta testers, especially with ability to
> > build
> > > from my branch.
> > >
> > > Of note:
> > > * previous methodology was: in a period, budgeted income, minus
> budgeted
> > > expense and any asset/liability transfers, must result in zero. This
> > > assumes credit-accounts sign reversal.
> > > * future methodology is: in a period, all natural budget amounts must
> > > equal zero. i.e. incomes being negative, will be balanced by positive
> > > expenses etc.
> > >
> > > My plan to try fix this for good is to *remove* all totals except the
> > > "Remaining to Budget"; from my understanding this is the only total of
> > any
> > > use.
> > >
> > > Alternatively, another plan is to switch to future methodology and
> forego
> > > backward compatibility in existing budgets, for use in 4.x or 5.x.
> > >
> > > On Fri, 10 Apr 2020 at 17:59, Adrien Monteleone <
> > > adrien.monteleone at lusfiber.net> wrote:
> > >
> > >> I just posted my first result and impression to the bug report, though
> > >> I’m sure you saw that already. (this is more for the benefit of list
> > >> readers not following the bug)
> > >>
> > >> The signs aren’t making sense, and the amounts aren’t adding up
> > correctly.
> > >>
> > >> Regards,
> > >> Adrien
> > >>
> > >> > On Apr 10, 2020 w15d101, at 5:59 AM, Christopher Lam <
> > >> christopher.lck at gmail.com> wrote:
> > >> >
> > >> > Next addendum: your existing budget data will behave well when
> reverse
> > >> > balances=credit accounts, but the *featured* data will be stable
> with
> > >> *any*
> > >> > reverse balances global preference option.
> > >> >
> > >> > On Fri, 10 Apr 2020, 11:28 am Christopher Lam, <
> > >> christopher.lck at gmail.com>
> > >> > wrote:
> > >> >
> > >> >>
> > >> >>
> > >> >> On Fri, 10 Apr 2020, 10:20 am Christopher Lam, <
> > >> christopher.lck at gmail.com>
> > >> >> wrote:
> > >> >>
> > >> >>> Deadline is 11 April at noon GMT, so, about 34 hours from now.
> > >> >>>
> > >> >>> For both: *existing* datafile and especially *4.x-featured
> *datafile
> > >> (in
> > >> >>> bug report).
> > >> >>>
> > >> >>> Please test:
> > >> >>> - creation of budget amounts
> > >> >>> - use estimate to prefill cells
> > >> >>> - all totals in all 5 account types A/L/Inc/Exp/Eq behave
> > >> appropriately
> > >> >>>
> > >> >>
> > >> >> Addendum this is not simply an arithmetic test; it *****must****
> also
> > >> >> confirm that the totals and signs are sensible for the purpose of
> > >> >> budgeting. Hence the difficulty of a one person coder to make it
> > work.
> > >> For
> > >> >> example, we can budget a liability account regularly until we have
> > >> enough
> > >> >> deposit for a huge loan, or we can budget a liability account
> > >> regularly for
> > >> >> the loan repayments. IIUC both approaches are "valid" but the signs
> > >> will be
> > >> >> opposite. Other counter examples likely exist.
> > >> >>
> > >> >> - budget.scm report (optionally other budget reports but these are
> > >> lower
> > >> >>> priority) and especially difference column.
> > >> >>>
> > >> >>> On Fri, 10 Apr 2020 at 02:16, Adrien Monteleone <
> > >> >>> adrien.monteleone at lusfiber.net> wrote:
> > >> >>>
> > >> >>>> Thank You! This makes it so much easier to test. I’ll give the
> > >> flatpak a
> > >> >>>> spin and see what I find. I still haven’t set up a build
> > environment
> > >> for
> > >> >>>> Mac yet. (and watching a recent thread on the subject makes it
> look
> > >> >>>> daunting compared to Linux)
> > >> >>>>
> > >> >>>> This is a busy weekend for me though. What kind of time frame do
> > you
> > >> >>>> have and is there something in particular you’re looking to find.
> > >> (other
> > >> >>>> than just loosely that the totals appear to work)
> > >> >>>>
> > >> >>>> Regards,
> > >> >>>> Adrien
> > >> >>>>
> > >> >>>>> On Apr 9, 2020 w15d100, at 9:10 PM, Christopher Lam <
> > >> >>>> christopher.lck at gmail.com> wrote:
> > >> >>>>>
> > >> >>>>> 2020-04-07 nightly available at
> > >> >>>> https://code.gnucash.org/builds/win32/maint/
> > >> >>>>> flatpaks available at
> > >> https://code.gnucash.org/builds/flatpak/maint/
> > >> >>>> - use
> > >> >>>>> between 2020-04-04 and 2020-04-10
> > >> >>>>>
> > >> >>>>> On Fri, 10 Apr 2020 at 01:38, Christopher Lam <
> > >> >>>> christopher.lck at gmail.com>
> > >> >>>>> wrote:
> > >> >>>>>
> > >> >>>>>> This topic is about budgets.
> > >> >>>>>>
> > >> >>>>>> We now know that budgets are currently inherently flawed: they
> > >> >>>> *assume*
> > >> >>>>>> that sign-reversal = credit-accounts, and do not work well at
> all
> > >> >>>> with any
> > >> >>>>>> other sign-reversal option. In addition, there was a feature
> > >> request
> > >> >>>> (bug
> > >> >>>>>> 781345) that introduced budget equity into the equation, and I
> > >> still
> > >> >>>> do not
> > >> >>>>>> know whether a budget equity amount is a correct approach.
> > >> >>>>>>
> > >> >>>>>> In 4.x series there is a planned *fix* which will scan budget
> > >> amounts,
> > >> >>>>>> use heuristics to determine the most likely sign-reversal
> > approach
> > >> >>>> used
> > >> >>>>>> during budget creation, internally unreverse the amounts, and
> > >> upgrade
> > >> >>>> the
> > >> >>>>>> datafile so that it cannot be damaged by 3.7 or earlier.
> > >> >>>>>>
> > >> >>>>>> Therefore 3.8 was the first release which could handle both old
> > and
> > >> >>>> fixed
> > >> >>>>>> budget amounts. Unfortunately, the interpretation of budget
> signs
> > >> >>>> was/is
> > >> >>>>>> very difficult, which explained the switch to
> > >> >>>>>> asset/liability/equity/income/expense totals, which are
> > impervious
> > >> to
> > >> >>>>>> budget signs. Unfortunately users missed the "Remaining to
> > Budget"
> > >> >>>> facility.
> > >> >>>>>>
> > >> >>>>>> Therefore 3.9 was, during development, tested with
> > >> >>>>>> https://github.com/Gnucash/gnucash/pull/630 and was deemed
> "good
> > >> >>>> enough"
> > >> >>>>>> to fix to restore the remaining to budget total. Unfortunately
> > the
> > >> >>>>>> liability budget amount issue was tested incorrectly.
> > >> >>>>>>
> > >> >>>>>> For a week, the git-maint contained a candidate fix, discussed
> in
> > >> >>>>>> https://bugs.gnucash.org/show_bug.cgi?id=797659 -- but there
> is
> > >> >>>>>> insufficient beta testing on the budgets for now. So, 3.10 will
> > >> >>>> retain 3.9
> > >> >>>>>> behaviour unless the fix is fully tested.
> > >> >>>>>>
> > >> >>>>>> Conclusion: this is a call for beta testers, using the
> 2020-04-07
> > >> >>>> nightly
> > >> >>>>>> (the only one with the fix), to test both their datafiles and
> the
> > >> >>>>>> *4.x-featured* datafile attached in the bug report. Please
> > >> >>>> *especially*
> > >> >>>>>> test the liability and equity totals, both with existing
> datafile
> > >> and
> > >> >>>>>> featured datafile.
> > >> >>>>>>
> > >> >>>>>> Flame away. I will try to be available throughout the day for
> > >> testing.
> > >> >>>>>> Win32 users have only 1 build to test, Linux users may also
> build
> > >> from
> > >> >>>>>> 882fd22ca rather than git-maint which has returned to 3.9
> > >> behaviour.
> > >> >>>> I'm
> > >> >>>>>> not sure how MacOS users can test.
> > >> >>>>>>
> > >>
> > >>
> > >> _______________________________________________
> > >> gnucash-devel mailing list
> > >> gnucash-devel at gnucash.org
> > >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> > >>
> > >
> > _______________________________________________
> > gnucash-devel mailing list
> > gnucash-devel at gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>


More information about the gnucash-devel mailing list