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 :)


gnucash-devel mailing list

Reply via email to