Re: Future allocated money, aka Envelope Budgeting

[Wm via gnucash-devel]

On 07/02/2018 09:45, Alen Siljak wrote:

He he

Thanks a lot for the tips. I'm in touch with Sebastien in order to
polish the ledger export script. It is available either directly
(pc-export has been renamed to export.py) or through piecash cli
("piecash ledger" is the command if I remember well).
Hopefully over the weekend I'll have some more time to play around with
the whole process:

gnucash -> sqlite db -> piecash export -> ledger data -> ledger or
beancount -> fava or custom web interface


beancount has a sort of sql of its own.  I'll say no more since I 
suggested the idea *after* my sql balance sheet, etc appeared here and ...


in  general many people are more casual about how exactly you store your 
plain text accounting data and consider an almost readable format (XML) 
or open db (all available gnc backends) as good as.



I did not notice if asset allocation is available through Fava. Either
way, I need to investigate that into more detail and see if I can get
something similar to the view I already created in Gnucash Portfolio.
I'm hoping it would be easier to contribute to an existing project than
write and maintain the whole thing from scratch.
I'll be interested to see how you get on.  I'm not sure how far you want 
to go with the portfolio ideas.



There is also another Python export script at
https://github.com/MatzeB/pygnucash. I hope to combine the wisdom from
both of these.


I had to re-write a bit of that IIRC so you are probably better working 
with Sebastien.



Is anyone aware of how close Beancount is to Ledger in terms of
functionality?


they are diverging rather than converging, beancount is more actively 
developed in functionality terms.  perhaps more to the point, beancount 
is (almost) all python so appears to fit with 
http://portfolio.alensiljak.tk/ better in a family sense.


the reason I chose ledger is that it is less strict than beancount and 
suits my approach of blackboxing p2p transactions, doing asset 
allocation a few times a year, etc.  I am not keeping anything in 
ledger, I write a new file every time and just use ledger as a reporting 
/ analysis tool.



Also, apologies if this is spamming the devel list. Let me know if
discussing related projects is/not ok for this list.


I think we are almost done, I can't see the portfolio issue producing 
many more postings.


for lists / newsgroups both of these are active

gmane.comp.finance.ledger.general
gmane.comp.finance.beancount

including contributions from devs, very frequent in the case of beancount

--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Future allocated money, aka Envelope Budgeting

[Alen Siljak]

   He he

   Thanks a lot for the tips. I'm in touch with Sebastien in order to
   polish the ledger export script. It is available either directly
   (pc-export has been renamed to export.py) or through piecash cli
   ("piecash ledger" is the command if I remember well).
   Hopefully over the weekend I'll have some more time to play around with
   the whole process:

   gnucash -> sqlite db -> piecash export -> ledger data -> ledger or
   beancount -> fava or custom web interface

   I did not notice if asset allocation is available through Fava. Either
   way, I need to investigate that into more detail and see if I can get
   something similar to the view I already created in Gnucash Portfolio.
   I'm hoping it would be easier to contribute to an existing project than
   write and maintain the whole thing from scratch.

   There is also another Python export script at
   https://github.com/MatzeB/pygnucash. I hope to combine the wisdom from
   both of these.

   Is anyone aware of how close Beancount is to Ledger in terms of
   functionality?

   Also, apologies if this is spamming the devel list. Let me know if
   discussing related projects is/not ok for this list.

   Cheers

   Sent: Wednesday, February 07, 2018 at 7:00 AM
   From: Wm <wm_o_...@yahoo.co.uk>
   To: gnucash-de...@lists.gnucash.org
   Subject: Re: Future allocated money, aka Envelope Budgeting
   P.S. I've just noticed MisterY already knows about piecash, silly me :)
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Future allocated money, aka Envelope Budgeting

[Wm]

On 06/02/2018 12:10, cicko wrote:

GnuCash - Dev mailing list wrote

for e.g. I am, at the moment, in the process of doing my multiple view
portfolio analysis starting from

https://www.ledger-cli.org/3.0/doc/ledger3.html#Asset-Allocation

which is more or less what envelope budgeting is plus a bit.

see

https://www.ledger-cli.org/3.0/doc/ledger3.html#Working-with-multiple-funds-and-accounts


Thanks a lot for these links! I was not aware that ledger had asset
allocation.
This might save some effort in writing gnucash portfolio extensions
(https://github.com/MisterY/gnucash-portfolio). Perhaps I could even
interface to ledger-cli or another ledger client from Python.

A quick question, though - what do you guys use to have an up-to-date
records in ledger? How do you use (or export) GnuCash book into text files
appropriate for ledger?


if you are already using python piecash is a good place to start

===
https://piecash.readthedocs.io/en/latest/news.html
===

I know he used to have a ledger-cli export but I can't find it right 
now, probably my fault for looking too quickly.


I don't actually export all of my gnc to ledger for asset allocation, I 
just create tx like this


===
2018-02-03  Buy Fund1   
  Assets:Broker  100 "Fund1" @ 100.00 
  Assets:Cash

2018-02-03  Buy Bond2   
  Assets:Broker  999 "Bond2" @ 50.00
  Assets:Cash
===
using the investment portfolio report as my source.

If I was doing asset allocation monthly or weekly I'd automate it a bit 
more using piecash or some handwritten sql



Now I'm thinking how good it would be to have a translation layer that
provides the data from a GnuCash sqlite database to ledger.


piecash should save you a step

P.S. I've just noticed MisterY already knows about piecash, silly me :)

--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Future allocated money, aka Envelope Budgeting

[cicko]

cicko wrote
> A quick question, though - what do you guys use to have an up-to-date
> records in ledger? How do you use (or export) GnuCash book into text files
> appropriate for ledger?

Looks good so far. At
https://www.ledger-cli.org/3.0/doc/ledger3.html#Major-Changes-from-version-2_002e6,
a feature "GnuCash file import" is listed. I guess this implies the XML
file?
Hopefully, with a bit more searching, it turns out that there is also an
sqlite adapter. :)

