Future allocated money, aka Envelope Budgeting

Wm wm_o_o_o at yahoo.co.uk
Fri Feb 2 10:25:49 EST 2018

On 02/02/2018 08:17, Christopher Lam wrote:
> Dear Devs
> The more I consider (b)udget transactions the more I feel it is the 
> right solution. See 
> https://docs.google.com/spreadsheets/d/1aaMoMVVTky_Df_haNAeVk3XpsgFIC7eMOOT7uurlV-s/edit?usp=sharing 
> for an example of a report with these "b"udget and regular transactions. 
> This demonstrates regular $50 monthly budgeting, and quarterly $300 
> spending, with 1 overspending, and 1 underspending. It also works with 
> closing transactions... which are either enabled/disabled according to a 
> random switch. The chart can also demonstrate the metaphorical envelope. 
> I think this can easily be hacked into code.

Christopher, I've looked at your spreadsheet, it is pretty but I 
wouldn't do it it like that.  I also don't presume that the way that I'd 
do it would be something anyone else would like.  Do you see the problem 
yet ?

I'm not even sure the existing budgeting should be part of gnc in the 
long run, it is too quirky.  Every time someone new looks at it they 
say, "that isn't how a budget works! it should be like this ..."

Reason ?  Because budgets are personal things and gnc is not an 
"inspirational" accounting package.  gnc doesn't have a "run your life 
this way at it will be better, promise" attachment.  Why ?  Because it 
isn't selling anything.

I'd like it to stay that way.


There is, IMO, work to be done on on the underlying db structure, have 
you seen this monster ?
It is as ugly as an ugly thing (I'd say what I thought but I'd like more 
than a  mod to get to read this).

My point is that if the db made more sense you wouldn't even be thinking 
of writing code for your envelope budgeting, you'd open your spreadsheet 
and grab the stuff you wanted from the db, if you were happy with your 
work you'd say on the *user* list "hey folks, I've made a nifty envelope 
budgeting spreadsheet" and someone else would say, "that's neat, 
Christopher, how about you get it put on the gnc wiki" etc

> The dilemma is to consider how to modify the schema to achieve this:

Have you seen the schema ?  Link just above.

There *are* people that can get useful stuff out of the existing schema 
but there aren't many of us.  IMO we do *not* need extra crap inside the 
db that will just have to be picked out later on.

> Either way I'd be grateful if some pointers could be offered? Even if 
> code, UI and reports are not completed in time for 3.0, it would be nice 
> to formalize the schema 3.0 release?
> I may be able to do TDD for this @rgmerk

if TDD is
then let me know how it works alongside gnc because as a db person there 
are some really obvious things I can fix in minutes ... but if the stuff 
I wanted done got done, you wouldn't need to do what you want to do, etc.

Or as someone might once have said, let's feed the horse before we ask 
it to pull the cart to the brewery where we load the beer, oh, have we 
brewed the beer yet? no we need to get the barley from the field for 
that, ok, get the horse and cart and get the barley from the field, but 
we haven't fed the horse yet, ok, go get some hay, from the field, using 
the horse and cart ? etc

Don't try making sense of the para above, it isn't meant to make sense :)


More information about the gnucash-devel mailing list