gnucash budget

[Josh Sled]

On Tue, Jul 24, 2001 at 07:32:42PM -0400, Bryan Larsen wrote:

| I just sent this too David Reno, who asked about budgeting.  I then
| realized that it would probably be useful to send it to everybody.

Yea! :)

| Why I wanted to do something different:

Yes and yes. 

| type 1) specific date (anniversary)
| type 2) continuous
| type 3) advanced only: combination of the above
| type 4) advanced only: anniversary with slack: probably leave out.

First off, I believe your Types 1 and 2 to be the same.

WRT them both, I believe the scheduled transactions [can] provide a good
basis for auto-creating a first-order budget [depending on how the user
interacts with GnuCash -- the idea was that people would initially use
GnuCash, then start using the SchedXactions, then move on to using the
budgeting toolset as they became more comfortable with the program].
Seeing this, I seperated the frequency specification [both the Engine
structure and UI] from the scheduled transactions to make it re-usable
for this purpose...  the template transactional data is tied directly to
the Scheduled Transaction, but I believe this to be appropriate.


I've been characterizing budget-related expense types in the following way:

. Type A: simple recurring [analogous to types 1/2]

. Type B: complex recurring [analogous to type 3]

  . these are expenses which are distributed throughout the year, but
    which recur y-t-y,

  . Examples

    . IRA contributions -  it doesn't matter that the contributions are
      evenly distributed throughout the year, so long as they add up to
      $2000/yr all told.

    . Gifts/Christmas - it doesn't matter how exactly I've saved for this
      [in terms of contributions ea. month], so long as I have $X saved
      up by October/November...

. Type C: Savings Goals

  . Examples

    . Vacation: I want to go on a vacation sometime next year.  I figure
      I can spend about $2000 for it.

    . Toys:  I want to be able to buy a couple of nifty gadgets throughout
      the year... let's say a $700/yr cap.

    . Grad School: I'd like to save $Y over the course of the next N
      years so I can be comfortable in returning to Grad School full time.

  . Obviously, there's some feedback loop with the budgeting UI that
    would help the user arrive at correct/realistic values...

  . When you start talking about toys and gifts and vacation, it becomes
    helpful to have more perfect info.  Let's call it an itemized interface.

    . For vacations: It's hard to say what the overall budget size should
      be.  You can say that, and then start to make various sub-allocations
      [travel costs are half of the total, lodging half of the remainder,
      and that means I have one-quarter of the total amount to divide
      between food/excusions/souveniers].

    . For toys: you want a wish-list... I can name a half-dozen neat
      things I want to spend money on ATM... the questions I'd like this
      to be able to answer are

      . You can buy 5 smaller or 1/2 bigger, but not 3 smaller and 1 bigger
        [total is outside the budget].

      . You can buy <whatever> in a month, when you have the available
        funds.

    . There are also priorities to consider here.  It's more important that
      I allocate towards a savings goal for grad school than a savings goal
      for toys; or, at least that I allocate porportionally-correctly [?].


One may see that Type B and C expenses are very similar... I can't quite
reconsile them fully, however...


| Reports look like this:  (or in a more succint format)

I've never thought that a report-based interface was sufficient for
budgeting stuff... as per my Novemember-based mails, I've been more focused
on thinking of a highly-interactive "workbench", that would allow you to
see the budget at the various levels of granularity you'd like.  OTOH,
I see how a more static view is useful.  Ultimately, I guess, what I'm
thinking of is basically a "report" with in-line controls... :)

| The summary lines only total the "You are $X over/under budget"
| lines.  The extra information is slack that shows up on the budget
| line as cycles roll over.

And, maybe, a "you are on track to be $X over/under budget"...?


I've spent many mornings of weekend at the coffee shop up on the corner
writing out pages of notes on budgeting.  Unfortunately, they always seem
to start with "Okay... blank slate:" and end with "hmmm."  I'll type up
a couple of the most recent notes as food for thought:

----------

date: 2001.06.16T1217