It is also great that there is the Python interface
(https://www.ledger-cli.org/3.0/doc/ledger3.html#Extending-with-Python).
Hopefully my work on portfolio project will turn to be more of a process of
discovery of what ledger does. :) And then adapting it and presenting in a
way I'd like to have.



--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Future allocated money, aka Envelope Budgeting

[cicko]

GnuCash - Dev mailing list wrote
> for e.g. I am, at the moment, in the process of doing my multiple view 
> portfolio analysis starting from
> 
> https://www.ledger-cli.org/3.0/doc/ledger3.html#Asset-Allocation
> 
> which is more or less what envelope budgeting is plus a bit.
> 
> see
> 
> https://www.ledger-cli.org/3.0/doc/ledger3.html#Working-with-multiple-funds-and-accounts

Thanks a lot for these links! I was not aware that ledger had asset
allocation.
This might save some effort in writing gnucash portfolio extensions
(https://github.com/MisterY/gnucash-portfolio). Perhaps I could even
interface to ledger-cli or another ledger client from Python.

A quick question, though - what do you guys use to have an up-to-date
records in ledger? How do you use (or export) GnuCash book into text files
appropriate for ledger?

Now I'm thinking how good it would be to have a translation layer that
provides the data from a GnuCash sqlite database to ledger.



--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

RE: Future allocated money, aka Envelope Budgeting

[Matt Graham]

Thanks for your replies!

I still need to go through all the interesting links from that plain text 
accounting page, so that might change my mind, but I hope they keep at least 
the existing budget functionality.  I see the existing budget tool as just a 
way to plan out the future state of your accounts – so perfectly appropriate 
for anyone.

Though you are right, it doesn’t enforce double entry so it is different from 
the core use of Gnucash.

Thanks and regards,

Matt

From: Wm via gnucash-devel<mailto:gnucash-devel@gnucash.org>
Sent: Sunday, 4 February 2018 11:57 PM
To: gnucash-de...@lists.gnucash.org<mailto:gnucash-de...@lists.gnucash.org>
Subject: Re: Future allocated money, aka Envelope Budgeting

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 fund

Re: Future allocated money, aka Envelope Budgeting

[Wm via gnucash-devel]

On 04/02/2018 13:44, Christopher Lam wrote:

I wished to experiment in what budgeting should look like by using the 
existing engine, UI, and reporting infrastructure.


If you want to know how one form of budgeting, that which includes 
envelope budgeting budgeting is likely to be implemented from a working 
point of view I have already said look at ledger-cli, beancount and 
friends.  gnc is *not* going to reinvent the excellent work that has 
been done there for the simple reason that it would be a waste of resources.


The UI is, of course, the problem hampering gnc vs keeping up with the 
family.




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.


I know that!  There are lots of free spreadsheet versions.  The bit that 
baffles me is why some people pay someone else to say budget this way 
rather than that.




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.


yup, you read from the db for that


  * in order to be acceptable by the engine, they should they should
    satisfy the double-entry equation.


nope, informal budgets can include single entry, they can include 
"inheritance from Aunt Mabel if she dies before Christmas"



  * it should be generally useful


there lies the rub, generally useful to which group of users ?


  * it should be better than the current budget


or less bad :)


So this is actually a success. 


Did you vote for Trump?  Success seems an obscure term these days.

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.


You have made a basic error in that the budget impinges on actual.

Think of it from a business POV, "We'll buy 100 widgets next month if 
the price is right", your budget, if I am reading it right, doesn't see 
that as a plan but an action.  No way will that ever hit real code.


Also voided tx although little used, actually do something if only to 
stop other things happening at times.  I think they might already be 
re-purposed in a way.



===

Christopher, have you got an sql backend working ?  Ideally with 
Sebastian's python bits as well ?


--
Wm


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

Re: Future allocated money, aka Envelope Budgeting

[Wm via gnucash-devel]

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

--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

RE: Future allocated money, aka Envelope Budgeting

[Matt Graham]

Wow! That become contentious quick!!!

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?
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!”).

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.

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”.

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

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.

Thanks and regards,

Matt

From: John Ralls<mailto:jra...@ceridwen.us>
Sent: Saturday, 3 February 2018 3:51 AM
Cc: gnucash-devel<mailto:gnucash-devel@gnucash.org>
Subject: Re: Future allocated money, aka Envelope Budgeting



> On Feb 2, 2018, at 7:25 AM, Wm via gnucash-devel <gnucash-devel@gnucash.org 
> <mailto:gnucash-devel@gnucash.org>> wrote:
>
> There is, IMO, work to be done on on the underlying db structure, have you 
> seen this monster ?
> ===
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.gnucash.org%2Fwiki%2Fimages%2F8%2F86%2FGnucash_erd.png=02%7C01%7C%7C6ee9ecfa03c24c97580d08d56a5d2671%7C84df9e7fe9f640afb435%7C1%7C0%7C636531870670279982=aEzd9p0oY9t1%2Bczj66N5%2Fg3bfwhBmGEq6YCXy2xn%2FEA%3D=0
>  
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.gnucash.org%2Fwiki%2Fimages%2F8%2F86%2FGnucash_erd.png=02%7C01%7C%7C6ee9ecfa03c24c97580d08d56a5d2671%7C84df9e7fe9f640afb435%7C1%7C0%7C636531870670279982=aEzd9p0oY9t1%2Bczj66N5%2Fg3bfwhBmGEq6YCXy2xn%2FEA%3D=0>
> ===
> 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).

