Budgeting proposal

Dave Fancella david.fancella at attbi.com
Mon Apr 14 13:40:51 CDT 2003


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:


Amount is obviously the arbitrary amount of money budgeted.  :)  Milestone and 
basetimeunit work together to determine the length of time for recurring 
budgets.  Setting these to 0 should determine that the budgeted amount is not 
recurring and the entire amount is budgeted for the entire length of time 
starting with openingdate and ending with expires.

The part where it gets tricky is in the milestone/basetimeunit relationship.  
basetimeunit is a number in relation to a year.  There are x basetimeunits in 
one year, and the ratio is this:


To create a recurring monthly budget, you need to have 12 occurences in one 
year, one for each month.  So basetimeunits = 12.  Now you need to have a 
frequency for the budget, which is what milestone represents.  If you pay 
this every month, set milestone to 1.

To create a recurring budget that recurs every other month (bimonthly), you 
have two options.  You can set basetimeunit to 6 and milestone to 1, or you 
can set basetimeunit to 12 and milestone to 2.

Then, the recurring amount will recur at the set interval starting on 

Algorithmically, it'll be up to the module that's using this information to 
determine what to do about it.  A report that shows budget expenses over time 
will have to calculate every single budget record it finds associated with 
the account in order to determine all of the milestones, even when the 
interval has been changed completely, and show holes where the budget didn't 
provide coverage (and reveal any transactions that land within those holes), 
overlapping areas (and whether or not to further expand the fraction to 
determine the exact amount of money that covers the overlapped period of 
time) and so forth.  Projecting into the future should be as simple as using 
the expiration dates to mark the current budget, and allowing for predictable 
budget changes in time (and highlighting accordingly).

Ok, I think that's as fuzzy as I can make it--er, as clear as I can make it.  
:)  Now for the GUI:

In the GUI, there are these additions that are necessary to support 
budget-at-a-glance.  In the accounts window, two optional columns need to be 
added allowing for the current budget.  The two columns will be Budgeted 
Amount, and Total Left in Budget (Budgettedamount - (debits + credits)).  In 
the account properties window there will be needed several additions to 
support budgeting.  There's plenty of room for discussion on how to implement 
the user interface, but I personally don't want to rip off Quicken on this 
because their interface sucks.  Unfortunately, I have no better suggestions.  
Finally, in the Account Register, two new fields at the bottom next to the 
balance need to appear, showing summary budget information for the current 

More stuff for the GUI, of course:

Reports to lay out your expenses according to budget, account reports that 
include budgeting information, etc.  Also, another dialog specifically for 
managing your complete budget.

There's plenty of room for discussion in the whole thing, of course.  :)  I 
want to get the budget outlined and then implement something basic to cover 
simple month-to-month budgeting.

I also want something to show credit limits and calculate available credit.  
The budgeting architecture can be used for this, actually, but I'm wondering 
if it should be separated anyway.  Something like /creditlimit = (number).  
Then there would be summary information in the accounts window and account 
register, just like the summary information I outlined for budgets.  IN order 
to get a handle on all the budgeting stuff, I would like to first pursue 
implementing credit limits exactly like this.  Naturally, I also want to do 
whatever is needed to get my code merged into the main source tree so 
everybody can have it.  :)

"I slipped inside the oval office,
I slipped in oh so fast,
Grabbed the president by the necktie
And wiped my funky ass, hey"
                -Soulhat, "Bonecrusher"

More information about the gnucash-devel mailing list