Thu, 15 Feb 2001 01:13:47 -0800
On Wed, Feb 14, 2001 at 11:03:44AM -0500, Gregory Novak wrote:
| True, but I think that asking the user to define an entire additional
| additional set of categories for budgeting is asking for trouble.
Maybe, maybe not. It's all about presentation and user interface.
I do believe that the budgeting categories are not going to be the same
as the expense categories... they will generally be a subset [and, in my
case they might very well be a one-to-one map], but the user should be able
to create a set of budgeting categories on the level which she wishes...
For instance, I may have expense [sub-]catgories for ea. type of donation
I make to various organizations. But I would probably budget this on
a yearly scale as "Donations". Entertainment, as well... I might have
categories for books and movies and painting supplies and whatnot, but
I'd probably just budget the category as a whole...
Taken to the other extreme, I might have a lot of budget categories,
but no expense categories... I may not care about tracking my expenses
[no matter how easy GnuCash makes it :)], but I still want to make a
budget over some general expense categories, and just leave the rest of
my expenses [and my spending allowance] as the difference between known
income and known expenses...
| believe I've seen talk of associating a "category" with every transaction
| in addition to the account info. If budgeting could be folded into this
| category specification, then we're golden, but if not, adding budgeting
| category information on top of this would be unwieldy.
Agreed... though I think you might be talking about what's in the
todo/projects page on the web site, the point still holds: Given the
mapping between the bcats and the normal accounts, I think the budgeting
specification can be "folded into" this process quite seamlessly... and
it's indeed necessary to keep the user burden from becoming overwhelming.
As well, there should be a tool to help the user create suitable budget
categories from an existing account tree... allowing the user to --
starting from the act tree -- easily change the granularity of bcats they
As I see it, once the budgeting categories are created and associated
with expense/income/liability accounts and template transactions [which
can also be deduced from historical data and UI help], then the existing
transaction entry and account linking should suffice to provide data to
the budgeting subsystem...
| It seems to me that this would give you a lot of generality with very
| little effort in setting things up (for the user).
They're orthogonal things... The user can have it good, and we don't have
to throw away relational data which is useful for analysis...
But I don't think I'm quite understanding your budgeting world view...