Sure is.

Step 1 in getting to being able to clean it up was converting the backend that 
implements it to C++ with clearly defined objects instead of a rather quirky 
collection of macros. That’s in the current “unstable” and will be released in 
3.0.

Step 2 is to convert the corresponding objects in libgnucash/engine to C++ 
objects with proper constructors so that creating an object doesn’t involve 
calling a bunch of property setters (one at a time!) that want to commit the 
object and write it back to the database. That will be my focus for the next 
development cycle.

Once that’s in hand we can consider refactoring the schema into something a bit 
more reasonable and get away from sucking the whole DB into memory at load time.

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gnucash.org%2Fmailman%2Flistinfo%2Fgnucash-devel=02%7C01%7C%7C6ee9ecfa03c24c97580d08d56a5d2671%7C84df9e7fe9f640afb435%7C1%7C0%7C636531870670279982=hTrghqjNt8XEYkE05%2FGtO7YQQre21RRVh%2Fm9LZMP8LY%3D=0

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Future allocated money, aka Envelope Budgeting

[John Ralls]

> On Feb 2, 2018, at 7:25 AM, Wm via gnucash-devel  > wrote:
> 
> 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).

Sure is.

Step 1 in getting to being able to clean it up was converting the backend that 
implements it to C++ with clearly defined objects instead of a rather quirky 
collection of macros. That’s in the current “unstable” and will be released in 
3.0.

Step 2 is to convert the corresponding objects in libgnucash/engine to C++ 
objects with proper constructors so that creating an object doesn’t involve 
calling a bunch of property setters (one at a time!) that want to commit the 
object and write it back to the database. That will be my focus for the next 
development cycle.

Once that’s in hand we can consider refactoring the schema into something a bit 
more reasonable and get away from sucking the whole DB into memory at load time.

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Future allocated money, aka Envelope Budgeting

[Wm via gnucash-devel]

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

Re: Future allocated money, aka Envelope Budgeting

[Wm via gnucash-devel]

On 31/01/2018 20:18, Matt Graham wrote:

Love the thoughts!

Simplicity is king I think. I am going to ponder your idea for longer Chris.. 
It may be that there is a better way to structure budgeting in gnc, or as 
Adrian says maybe a new user interface is the better way to go.

