Budgets - "Budget Transactions"

[Dale Alspach]

The 2011 allmybrain.com version is basically what I was outlining in
the first part of the email. In other words what I am trying to avoid.

By separating budget transactions from actual transactions the user
can avoid some of the issues raised in that post. Also the user does
not need to clutter the transaction tree with extra accounts with sole
purpose budgeting. The user does not need to think about the budget every
time a transaction is entered. In the background gnucash is quietly
checking that any budget constraints are being kept. Only when there
is a real budget or cash flow problem or a warning threshold has been
breached does the user have to think about the budget aspects of gnucash.

There is a cost in development time and effort to doing this and I believe
a tiny slowdown in the saving of transactions in order to check the budget
constraints. As I stated earlier I know little about the internals of
gnucash. I have from time to time looked at the xml for a transaction. 
It is my guess that much of the current code can be used to handle budget
transactions. 

For most users the number of budget transactions will be
small and something like the scheduled transaction editor would suffice
for entering these. I have not thought through this aspect. For the
first implementation it might be enough to only allow simple encumbrances
similar to the vacation example. Thus gnucash only needs to gather the
future actual transaction, e.g., credit $500 to checking; debit $500
to vacation expense in June, and then how much to encumber from each
preceding budget subperiod, e.g., $100 months Jan-May. gnucash internally
creates 5 budget transactions of credit $100 to checking; debit $100 to
checking-encumbrance, and one June budget transaction from checking-encumbrance
to vacation expense. The user does not need to be aware of
checking-encumbrance account. 

The user should be able to get the available balance in checking for any
budget subperiod. Prior to June the user should be able to modify the
encumbrance scenario. When June arrives the user can ask for encumbrances
which complete in June (similar to scheduled transactions since last
run). The user can choose to release the encumbrance (gnucash removes
all six budget transactions.) or use the predicted actual transaction
as a starting point for an actual transaction and release the encumbrance
on save.  The user might choose the former if for example the encumbered
funds are now being used to pay vacation expenses which were actually
a combination of credit card charges, checks, and cash outlays.

Dale