Future allocated money, aka Envelope Budgeting
christopher.lck at gmail.com
Sun Feb 4 08:44:59 EST 2018
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.
* 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
* 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
a demo of "what can be achieved using the engine". But I stress this was
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
>> 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
> 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
> 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
> Take the time to read something like
> I see gnc as part of the family, others don't because gnc *has* *a*
> *user* *interface* :)
> it can get odd. happy reading
More information about the gnucash-devel