Patch to partially add recursion to budgets
Chris Shoemaker
c.shoemaker at cox.net
Thu Sep 28 11:11:13 EDT 2006
On Thu, Sep 28, 2006 at 02:30:16AM -0500, Gregory Alexander wrote:
> 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.
Yes, the user must enter a budget value for each account they want to
compare. Also keep in mind that there are cases where the user wants the
budgeted value for the parent to be different than the sum of the
budgeted values for children.
> 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) *
I'm not so sure this is generally good behavior. Imagine that the
user only cares to budget for _some_ of the children accounts, and not
the parent. In that case, using the sum of the budgeted children as
the parent's budgeted value isn't correct.
> 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.
Hmm. I expected that the normal usage of the budget report would be
to only include the accounts that you budgeted for. But, I can
imagine some cases where it might be interesting to see the accounts
you budgeted for alongside the accounts you didn't, in the same
report.
> 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.
That sounds useful.
>
> 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?
Yes, it does. And easier, too. It could involve:
1) return one of the of the gnc_numeric error states from the
get_budgeted_value() when it was unspecified.
2) Allow set_budgeted_value() to "unset" the value if a bad numeric is
supplied. (or, provide an unset_budgeted_value()).
3) Teach the report to do something pretty for unspecified budget
values.
Are you interested in patching that up?
-chris
More information about the gnucash-devel
mailing list