Patch to partially add recursion to budgets
Gregory Alexander
gregalexa at gmail.com
Thu Sep 28 03:30:16 EDT 2006
I apologize for the rich-text formatting, I needed it to get the mock-ups to
look right.
Hmmm, thanks for pointing me at that file. Now I understand the design
philosophy behind what I thought was a functional bug. I think the reason I
found it counter-intuitive is that this is different from how the rest of
gnucash works, where account either stand on their own or are the sum of
their sub-accounts.
I think it will help to work backwards from the report I want to generate to
determine what the correct behavior is.
I want to generate a budget report that looks something like this:
Budget entered by user:
Expenses 500
Bills 200
Non-Bills 300
Food 100
Entertainment 50
Car 150
Misc. 0
Account: Budget: Actual: Remain: Percent remain:
Expenses 500 250 250 50%
Bills 200 100 100 50%
Non-Bills 300 150 150 50%
Food 100 50 50 50%
Entertainment 50 60 (10) (20%)
Car 150 0 150 0%
Misc. 0 40 (40) *
Right now, the user has to manually enter the budget values for each line,
including the Non-Bills and Expenses parent categories. That's a lot of
work for the user, but if they really want to track at all those granularity
levels, it's probably worth it, espescially if they want a slush fund, or
they've over child-budgeted at any parent level.
Now, let's assume the user doesn't actually care about the Non-Bills
category. It's just a placeholder (I can come up with some better reasons
for this, but I want to keep using the same account structure.) Here's what
happens if the user just doesn't fill in that category in the budget:
Budget entered by user:
Expenses 500
Bills 200
Non-Bills 0
Food 100
Entertainment 50
Car 150
Misc. 0
Account: Budget: Actual: Remain: Percent remain:
Expenses 500 250 250 50%
Bills 200 100 100 50%
Non-Bills 0 150 (150) *
Food 100 50 50 50%
Entertainment 50 60 (10) (20%)
Car 150 0 150 0%
Misc. 0 40 (40) *
Now the user has an ugly negative 150 in the remain column under non-bills.
Just looking at the zero in Budget doesn't work, because there was a
legitimate 0-budget column that had unexpected expenses.
The user would probably prefer to have one of the following happen.
Option 1 (what I suggested earlier): fill in from the bottom-up. This gives
the user extra data for free, but clutters up the chart with data they don't
care about.
Budget entered by user:
Expenses 500
Bills 200
Non-Bills 0 (Sum children)
Food 100
Entertainment 50
Car 150
Misc. 0
Account: Budget: Actual: Remain: Percent remain:
Expenses 500 250 250 50%
Bills 200 100 100 50%
Non-Bills 300 150 150 50%
Food 100 50 50 50%
Entertainment 50 60 (10) (20%)
Car 150 0 150 0%
Misc. 0 40 (40) *
Option 2: Mark entry as unbudgeted.
Budget entered by user:
Expenses 500
Bills 200
Non-Bills 0 (Unbudgeted)
Food 100
Entertainment 50
Car 150
Misc. 0
Account: Budget: Actual: Remain: Percent remain:
Expenses 500 250 250 50%
Bills 200 100 100 50%
Non-Bills . 150 . .
Food 100 50 50 50%
Entertainment 50 60 (10) (20%)
Car 150 0 150 0%
Misc. 0 40 (40) *
I think option 2 is actually a better option, though it is interesting that
it's nowhere near where I expected to end up.
Thus, I think we need to be able to add an "unbudgeted" state to a budget
value, which is *DIFFERENT* from a budget value of 0. I'm having a hard
time imagining what that would look like in the budget entry, unless it
would just be a budget without even a '0' in the amount.
The need is even more clear if you consider the following scenario, (which
is one I got from gnc-budget.h):
Budget entered by user:
Expenses 500
Bills 200
Non-Bills 300
Food 0 (Unbudgeted)
Entertainment 0 (Unbudgeted)
Car 0 (Unbudgeted)
Misc. 0 (Unbudgeted)
(current:)
Account: Budget: Actual: Remain: Percent remain:
Expenses 500 250 250 50%
Bills 200 100 100 50%
Non-Bills 300 150 150 50%
Food 0 50 (50) *
Entertainment 0 60 (60) *
Car 0 0 0 *
Misc. 0 40 (40) *
(Option 2)
Account: Budget: Actual: Remain: Percent remain:
Expenses 500 250 250 50%
Bills 200 100 100 50%
Non-Bills 300 150 150 50%
Food . 50 . .
Entertainment . 60 . .
Car . 0 . .
Misc. . 40 . .
Here again, option 2 is much cleaner, and makes for a nice report.
Does this seem like a more reasonable path?
Thanks!
GREG
Responses to your comments below, though I no longer think I was headed in
the right direction. Read and dump.
On 9/27/06, Chris Shoemaker <c.shoemaker at cox.net> wrote:
> On Wed, Sep 27, 2006 at 12:59:34AM -0500, Gregory Alexander wrote:
> I'm thinking that
> what you describe is probably not so much a bug as a difference of
> expectations. See below...
Agreed. The budget process is counter-intuitive. This doesn't mean it's
bad, but it means that it requires a LOT of documentation, and much better
documentation that is currently available.
> At the end of the day, you need two sets of comparable numbers,
> actuals and budgeted. To be comparable, they need to be either both
> recursive or both not.
Agreed, with the caveat that sometimes the user doesn't really want anything
compared.
> Currently, GnuCash only supports "both recursive". However, that
> _doesn't_ mean that budgeted values are summed from children accounts'
> budgeted values. (That would quickly become very complicated in
> multi-currency situations.) Instead, the user specifies the "summary"
> budgeted value, i.e. recursive.
This was NOT the behavior I expected, because it is different from the way
the rest of gnucash works. See below. I think this would be easier with
more documentation.
> In this implementation you don't have the ability to
> budget for transactions that post to a parent account while excluding
> transactions that post to the account's children. I think this is an
> uncommon need.
I'll buy that.
> So, what would happen if GnuCash supported "both not recursive"? For
> one, you now have to specify budget values for the actual accounts
> that transactions are posted to. You lose the ability to choose a
> parent account, and to budget at a level of detail less than what you
> use for accounting. I think this is quite a common need.
Again, I agree.
> Side note: Can you specify budgets non-recursively, but then report
> recursively? Maybe, but then the "reported" budget value for a parent
> account with some non-recursive value is different than the
> "specified" budget value for that account. Isn't that pretty weird?
NO, that isn't weird, that is typical gnucash behavior for pretty much
everything except budgets. I enter transactions within subaccounts and they
show up in the reports for the parent. When looking at *transactions* in
the parent, you *usually* are only looking at transactions that act directly
on the parent account.
I still think I'm wrong, but for the reason you state in gnc-budget.h.
Building reports my way causes budgets to have to be built from the bottom
up. That's a bad workflow to force on users. Did I mention that
documentation might help in this area? :)
What I think we *DO* need is a way to differentiate between account that
have a budget of $0, and accounts where we really don't want to track budget
data. The need for that differentiation is more clear when looking at my
report above, where handling a false zero makes the report harder to read.
> Anyway, I concluded that being able to budget at different levels of
> detail was more important than being able to budget for accounts
> excluding their children.
Agreed.
> That said, if you really want to specify budgets non-recursively, then
> you're really changing the meaning of the stored values, so you should
> reflect that in the budget model, with an additional boolean structure
> member. That way, you can ensure that the reporting is consistent
> with the specification method.
I agree, but I think that would be ugly feature creep, and a good maintainer
wouldn't take my patches if I submitted them, so I'm not going to go there.
More information about the gnucash-devel
mailing list