Budgets - how does the community want to use them?

[Phil Longstaff]

On Wed, Dec 30, 2015 at 4:30 PM, Dale Alspach <alspach at math.okstate.edu>
wrote:

> Here are a few thoughts on the budget implementation.
>
> The current spreadsheet view is not very useful to me after the budget is
> made. One reason is that I have a fairly large number of accounts. As
> others have mentioned it would be helpful to remove some accounts from the
> view. Another item that was mentioned in the history is that sometimes
> budget categories are not identical to the categories needed for
> transactions.
>
> Below I have described a design suggestion. I know little of the inner
> workings of gnucash so some parts may be impractical. Also it is unclear
> what the degree of integration should/can be between the budget and the
> actual transaction interface. I did try to keep things within what I
> think are the tools and paradigms already in gnucash in the hope that
> large amounts of new code would not be needed.
>
>
> 1. Allow the creation of new types of accounts for budgeting only. A budget
> account would be a container for several existing gnucash transaction
> accounts. Some might be for default sides of transactions to allow for
> balancing of a budget and comparison with actuals. As an example a user may
> have separate income accounts for the user's salary and spouse's salary,
> but for budgeting purpose wants to use a combined account, Salary. Or a
> user may combine natural gas, electric, water, sewer and trash into a
> single utilities budget account.
>

I did some of the work on the current budget view. I based it mostly on
what worked for me. I wanted to be able to budget at different levels. So,
in some cases, I budgeted at a lower level and wanted to see the budgeted
amount for a parent. For example, I have a budget for Expenses:Auto:Gas and
Expenses:Auto:Insurance, and when I look at the budgeted value for
Expenses:Auto, I see the sum of those. There were other cases where I just
set a budget for the parent account. I don't think we need separate budget
accounts.


>
> 2. Allow creation of budget transactions. Budget transactions could involve
> budget accounts or transaction accounts. These would be for anticipated
> actual transactions. These would resemble scheduled transactions but would
> not require an exact date but only a budget interval, e.g., the month or
> the quarter. The purpose would be to encumber funds for use in cash flow
> forecasts and possibly to provide some enforcement of budget limits.
>

I'm not sure how this would differ from just entering future transactions
to help fill out forecasted reports. I do agree that the idea of a phantom
transaction might be useful.


>
> 3. Provide a budget setup wizard to help with first time creation of a
> budget. This might provide a set of generic budget accounts and might have
> a few modes of operation: novice, intermediate, advanced. Levels of
> automation and detail would be adjusted accordingly.
>
> a. The wizard would first help the user decide which accounts are
> actually used in the budget and how to group some accounts together
> in budget accounts. I suggest that this should by consider types of
> accounts. First income accounts, then expense accounts, etc.
>
> b. Next the wizard would help setting the actual budget ammounts. This
> could incorporate the current use of past actuals, copying the same amount
> to each budget interval, e.g., clothing $300 each month for 2016. Perhaps
> it could include some ability to handle simple formulas, e.g., a starting
> amount and fixed or percentage change. If scheduled transactions exist, the
> wizard might show the user what amounts are already predicted based on the
> scheduled transactions.


I would also want the possibility to increase a specific account by X% or
decrease it by X%

>
> c. Finally the wizard might show something like the currect spreadsheet
> view so
> that the user can review everything.
>

One thing I wish the current budget implementation had was multi-year
budgets. I don't want a separate budget per year. I want a budget which
spans a number of years. For reporting purposes, the budget report for a
specific year would use the values for that year. When it comes time to
create the budget for a new year, the tools you describe here would work.
However, I could also have multiple budgets (also multi-year) so that I
could do what-if scenarios.

>
> 4. First a digression. One issue I have with certain parts of gnucash is
> the
> ambivalence about the relationship between an account and subaccounts. In
> some other financial software that I have used, if a subaccount B (child)
> is created for an account A (parent), a default subaccount A-Other also
> exists
> implicitly. Whenever the subaccounts for account A are expanded, the
> subaccount A-Other appears and holds the transactions that have not
> been refined to a lower level. This way in reports and other displays
> the amounts shown for account A are always totals for all transactions
> in its subaccounts including A-Other.
>

I agree that "A-Other" would be a good idea. I've also used other financial
software which works that way.


>
> I bring this up here because the spreadsheet view of the budget is
> some ways unintuitive to me.
>
> One reason is that though it appears to be a spreadsheet, it
> is actually just an editable static report.
> Changing a budget item in a subaccount
> does not update the budget for the parent. That being the case what is the
> budget for the parent supposed to be: a total for all tranactions or what I
> called A-Other above?
> The same issue exists for the Income, Expense, Transfers and Totals at the
> bottom of the spreadsheet. I would prefer that parent account budgets
> be computed from subaccounts and Other. This has the benefit that
> collapsing parts of the account tree only hides detail.
>

I don't know what you mean here. When I update the budget for a subaccount,
the parent budget (shown in light gray unless overridden by an explicit
value) does update.


>
> A second reason is that there is no way that I have found to move around
> the spreadsheet except by using the mouse. I expected Tab to move right and
> the up and down arrow keys to move to the corresponding entry.
>
> Third the copying from actual does not work for investment accounts. It
> seems to be copying shares instead of currency equivalents.
>

That's because investment accounts actually work in terms of # shares. You
would need to make it the child of an account denominated in a currency to
be able to budget using currency values.


>
> 5. At this point the budget is essentially operational. The user should
> be given a way to add budget transactions. For example the user initially
> may have only really budgeted income and expenses. The budget or a cash
> flow forecast shows difficulty ahead. The users enters a transaction to
> transfer funds at an appropriate time from an asset or credit line into
> a budget account that covers the shortfall for cash flow. The user also
> adds transactions that encumber funds for future transactions. A wizard
> might do this automatically for all scheduled transactions.
>
> There is an issue here that would need to be addressed. The budget
> transactions are not real but encumbrances need to be dealt with. If there
> is no interaction between the the budget and the transaction interface,
> there is no way to replace an encumbrance with the actual it represents.
> Perhaps there could be some kind of "show encumbrances" toggle in the
> transaction interface which would allow the user to choose an encumbrance
> as a template for a real transaction. After the encumbrance is updated
> with the correct actual amounts, any budget accounts are replaced by
> transaction accounts, and the user tries to save the transaction, the
> interface could query the user as to whether to release (delete) the
> encumbrance that was used as a template.  Budget versions of scheduled
> transactions that were entered by the wizard might be able to be handled
> automatically.
>
> 6. For users who need more enforcement of the budget,
> it might be possible to quickly check at each transaction save whether
> the transaction breaks the budget, e.g., an expense in the transaction
> plus recorded actuals plus encumbrances exceeds the budgeted amount
> for the account or a real or budget parent. If it does, there could be
> two levels of response: soft and hard. Soft response could be a pop-up
> warning and a flag (by color or something) in a budget view which includes
> the account. Hard could be to return the transaction to edit status and
> pop-up a message or color the offending entries in the transaction.
> One could also look at providing warning thresholds, e.g., after saving a
> transaction a warning is given that 90% of the budget for account X is
> committed.
>

Yes, this would be good.


>
> 7. For reports and views the user should have good control over the level
> of detail.  I would like to have a report or view that shows for each
> budgeted account columns budget, actual, difference for the subperiod
> (month), the budget, actual, and difference for the period to date and
> the budget for the total period (year).
>
> I hope this gives enough of a sketch that others can think about how this
> could (not) work, point out issues, suggest improvements, etc. If
> clarification
> is needed, let me know.  Those on the development side might be able to say
> what trouble implementing things like #6 would be.
>
> Dale
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>