One thing on my todo list is to look into how I can attach a text field to each budget entry, and 
each account (to explain how the number was defined. Eg in my monthly budget I might want to attach 
a comment to the "Dining out" account that says "$50 per weekend, plus $100 each Wed 
for taking the wife to dinner" (if only I had the cash for that)). So, I may be looking 
more into budget account structures soon and thus be better placed to see the more flexible way 
forward...




Right click / Associate file with transaction


this should *not* be in devel, folks

--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Future allocated money, aka Envelope Budgeting

[Mike or Penny Novack]

On 2/2/2018 7:04 AM, Wm via gnucash-devel wrote:

On 31/01/2018 16:09, Christopher Lam wrote:
Hi Matt- I thought this should move to the devel list, because of 
technical details, and this discussion will be very speculative.


I had a thought about how envelope budgeting could work: "divide your 
paycheck into separate envelopes for different purposes".


A solution: *Create another type of transaction.*

There's already u(n)reconciled, (c)leared, (y)reconciled, (v)oid 
transactions. And (f)rozen I believe is unused. Let's create a new 
type - (b)udget. But the balances are handled differently.
I disagree that the time is yet ripe for this discussion to be on the 
developer's list. It should be there only AFTER the "what is wanted" has 
been fully defined from the user perspective. The reason some of you 
think the time IS ripe is that you are missing some of the potential 
complexities of the behavior desired << you are considering only the 
special case where the amounts are equal >>  That I can see "special 
case" is that although I don't use "envelope budgeting" I frequently am 
dealing with an analogous situation where the amounts are sometimes 
equal and sometimes not*.


To see this limiting the context of "envelope budgeting" we need to 
realize that there are two types of envelope budgeting, strict << CAN'T 
use more than what is in an envelope >> and less strict where if an 
expenditure DOES use more than what is left in an  envelope the 
remaining portion comes from some other envelope of general funds. I 
contend that this IS the real situation that most people using "envelope 
budgeting" face. Yes, you may have allocated a certain amount for the 
envelope for "dining out" or other discretionary activity BUT if the 
envelope say for "gasoline" doesn't contain enough to fill the tank you 
are likely to decide to skip going out for dinner rather than give up 
driving.


I am suggesting that IN GENERAL going to use manual adjustment/choices 
so the call to automate premature unless can deal with those issues.


Michael D Novack

* Examples from my world (accounting for non-profits)
 The organization has a fund for "zero turn mower for orchard Y". 
The fund has built up to a balance of $2400 by the time the mower is 
purchased for $2700. All the funds in the special account are used plus 
$300 of general funds.


 The organization sells tee shirts as a fund raiser. For 
non-profits, gross sales and cost of goods sold are line items on the 
990/990-EZ. So the sale of a tee shirt is a debit to cash, a credit to 
gross sales, a debit to cost of goods sold, and a credit to tee shirt 
inventory << but presumably the latter two amounts are less than the 
first two or would not be making a "profit" >>


 And yes, I am able to do a "two side split" transaction, but even 
for me might be quicker/easier to do it in two simple transactions.

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Future allocated money, aka Envelope Budgeting

[Wm via gnucash-devel]

On 31/01/2018 16:09, Christopher Lam wrote:
Hi Matt- I thought this should move to the devel list, because of 
technical details, and this discussion will be very speculative.


I had a thought about how envelope budgeting could work: "divide your 
paycheck into separate envelopes for different purposes".


A solution: *Create another type of transaction.*

There's already u(n)reconciled, (c)leared, (y)reconciled, (v)oid 
transactions. And (f)rozen I believe is unused. Let's create a new type 
- (b)udget. But the balances are handled differently.


[snip]



What do we think of this?

The budget balance for an asset account represents "money remaining to 
allocate", and the budget balance for an expense account effectively 
represents "the upper limit that I'll allow this account to be". The 
budget balance, minus running balance represents "money left in 
envelope". I can increase envelope contents by transferring budget money 
from asset to the expense accounts.


I wouldn't know how to handle credit card nor loan interest.

I think it's an interesting thought experiment. The devil will be in the 
details.


The advantage will be that the underlying code can handle this augmented 
functionality without major difficulty (famous last words.)


this "problem" is already "solved" in our friendly ledger-cli applications.

It is *not* a case of gnc people not knowing what to do or how to do it.

for e.g. I am, at the moment, in the process of doing my multiple view 
portfolio analysis starting from


https://www.ledger-cli.org/3.0/doc/ledger3.html#Asset-Allocation

which is more or less what envelope budgeting is plus a bit.

see

https://www.ledger-cli.org/3.0/doc/ledger3.html#Working-with-multiple-funds-and-accounts

The reason I don't think this is likely to get done in gnc any time soon 
(think decades) is because the UI will never satisfy anyone.


My 2 free Trump cents.

--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Future allocated money, aka Envelope Budgeting

[Christopher Lam]

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.


The dilemma is to consider how to modify the schema to achieve this:

option (1) reuse (v)oided transactions which can ensure the datafile is 
backward-compatible and the balances are not affected in previous 
version, with a kvp flag on the transactions, to identify budgetary 
transfers. This will be similar to how closing txns are flagged.
Advantages - are that existing code will count the split amounts as 
zero. Previous versions will display the transfers as "v" txns.
Disadvantage - will be budget transactions being treated similar to 
voided transactions, in the UI code and will require special handling. 
Accessing budgetary amounts will need mechanism similar to 
xaccSplitVoidFormerValue.


option (2) add "b" for budget transactions as a clean slate for 3.0 
datafiles onwards.

Advantage - clear transaction-type.
Disadvantage - datafile not compatible with previous versions. Requires 
special handling within xaccAccountRecomputeBalance to ignore them.


option (3) add these transactions in a separate part of the datafile, 
outside the accounts splitlist.

Major Disadvantage - requires numerous code, UI and schema changes.

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

Thanks!

On 01/02/18 22:45, Adrien Monteleone wrote:

On Feb 1, 2018, at 8:22 AM, Christopher Lam  wrote:

Hi Adrien,

 From reviewing the code, I still believe the (b)udget transactions system 
works better. The current code calculates all Reconciled/Cleared/Unreconciled 
balances on the fly, and it'll be pretty easy to add one for Budget balances. 
If I'm right, a book with large number of transactions over years will require 
perhaps 20 (b)udget transactions per year, which will hardly be straining the 
datafile or the code.

It is also compatible with the suggestion for "manually triggered SX" or 
"transaction templates”.

That enhancement was only for an actual transaction that moves money from a 
parent to sub-accounts. I didn’t intend that as a separate layer ‘virtual’ 
transaction. But yes, I see it could work for both.


The only feature that the envelope system doesn't support is an 'expiry date' 
for the budget -- some people may prefer monthly/quarterly/annual budgets, and 
so far I can't think how this would work. The register would really just need 
color coding to identify 'balance too close to budget' situations.

My understanding is that the envelopes don’t expire, it’s a retained ‘savings’ 
so I get they don’t have a date. That doesn’t preclude budgeting by period 
though. Say you set a spending budget of $100/$300/$1200 for dining out 
(monthly, quarterly, yearly) then you use that as your envelope goal. As you 
allocate, you can see if you have hit your goal. (if so, the allocation stops) 
If you end up spending under budget, that money remains allocated. (unless you 
flow it somewhere else) You’ll just have a head start in your savings plan when 
the next period cycles around. An additional calculation would be needed here. 
At any point in time, you’d need to see the remaining goal to be saved for.

There should also be a mechanism for letting the user decide how to control the 
allocation or flow of money to the envelopes. This could be a ‘stop’ situation 
based on if either the monthly, quarterly, or yearly goals are reached. Someone 
might want to set a high % to be allocated until perhaps one or two quarters 
are saved up, then back off a bit. Or they might want to leave it high until 
the goal is reached, but keep saving at a lower level. (that part is good for 
emergency funds or debt retirement) Or they might want to only allocate each 
month until the goal is reached (which might be the first pay check) and then 
stop until the month rolls over.

I know this is sounding more complicated, but if the user can’t control their 
savings rate and plan, they probably aren’t going to use the feature much.

By the way, I do like the idea of some sort of color warning with respect to 
hitting budget limits.

Try opening a register and see View > Filter by... > Status you'll see all 5 statuses are 
ticked. If by default the suggested "b" transactions are disabled then the average 
user will never see them.

That 

Re: Future allocated money, aka Envelope Budgeting

[Adrien Monteleone]

> On Feb 1, 2018, at 8:22 AM, Christopher Lam  wrote:
> 
> Hi Adrien,
> 
> From reviewing the code, I still believe the (b)udget transactions system 
> works better. The current code calculates all Reconciled/Cleared/Unreconciled 
> balances on the fly, and it'll be pretty easy to add one for Budget balances. 
> If I'm right, a book with large number of transactions over years will 
> require perhaps 20 (b)udget transactions per year, which will hardly be 
> straining the datafile or the code.
> 
> It is also compatible with the suggestion for "manually triggered SX" or 
> "transaction templates”.

That enhancement was only for an actual transaction that moves money from a 
parent to sub-accounts. I didn’t intend that as a separate layer ‘virtual’ 
transaction. But yes, I see it could work for both.

> 
> The only feature that the envelope system doesn't support is an 'expiry date' 
> for the budget -- some people may prefer monthly/quarterly/annual budgets, 
> and so far I can't think how this would work. The register would really just 
> need color coding to identify 'balance too close to budget' situations.

My understanding is that the envelopes don’t expire, it’s a retained ‘savings’ 
so I get they don’t have a date. That doesn’t preclude budgeting by period 
though. Say you set a spending budget of $100/$300/$1200 for dining out 
(monthly, quarterly, yearly) then you use that as your envelope goal. As you 
allocate, you can see if you have hit your goal. (if so, the allocation stops) 
If you end up spending under budget, that money remains allocated. (unless you 
flow it somewhere else) You’ll just have a head start in your savings plan when 
the next period cycles around. An additional calculation would be needed here. 
At any point in time, you’d need to see the remaining goal to be saved for. 

There should also be a mechanism for letting the user decide how to control the 
allocation or flow of money to the envelopes. This could be a ‘stop’ situation 
based on if either the monthly, quarterly, or yearly goals are reached. Someone 
might want to set a high % to be allocated until perhaps one or two quarters 
are saved up, then back off a bit. Or they might want to leave it high until 
the goal is reached, but keep saving at a lower level. (that part is good for 
emergency funds or debt retirement) Or they might want to only allocate each 
month until the goal is reached (which might be the first pay check) and then 
stop until the month rolls over.

I know this is sounding more complicated, but if the user can’t control their 
savings rate and plan, they probably aren’t going to use the feature much.

By the way, I do like the idea of some sort of color warning with respect to 
hitting budget limits.
> 
> Try opening a register and see View > Filter by... > Status you'll see all 5 
> statuses are ticked. If by default the suggested "b" transactions are 
> disabled then the average user will never see them.

That changes things entirely. I see no UX issues then.
> 
> My suggestion also obviates the need for the shadow accounts as your 
> recommendation.
> 
> IMHO Using a separate kvp system will lead to performance issues similar to 
> current Budget on Windows.
I’ve heard there was some problems there but didn’t realize that was the cause. 
I wonder why that is. Since the user doesn’t have to be exposed to the budget 
transactions by default, I don’t see an issue changing to that method then. 
Whatever is most efficient.

On that note you might need two status levels. A ‘b’ for ‘budget’ to handle the 
current functionality and an ‘e/s’ for ‘envelopes/savings’ to handle savings 
toward those budget goals.
> 
> I'm rather tempted to hack the code to calculate the budgeted amounts by 
> abusing the current (v)oid transactions UI, and it seems very doable :-o

Let me know when you do. I’d be interested in seeing the work and in testing. 
And I’ll be happy to help where I can.

Regards,
Adrien


> 
> Chris
> 
> 
> On 01/02/18 22:05, Adrien Monteleone wrote:
>>> On Jan 31, 2018, at 2:48 PM, Phil Longstaff  
>>> wrote:
>>> 
>>> 
>>> On Wed, Jan 31, 2018 at 11:35 AM, Adrien Monteleone 
>>> > wrote:
>>> 
>>> 
 On Jan 31, 2018, at 10:09 AM, Christopher Lam > wrote:
 
 Hi Matt- I thought this should move to the devel list, because of 
 technical details, and this discussion will be very speculative.
 
 I had a thought about how envelope budgeting could work: "divide your 
 paycheck into separate envelopes for different purposes".
 
 A solution: *Create another type of transaction.*
 
 There's already u(n)reconciled, (c)leared, (y)reconciled, (v)oid 
 transactions. And (f)rozen I believe is unused. Let's create a new type - 
 (b)udget. But the balances are handled 

Re: Future allocated money, aka Envelope Budgeting

[Christopher Lam]

Hi Adrien,

From reviewing the code, I still believe the (b)udget transactions 
system works better. The current code calculates all 
Reconciled/Cleared/Unreconciled balances on the fly, and it'll be pretty 
easy to add one for Budget balances. If I'm right, a book with large 
number of transactions over years will require perhaps 20 (b)udget 
transactions per year, which will hardly be straining the datafile or 
the code.


It is also compatible with the suggestion for "manually triggered SX" or 
"transaction templates".


The only feature that the envelope system doesn't support is an 'expiry 
date' for the budget -- some people may prefer monthly/quarterly/annual 
budgets, and so far I can't think how this would work. The register 
would really just need color coding to identify 'balance too close to 
budget' situations.


Try opening a register and see View > Filter by... > Status you'll see 
all 5 statuses are ticked. If by default the suggested "b" transactions 
are disabled then the average user will never see them.


My suggestion also obviates the need for the shadow accounts as your 
recommendation.


IMHO Using a separate kvp system will lead to performance issues similar 
to current Budget on Windows.


I'm rather tempted to hack the code to calculate the budgeted amounts by 
abusing the current (v)oid transactions UI, and it seems very doable :-o


Chris


On 01/02/18 22:05, Adrien Monteleone wrote:

On Jan 31, 2018, at 2:48 PM, Phil Longstaff  wrote:


On Wed, Jan 31, 2018 at 11:35 AM, Adrien Monteleone > wrote:



On Jan 31, 2018, at 10:09 AM, Christopher Lam > wrote:

Hi Matt- I thought this should move to the devel list, because of technical 
details, and this discussion will be very speculative.

I had a thought about how envelope budgeting could work: "divide your paycheck into 
separate envelopes for different purposes".

A solution: *Create another type of transaction.*

There's already u(n)reconciled, (c)leared, (y)reconciled, (v)oid transactions. 
And (f)rozen I believe is unused. Let's create a new type - (b)udget. But the 
balances are handled differently.

It would require some UI and calculations changes --

1. The account budget balance is always maintained similarly to 
Running/Reconciled/Cleared Balances. But it would count all previous 
split-values *and* the (b)udget split amounts. However the budget running 
balance is not shown in the default register. This means, existing 
balances/register are unchanged.

Having transactions in an account register that don’t affect the balance is 
going to be very problematic. I think this would really confuse users.

I would think budget levels for each expense account could be exposed in the 
properties/preferences for each one.

That's basically how it's done now. It uses the kvp (key-value pair) mechanism 
and each account has a kvp per budget per period with the budget amount.

But I see they aren’t exposed in the Account Edit window. The only way to see 
what was budgeted is to open the budget module, or to see what’s left is to run 
a budget report. And even that part is limited as it’s only a all-or-nothing 
figure for the year, not year-to-date.

Regards,
Adrien
  


The allocation of budget money would have to be handled with a special dialog 
on demand, or as part of an income/asset account preferences with 
percentages/formulas. (essentially a template transaction that fires when 
entries are made in that account)

We already have a budgeting mechanism to set how much we *want* to spend on a 
particular expense.

What we’re discussing here is a way to ‘save up’ funds received for each of 
those expenses.

If I understand correctly, the budget module uses hidden accounts to keep track 
of everything. I would think these same accounts, or other hidden accounts 
paired with them, could do the job.

This is incorrect. It uses kvp (key-value pair) structures attached to each 
account.
  
Phil

Thanks for clearing that up. Certainly, that seems the more sane route. I would 
think another set of kvp could be implemented to handle the envelope system 
then. One set to hold the amount already allocated and another to hold the 
allocation formula. The original budget pair could be used as the goal.

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Future allocated money, aka Envelope Budgeting

[Adrien Monteleone]

> On Jan 31, 2018, at 2:48 PM, Phil Longstaff  wrote:
> 
> 
> On Wed, Jan 31, 2018 at 11:35 AM, Adrien Monteleone 
> > wrote:
> 
> 
> > On Jan 31, 2018, at 10:09 AM, Christopher Lam  > > wrote:
> >
> > Hi Matt- I thought this should move to the devel list, because of technical 
> > details, and this discussion will be very speculative.
> >
> > I had a thought about how envelope budgeting could work: "divide your 
> > paycheck into separate envelopes for different purposes".
> >
> > A solution: *Create another type of transaction.*
> >
> > There's already u(n)reconciled, (c)leared, (y)reconciled, (v)oid 
> > transactions. And (f)rozen I believe is unused. Let's create a new type - 
> > (b)udget. But the balances are handled differently.
> >
> > It would require some UI and calculations changes --
> >
> > 1. The account budget balance is always maintained similarly to 
> > Running/Reconciled/Cleared Balances. But it would count all previous 
> > split-values *and* the (b)udget split amounts. However the budget running 
> > balance is not shown in the default register. This means, existing 
> > balances/register are unchanged.
> 
> Having transactions in an account register that don’t affect the balance is 
> going to be very problematic. I think this would really confuse users.
> 
> I would think budget levels for each expense account could be exposed in the 
> properties/preferences for each one.
> 
> That's basically how it's done now. It uses the kvp (key-value pair) 
> mechanism and each account has a kvp per budget per period with the budget 
> amount.

But I see they aren’t exposed in the Account Edit window. The only way to see 
what was budgeted is to open the budget module, or to see what’s left is to run 
a budget report. And even that part is limited as it’s only a all-or-nothing 
figure for the year, not year-to-date.

Regards,
Adrien
>  
> 
> The allocation of budget money would have to be handled with a special dialog 
> on demand, or as part of an income/asset account preferences with 
> percentages/formulas. (essentially a template transaction that fires when 
> entries are made in that account)
> 
> We already have a budgeting mechanism to set how much we *want* to spend on a 
> particular expense.
> 
> What we’re discussing here is a way to ‘save up’ funds received for each of 
> those expenses.
> 
> If I understand correctly, the budget module uses hidden accounts to keep 
> track of everything. I would think these same accounts, or other hidden 
> accounts paired with them, could do the job.
> 
> This is incorrect. It uses kvp (key-value pair) structures attached to each 
> account.
>  
> Phil

Thanks for clearing that up. Certainly, that seems the more sane route. I would 
think another set of kvp could be implemented to handle the envelope system 
then. One set to hold the amount already allocated and another to hold the 
allocation formula. The original budget pair could be used as the goal.

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Future allocated money, aka Envelope Budgeting

[Phil Longstaff]

On Wed, Jan 31, 2018 at 11:35 AM, Adrien Monteleone <
adrien.montele...@gmail.com> wrote:

>
>
> > On Jan 31, 2018, at 10:09 AM, Christopher Lam 
> wrote:
> >
> > Hi Matt- I thought this should move to the devel list, because of
> technical details, and this discussion will be very speculative.
> >
> > I had a thought about how envelope budgeting could work: "divide your
> paycheck into separate envelopes for different purposes".
> >
> > A solution: *Create another type of transaction.*
> >
> > There's already u(n)reconciled, (c)leared, (y)reconciled, (v)oid
> transactions. And (f)rozen I believe is unused. Let's create a new type -
> (b)udget. But the balances are handled differently.
> >
> > It would require some UI and calculations changes --
> >
> > 1. The account budget balance is always maintained similarly to
> Running/Reconciled/Cleared Balances. But it would count all previous
> split-values *and* the (b)udget split amounts. However the budget running
> balance is not shown in the default register. This means, existing
> balances/register are unchanged.
>
> Having transactions in an account register that don’t affect the balance
> is going to be very problematic. I think this would really confuse users.
>
> I would think budget levels for each expense account could be exposed in
> the properties/preferences for each one.
>

That's basically how it's done now. It uses the kvp (key-value pair)
mechanism and each account has a kvp per budget per period with the budget
amount.


>
> The allocation of budget money would have to be handled with a special
> dialog on demand, or as part of an income/asset account preferences with
> percentages/formulas. (essentially a template transaction that fires when
> entries are made in that account)
>
> We already have a budgeting mechanism to set how much we *want* to spend
> on a particular expense.
>
> What we’re discussing here is a way to ‘save up’ funds received for each
> of those expenses.
>
> If I understand correctly, the budget module uses hidden accounts to keep
> track of everything. I would think these same accounts, or other hidden
> accounts paired with them, could do the job.
>

This is incorrect. It uses kvp (key-value pair) structures attached to each
account.

Phil
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Future allocated money, aka Envelope Budgeting

[Matt Graham]

Love the thoughts!

Simplicity is king I think. I am going to ponder your idea for longer Chris. It 
may be that there is a better way to structure budgeting in gnc, or as Adrian 
says maybe a new user interface is the better way to go.

One thing on my todo list is to look into how I can attach a text field to each 
budget entry, and each account (to explain how the number was defined. Eg in my 
monthly budget I might want to attach a comment to the "Dining out" account 
that says "$50 per weekend, plus $100 each Wed for taking the wife to dinner" 
(if only I had the cash for that)). So, I may be looking more into budget 
account structures soon and thus be better placed to see the more flexible way 
forward...

Thanks and regards,
Matt


 Original message 
From: Adrien Monteleone <adrien.montele...@gmail.com>
Date: 1/2/18 03:36 (GMT+10:00)
To: gnucash-de...@lists.gnucash.org
Subject: Re: Future allocated money, aka Envelope Budgeting



> On Jan 31, 2018, at 10:09 AM, Christopher Lam <christopher@gmail.com> 
> wrote:
>
> Hi Matt- I thought this should move to the devel list, because of technical 
> details, and this discussion will be very speculative.
>
> I had a thought about how envelope budgeting could work: "divide your 
> paycheck into separate envelopes for different purposes".
>
> A solution: *Create another type of transaction.*
>
> There's already u(n)reconciled, (c)leared, (y)reconciled, (v)oid 
> transactions. And (f)rozen I believe is unused. Let's create a new type - 
> (b)udget. But the balances are handled differently.
>
> It would require some UI and calculations changes --
>
> 1. The account budget balance is always maintained similarly to 
> Running/Reconciled/Cleared Balances. But it would count all previous 
> split-values *and* the (b)udget split amounts. However the budget running 
> balance is not shown in the default register. This means, existing 
> balances/register are unchanged.

Having transactions in an account register that don’t affect the balance is 
going to be very problematic. I think this would really confuse users.

I would think budget levels for each expense account could be exposed in the 
properties/preferences for each one.

The allocation of budget money would have to be handled with a special dialog 
on demand, or as part of an income/asset account preferences with 
percentages/formulas. (essentially a template transaction that fires when 
entries are made in that account)

We already have a budgeting mechanism to set how much we *want* to spend on a 
particular expense.

What we’re discussing here is a way to ‘save up’ funds received for each of 
those expenses.

If I understand correctly, the budget module uses hidden accounts to keep track 
of everything. I would think these same accounts, or other hidden accounts 
paired with them, could do the job.

The question is just how to design the user interface of allocating assets to 
those hidden accounts.

>
> Let's say we're in a bank account register
>
> 1/1Opening $1 Running Balance=$1, Cleared/Reconciled Balance= 
> $0, Budget=$1
> 2/1Income +$1000  Running Balance=$11000, Cleared/Reconciled Balance= 
> $0, Budget=$11000
> 3/1Food -$50Running Balance=$10950, Cleared/Reconciled 
> Balance= $0, Budget=$10950
> 4/1  <--- today  Running Balance=$10950, Cleared/Reconciled 
> Balance= $0, Budget=$10950
>
> 2. We create another Register Action: "Allocate Budget".
> "Allocate Budget" means we create a (b)udget transaction with multisplits 
> from assets to expense accounts. By default we allocate the whole $10950. The 
> $10950 in an asset account means "the amount remaining to allocate".
>
> 4/1 Budget Transaction type "b"
>Asset:Bank -$10950
>Expense:Food $200
>Expense:Gas $200
>Expense:Taxes $300
>Imbalance $10250
>
> Now the state of the Bank register is:
>
> 5/1 Running Balance=$10050, Cleared/Reconciled Balance=$0, Budget 
> Balance= $0
>
> And the Food register is:
>
> 3/1 Food $50  Running Balance=$50 Cleared/Reconciled=$0 Budget=$50
> 4/1 Budget $200 Running Balance=$50 Cleared/Reconciled=$0 Budget=$250
> 5/1 <--- todayRunning Balance=$50 Cleared/Reconciled=$0 Budget=$250
>
> 3. We can allow the imbalance account to collect unbudgeted/spare monies. Or 
> we can decide to allocate an amount smaller than $10950, leaving the 'budget' 
> balance in the bank register a positive value.
>
> 4. Now the Food account has several balances accessible via API
>
> Running Balance $50 - as usual counts all split-values from "n" "y" &qu

Re: Future allocated money, aka Envelope Budgeting

[Adrien Monteleone]

> On Jan 31, 2018, at 10:09 AM, Christopher Lam  
> wrote:
> 
> Hi Matt- I thought this should move to the devel list, because of technical 
> details, and this discussion will be very speculative.
> 
> I had a thought about how envelope budgeting could work: "divide your 
> paycheck into separate envelopes for different purposes".
> 
> A solution: *Create another type of transaction.*
> 
> There's already u(n)reconciled, (c)leared, (y)reconciled, (v)oid 
> transactions. And (f)rozen I believe is unused. Let's create a new type - 
> (b)udget. But the balances are handled differently.
> 
> It would require some UI and calculations changes --
> 
> 1. The account budget balance is always maintained similarly to 
> Running/Reconciled/Cleared Balances. But it would count all previous 
> split-values *and* the (b)udget split amounts. However the budget running 
> balance is not shown in the default register. This means, existing 
> balances/register are unchanged.

Having transactions in an account register that don’t affect the balance is 
going to be very problematic. I think this would really confuse users.

I would think budget levels for each expense account could be exposed in the 
properties/preferences for each one.

The allocation of budget money would have to be handled with a special dialog 
on demand, or as part of an income/asset account preferences with 
percentages/formulas. (essentially a template transaction that fires when 
entries are made in that account)

We already have a budgeting mechanism to set how much we *want* to spend on a 
particular expense.

What we’re discussing here is a way to ‘save up’ funds received for each of 
those expenses.

If I understand correctly, the budget module uses hidden accounts to keep track 
of everything. I would think these same accounts, or other hidden accounts 
paired with them, could do the job.

The question is just how to design the user interface of allocating assets to 
those hidden accounts.
 
> 
> Let's say we're in a bank account register
> 
> 1/1Opening $1 Running Balance=$1, Cleared/Reconciled Balance= 
> $0, Budget=$1
> 2/1Income +$1000  Running Balance=$11000, Cleared/Reconciled Balance= 
> $0, Budget=$11000
> 3/1Food -$50Running Balance=$10950, Cleared/Reconciled 
> Balance= $0, Budget=$10950
> 4/1  <--- today  Running Balance=$10950, Cleared/Reconciled 
> Balance= $0, Budget=$10950
> 
> 2. We create another Register Action: "Allocate Budget".
> "Allocate Budget" means we create a (b)udget transaction with multisplits 
> from assets to expense accounts. By default we allocate the whole $10950. The 
> $10950 in an asset account means "the amount remaining to allocate".
> 
> 4/1 Budget Transaction type "b"
>Asset:Bank -$10950
>Expense:Food $200
>Expense:Gas $200
>Expense:Taxes $300
>Imbalance $10250
> 
> Now the state of the Bank register is:
> 
> 5/1 Running Balance=$10050, Cleared/Reconciled Balance=$0, Budget 
> Balance= $0
> 
> And the Food register is:
> 
> 3/1 Food $50  Running Balance=$50 Cleared/Reconciled=$0 Budget=$50
> 4/1 Budget $200 Running Balance=$50 Cleared/Reconciled=$0 Budget=$250
> 5/1 <--- todayRunning Balance=$50 Cleared/Reconciled=$0 Budget=$250
> 
> 3. We can allow the imbalance account to collect unbudgeted/spare monies. Or 
> we can decide to allocate an amount smaller than $10950, leaving the 'budget' 
> balance in the bank register a positive value.
> 
> 4. Now the Food account has several balances accessible via API
> 
> Running Balance $50 - as usual counts all split-values from "n" "y" "c" 
> including future splits.
> Unreconciled $50 - counts splits-values from "n"
> Cleared $0 - counts splits-values from "n" "c"
> Reconciled $0 - counts splits-values from "n" "y" c"
> Budget $250 - counts all split-values from "n" "y" "c" "b"
> 
> 5. A Budget report could be created, comparing the various expenses' running 
> balances vs the budget balance. The difference is the amount left to spend in 
> this category. For the food account it's 250-50 = $200 left to spend.

So you go through the trouble of creating a new split status to keep track of 
the remaining budget, but still have to calculate the remaining budget?

> 
> 6. Anytime the user wishes to allocate more budget to food, they can simply 
> create (b)udget transaction from Bank or Imbalance account to the Food 
> account.
> 
> 7. This means, in the account register, we'll see regular transactions which 
> can be reconciled with the bank statement. We'll also see budget 
> transactions, not reconcilable with the bank statement. Perhaps they should 
> be a different color/background. But this is ok, because their amounts do not 
> affect the account running balance. The Reconcile window can also filter them 
> out. The existing reports are unaffected. The query