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 ?
===
https://wiki.gnucash.org/wiki/images/8/86/Gnucash_erd.png
===
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
===
https://en.wikipedia.org/wiki/Test-driven_development
===
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 :)
--
Wm
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
