Budgeting proposal

Matthew Vanecek mevanecek at yahoo.com
Wed Apr 16 23:20:18 CDT 2003


On Mon, 2003-04-14 at 14:40, Dave Fancella wrote:
> All,
> 
> Ok, I've beat this around irc a little bit, and here's what I've come up with:  
> (this is long)
> 
> First, I'll define budgeting.  :)
> 
> Budgeting is a means to determine an arbitrary amount of money to be 
> transferred within an arbitrary period of time.  The transfer can be either 
> incoming or outgoing, and the arbitrary period of time need not be linked to 
> any specific interval.
> 

> Second, here's how I want to represent this.
> 
> Using the kvp architecture (thanks warlord!), we'll have the budget 
> information linked directly to the account.  The information actually has to 
> be stored over time, and it also needs to be easily changeable over time, 
> keeping all historical changes along the way.  So here's the setup:

This is, IMO, a bad idea.  A Budget is a separate entity; it should not
be relegated to the ambiguous netherworld of kvp-dom (KVPs are suitable
for extending existing objects, I guess, but should be avoided for new
entities--a Budget is a new entity).  

Budgets are only loosely linked to Accounts.  Accounts are handy to have
when you set up your Budget, because the BudgetCategories can be taken
directly from the Account hierarchy.  E.g., "create me a new Budget
based on my Account tree".  In a robust system, you would be able to
link and delink BudgetCategories to/from Accounts.  A delinked
free-standing BudgetCategory may not be very useful without an Account,
but there you go...

Once you have your Budget hierarchy created (either manually, or based
on you Account hierarchy), you can enter the period of time for which
the Budget is effective, as well as individual amounts for each
BudgetCategory.  Note that it would be useful to have the amount entry
automated based on the Account history for a period of time (where the
period of time is user-specified).

The above model is greatly simplified, of course, from my vision of the
whole thing.  You should be able to edit the Budget in a similar fashion
to editing Accounts.  That is, the hierarchy would be displayed the same
as the Account hierarchy, but "opening" a BudgetCategory would bring up
a dialog to edit the currency amount, etc.,  instead of bringing up a
register.

This model also allows for creating several simultaneous Budgets and
running scenarios/reports against each one to determine the most
favorable outcome, or whatever.  You could, perhaps, mark a given Budget
as default, and all reports are run against that Budget by default. 
Reports could show you how your current expenditures match your Budget,
etc.  A lot of the tracking stuff doesn't really need to be stored--it
can be captured in reports as needed.

As for your columns idea to show the budgeted amount and the current
Account balance, I like that idea.  To implement it, you would just mark
a given Budget as default (with appropriate date reasonability checks,
of course), and you could see the difference.  This would require,
though, that the Account balances be captured for the same period for
which the Budget is effective.  I think, in the short term, that a
dynamic report would be easier to write, though.

I think conceptually, we're pretty close.  One point I'd like to make
though:  where you use months/basetimeunits, etc., we need to be sure
that the effective time period for a Budget is 100% customizable.  For
example, my current project at work certainly has a time limit, but the
Budget is actually (or will be, when approved. :( ) effective for the
life of the project, as opposed to effective for a period of time.
Subtle difference, but critical.

Good thoughts,
-- 
Matthew Vanecek
perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
********************************************************************************
For 93 million miles, there is nothing between the sun and my shadow except me.
I'm always getting in the way of something...



More information about the gnucash-devel mailing list