. We have a working defintion for budgeting:
   The informed allocation of income to expected future expenses
. some people do this physically, with envelopes
. we see a GnuCash-based way to do it with multiple transaction between
  the real accounts and a liability|budget account [see -devel Message-ID
  <3B297FF7.7070309@uow.edu.au>, 2001.07.15 by Ben Stanley].
. but what do we really want?
  . we want the power of the physical|account-based pre-allocate w/o the
    multiple transactions
  . we want improved knowledge to influence the allocation [1].
  . we want to deal with long-period recurring expenses...
  . we want to deal with examining the effects of changes to the budget
  . we want feedback about budget health as transactions are entered
  . we want a recovery mechanism in the case of over-expenditure

[1: we want an easy interface for determining variable expenses
    [long-distance, food, utilities, &c]]

. inputs
  . all I know is that I...
    . [class alpha]
      . make '$I' a month
      . pay rent [$R] on the first
      . pay bills on the 6th, 8th, 15th, &c.
      . have auto-pay of loans [bills] on the 20th
      . gas
      . food
      . smokes
    . [class beta]
      . have expenses throughout the year, which recurr y-t-y
        . IRA - fixed
        . gifts - variable
        . Christmas - ~fixed
        . birthday - all or nothing [that is: I either throw a party
          [$200 for liquor/food] or I don't]
    . [class delta]
      . have one-time expenses
        . vacation
        . large-ticket electronics items [gadgets]

  . class alpha
    . easy enough...  I_{0} -> e_{0}, e_{1}, ..., e_{i};  I_{1} -> e_{i+1},
      e_{i+2}, ...
  . class beta
    . still not so bad
      . some issue of what I_{i} applies to what e_{j} ... how "quickly"
        to allocate towards a goal.
        . there is a question of how far to look ahead...
          . may need savings from I_{0} to deal with an e_{i} temporally
            very far from I_{0}

[ At this point I went off into a bit about generating
  constraint-satisfaction problems, which I believe may be right, but I
  omit this here ].

  . different allocation Strategies will want to be tried.
  . time, priority cannot be ignored

. output 
  . for each budgeting category, we want to know the present available
    allocation amount.  But even more importantly, we want to know when
    the expsense is "covered".
    . The former for "open" categoires, the latter for "fixed" categories.
      [ I believe here I was implicitly making a distinction in the
        variability of expense size.  Rent doesn't change much, but
        utilities bills can vary much during the quarter of the year. ]


----------

date: 2001.07.14T1143

What are the user's goals/requirements?


Budgeting occurs in two phases:

Phase One: "Limits"

In the first phase, the user seeks to characterize their large cash
flows.  Note that a frequent set of individually-small cash flows may be
considered large as well.  In this phase, the user primarily deals with
... uncontrollable [?] expenses - those which are required, the amounts
of which aren't [easily] under the users's control [1].

[1: e.g., Rent, which can be changed, but only after much headache to
    the user]

The user's primary purpose in the Limits phase is to ensure that:
   income - expenses > 0

GnuCash can assist the user in various ways during the Limits phase:
. analysis of historical register data can provide an automated, complete
  picture of expenses.
. domain-specific worksheets [daily expenses [food, coffee, cigarettes,
  &c], gas, &c] can guide expense-size determination.

Phase Two: "Pushing the Limits"

["want what I'm worth; in other terms: what I deserve.
  you're a customer: that means you're gonna get served."
	-- Dilated Peoples, "Pushing Limits" ]

The second phase of budgeting involves pushing the limits.  In this phase,
the user seeks to add new budgeting elements relating to the difference
between income and expense.  The nature of these elements is generally
associated with low-prioity and long-term savings goals, though the user
likely doesn't reason about them as such.

A reasonable goal of this phase is to reduce income - expenses to within
epsilon of 0.

At this point, the user is concerned with the following tasks:
. defining long-term expenses [savings goals]
. (min|max)imizing certain budget categories/elements, possibly to the
  exclusion of others...


...jsled