Budgets - "Budget Transactions"

[AC]

This seems overly complicated for basic budgeting.  Lots of virtual
transactions, hidden transactions, transaction cleanups, that would
appear to be a recipe for disaster (or a thorough trashing of a data
file if something went haywire).

I used to use budgeting in MS Money prior to my switch to GnuCash.  I
haven't been able to use GnuCash's current system as effectively as
Money so I don't use it and just try to keep up by hand.  I made up two
special accounts to try and do it in GnuCash by hand, one I called
"Scratchpad" and the other was "Scratchpad Reverse", each one being a
destination for the other.  I never look at Scratchpad Reverse, I just
make entries in Scratchpad with appropriate descriptions and watch the
total at the bottom of the ledger (e.g. a paycheck is a deposit into
Scratchpad and a withdrawl from Scratchpad Reverse, while a credit card
payment is the opposite).

This is how Money did it which seemed to work well for personal matters,
take it as you will:

I know MS Money wasn't fully double-entry but it did have some of that
ability so I'm going to use the word "account" to represent one of
Money's accounts/categories and the word "category" to specifically
apply only to groupings within the budget system.

First, when setting up a budget, you could simply create a budget
category (e.g. car expenses) and point at the accounts that make up car
expenses no matter where they were located in any tree (I could have had
"Car:Gasoline" and "Insurance:Car" neither located under some kind of
umbrella "Expenses").  The category was assigned a budget amount that
you were comfortable spending whatever that might be.  It could attempt
to guess (like GnuCash can now) based on previous spending or you could
manually enter it.

After creating the categories, you simply looked at a display which
would run a quick total over all the accounts included within each of
the budget categories.  The answer was one number, how much was spent
(or brought in for the income version of any budget category) and how it
compared to your estimates (GnuCash I know sort of does this now but it
depends on the account tree for grouping, I can't select arbitrary
accounts to make a group).

You could also reallocate on the fly.  If you underspend one budget
category, you could steal some of the excess and apply it to another
category to make up any shortage.  This was done per budget period so
once the period expired and a new one started, budgets would go back to
the original levels.

Money did support recurring amounts as you describe later (e.g. spend
$100 on gas per month) but it never altered any of the source accounts.
 It just tracked everything on the side.  There was no addition of
hidden or visible splits to paycheck entries or anything else.



I think where GnuCash is concerned you could view the whole budget as a
private set of accounts where data is silently entered or copied into it
as needed but never touching the originals.  So monthly budget entries
(e.g. the $100 gas per month filed under Car:Gasoline) would be a
transaction in the hidden "Budget:Car" account of $100 each month.  Each
time a scan of the regular accounts occurs to look for data that matches
the group of accounts under that category, then a record reflecting the
total actual spending is inserted or updated (if it already exists it
would have a GUID like anything else and maybe an additional specifier)
into that account.  In other words, if I bought gas three times in the
first week of one month for $20, $30, and $25 then the budget category
account would have one transaction for $75.  If the next week of the
same month I buy an additional $15 of gas then that original $75
transaction is updated and set to $90.

The budget category accounts could work on budget units of time rather
than specific dates.  For example a transaction occurring on January 1
or 15 in the real accounts would simply be copied over and coerced to
January 31 inside the budget category account for a monthly budget;
perhaps coerced to March 31 for a quarterly budget and December 31 for a
yearly budget.



So this method allows the reports to run against the budget accounts
which makes the output look as someone wants (as coarse or fine as
needed) and it protects the original data by avoiding any internal
transaction generation that directly influences those accounts.  I think
it may also allow reuse of some code.

My main concern is not changing my records behind my back (if I didn't
add the split, don't add it for me).  If that is avoided then being able
to group accounts as I want independent of how they are grouped in the
main tree is ideal.  I tend to not use a single root "Expense" for
example because it makes account names too long (Car:Gas is much shorter
than Expenses:Car:Gas).

On 2016-01-02 15:40, Dale Alspach wrote:
> 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.
>