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

Mon Apr 27 07:33:16 EDT 2020

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
>