Future allocated money, aka Envelope Budgeting

[Christopher Lam]

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
>