Future allocated money, aka Envelope Budgeting
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
> 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
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