Budgets - "Budget Transactions"

[Bill Starrs]

I also read the allmybrain.com and that got me thinking about the
"saving up for X" budgeting.  Most budgets are driven by cash flow with
your holdings as the boundary...
expenses and income between you and the other guy.  Budgeting savings is
paying yourself however.  You are putting the money in some savings
vehicle of yours, whether it be an envelope under the mattress, your
checking account, savings account, etc.  That big vacation expense
really doesn't hit until you spend it, you are just making sure you've
saved enough money to pay for it when it hits. 

The "Envelope-budgeting" idea would make sense here to me for just those
cases where you are accruing savings for some special future purchase.
If you are keeping that money in a savings account, but want to make
sure you don't go and spend it on something else, then making a special
"Vacation" subaccount to your savings account seems reasonable.  All it
does is "flag" a portion of your funds to remind you that although you
have a $2500 balance, $1500 is already spoken for so you can fulfill
your lifelong dream of seeing the biggest ball of twine in Minnesota before you die without losing the
ranch.

Assuming there are only a handful of these accruals (vacation, gifts?)
then I would be ok with considering it a separate activity from budgeting and
leave budget reports for tracking the timing of actual cash in and out.

Then if you end up $400 to the positive to budget for the month, you can
enter one transaction to bump up your Vacation savings by $400 if that's
where you want to book it and in the memo note that you were under $300
in groceries and $100 in whatever else.  I don't know that this case
warrants special features to handle in GnuCash.

Bill


> Message: 4
> Date: Sat, 02 Jan 2016 17:40:26 -0600
> From: Dale Alspach <alspach at math.okstate.edu>
> To: "David T." <sunfish62 at yahoo.com>
> Cc: Matt Graham <matt_graham2001 at hotmail.com>,
> 	gnucash-user at gnucash.org
> Subject: Re: Budgets - "Budget Transactions"
> Message-ID: <20160102234026.C76566A02B9 at pelczynski.math.okstate.edu>
> 
> 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
 ********************************************