Hi Wm
I wished to experiment in what budgeting should look like by using the
existing engine, UI, and reporting infrastructure.
It's actually not that difficult to create a 'budget balance
calculator'; whether it meets the needs for everyone is another matter.
But for people who wish to experiment with envelope budgeting, I can
confirm that it is possible.
Rules are:
* budget transactions must be "outside the books" so to speak, i.e.
they are not counted in any net worth, profit/loss, transaction
report, etc. they must be, by default, invisible to the reporting
engine.
* in order to be acceptable by the engine, they should they should
satisfy the double-entry equation.
* it should be generally useful
* it should be better than the current budget
So this is actually a success. I don't use transaction voiding, and have
hacked "voided transactions" to become "budget transactions" and
upgraded the status bar display. The results are available on the
topmost commit in
https://github.com/christopherlam/gnucash/commits/envelope-budgeting as
a demo of "what can be achieved using the engine". But I stress this was
an experiment.
HTH.
On 04/02/18 20:33, Wm via gnucash-devel wrote:
On 03/02/2018 00:12, Matt Graham wrote:
Wow! That become contentious quick!!!
Only sort of. If you read the devel list before the user list you get
a feeling for what isn't going to happen soon and why.
The primary issue I’m seeing here is one of philosophy. What is
GNUCash for? What is the purpose? What “should” be included and what
“shouldn’t” be?
It is for people, of course ! Perhaps you meant, "who is it for?" :)
There is a universe of people that like, use and prefer single entry
accounting along with the budgeting spiritualism and personal mantras
that accompany some of them. gnc ain't that and may not be for them.
Let me mention something else I think should, for example, be removed
once the db is sorted out: USA and other country specific tax stuff
(I'm not even sure how much of it works any more as governments change
their tax systems without consulting gnc, etc)
Double entry accounting has been around for a while, that is
definitely going to be included for ever.
Budgeting is, as I said before, personal. It varies from person to
person (I think envelope budgeting is short sighted) and what is
appropriate for a person is inappropriate for more formal
organisations that might require auditing or oversight.
If *all* the myriad of wonderful budgeting weirdness was added to gnc
the prog would more than double in size in a year ... each year ...
and 3 people would be using each of the special budgets and another 2
requests would come in each year, etc.
It just doesn't make sense putting more into an over stretched db
compared to an interface that anyone can grab anything they want from
using an ordinary spreadsheet.
Am I making sense?
gnc isn't
for a person of a certain nationality, it should work for most
gnc isn't
for a person or an organisation, it should work for most
gnc isn't
for a charity vs a business, it should work for most
gnc isn't
for a country, it works with currencies
etc
As has been highlighted, when someone loads up software they have a
preset notion in their own mind of how it “should” work, and that is
usually their own very narrow context (e.g. “That’s not how budgets
work!”).
gnc's existing budgeting is very useful to some businesses and charity
organisations, even though I use them in that context I still think
they should be pulled out in the long term. Budgeting is too
idiosyncratic.
And anyway, given a good interface you could use, I could probably
write a budget app a day.
NB: budgeting is not complicated computing, it is largely a human
problem rather than a computing one.
My assumption on purpose: Open source software is created out of need
and altruism. People who know how and want help create and maintain
the project both because they are interested in software and enjoy
the process, but also because they like being altruistic and
providing something that others find useful.
I won't speak for seniors, I do read what they say. Of course, my
understanding is mine if incorrect.
Based on that assumption, I have had the attitude “All requests
should be considered and prioritised by the devs, but of course they
will mainly implement what they find useful and of course they will
only give how much time they can afford to”.
devs may be busy, devs may have a long list, devs may have lives aside
from the project, etc
The natural flow on from my attitude is that I should indeed throw in
what I want/need from my financial tools, but not expect anyone to
act on it. If I want it done, I need to donate my time and implement
it because it is definitely unreasonable to demand others to do it
when it isn’t useful for them. (On that note, I’m keen to help out,
but don’t yet have knowledge (and also struggle for time) in all this).
The problem with gnc code at the moment is that there is very little
most people (or at least I) can do coding wise until the seniors get
their stuff done.
Monitoring the user list, knowing accounting, understanding stuff,
these are all useful things to do.
I have lots of specific comments against what people are saying, but
all would be unhelpful if my fundamental attitude to the project is
wrong.
Take the time to read something like
http://plaintextaccounting.org/
I see gnc as part of the family, others don't because gnc *has* *a*
*user* *interface* :)
it can get odd. happy reading
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
