Budgeting - Let's decide what we want!

[Matthew Vanecek]

On Fri, 2003-08-29 at 09:41, Jesse Guardiani wrote:
> Stewart V. Wright wrote:
> 
> [...]
> 
> > 2.2 The Problem
> > 
> > The problem with this sort of budgeting is that
> > currently it is not possible to implement this virtual
> > division of income in a simple manner that also allows
> > the easy reconciling of bank statements that (in my
> > opinion) is a great aspect of GnuCash.
> > 
> > I do however have a suggested method of implementing
> > such a system which I believe will add to the strengths
> > of GnuCash without changing the behaviour for anyone
> > who doesn't wish to work in this manner. This is an
> > important requirement of any budgeting extension to
> > GnuCash. Those who don't want to budget in GC shouldn't
> > have to do anything differently to the way they do now.
> > 
> > 3 Budgeting in GnuCash
> > 
> > This section suggests a slight extension to the account
> > structure of GnuCash to allow the budgeting approach of 2.1
> >  without modifying the current behaviour for most users.
> > 
> > 3.1 Virtual Accounts
> > 
> > Budgeting is often achieved by the use of an imaginary
> > division of income and expenses into user defined
> > categories. Keeping with the terminology of GnuCash
> > these imaginary categories will be known as Virtual
> > Accounts (VAs).
> > 
> > In summary VAs are a imaginary asset/liability/expense
> > source that are used to divide income and expenses as
> > defined by the user. The major difference from regular
> > Accounts is that a leaf VA will mirror all expenses to
> > the first (real) Account that sits above it.
> 
> I am a new (started about 1 month ago. Feel like I have
> a good grasp on the functionality now.) GnuCash user,
> and a programmer/sys admin.
> 
> I think the above can be accomplished WITHOUT implementing
> an entirely new "Virtual Account" concept. I think the current
> GnuCash subaccounts are adaquate.
> 

The 'Virtual Accounts' is the proper way to implement budgetting.  A
budget is a separate entity.  It's relationship to your accounts is very
loose and malleable.  You can associate a Budget account with an actual
account of a completely different name.  The budget is editable separate
from the accounts it is supposed to be guiding.

What is needed:
1) Generate a Budget hierarchy from the existing accounts, or create it
dynamically from scratch.  This decouples the Budget from the accounts,
and allows you to add Budget items that don't have account
represenation.  It also allows you to model several different scenarios
by creating different Budgets.

2) Populate the Budget amounts either dynamically, or as some sort of
average of the related account(s) over time.

3) To track how your actual cash flow compares to the Budget, you run
reports that draw from a user-specified Budget and the accounts you want
to track.

There is no concept of sub-account useage or anything like that--trying
to group subaccounts under a checking account is too time consuming and
hard to maintain.  Also, it is very, very unscalable.

A lot of people try to look at the money they receive and spend as the
budget that is tracked in the accounts.  That is simply not true. 
Tracking the money you receive and spend is accounting.  You move money
from income to expenses or assets (usually via a bank account).  A
Budget, on the other hand, represents how you are *planning* on moving
your money around.  It can take as its foundation a history of actual
money movement, but other than some loosely-coupled relations between
Budget categories and Accounts, there is no relationship between Budget
and Account (in programatic implementation, not practice).  You use
reports to track overages and underages.

That's budgetting in a nut shell.  The above concept scale remarkable
well from home users to large businesses.  I don't see any need to have
different implementations for the two user sets.  Basically, both need a
"how do I *plan* to spend the money", "how have I *spent* the money",
and a "how do the two compare" functionality.  Warnings for
over-spending or whatever is simply fluff and frills built on top of the
basic implementation.

ciao,


-- 
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...