budgeting

[nigel_gnucash-devel@unos.net]

On 30 Sep, Josh Sled wrote:
<snip>
> So there's some policy for Budgeting Categories WRT unused portions of
> the allocated amount.  The policy may be a ordered list of the
> following elements:
> 
> . carry-over unused amount for next period
> . use unused amount for over-allocated categories
> . unused amount goes to 'pool'
> 
> Others?  Sound right?

See the bucket system description below...  (OT: I hate it when I'm
hacking code in vi, then go to write e-mail and inevitably hit <ESC>,
which my mailer doesn't acnowledge at all... sigh.)

> | At that point we *know* that we have $500 sitting in the bank, and
> we
> | don't have to stress about minor repairs or maintenance.  I don't
> | necessarily care *where* that money is physically located, though,
> | because I can move money around at will in physical accounts.  So
> the
> | "buckets" are logical entities completely separate from any specific
> | physical account.  
> 
> As I talked about in the mail to Todd, I think this is going to be
> true a lot of the time, but it won't be true in many other cases...

See my reply to your e-mail to Todd.  >)

> | (A side effect of this is that when I charge
> | something to a credit card, I count is as "spent", but it's still
> | actually located in my savings account, so I accrue interest until I
> pay
> | the bill, and I'm *guaranteed* to have the money around to pay my
> credit
> | card bill, which means no finance charges).
> 
> I think it's imporant that a budgeting system understands the notion
> of a credit card, and it's limit.  There are expenses that you'll
> charge to a card for convenience, but are already "covered" in a
> savings location. There are other expenses, however, that may be
> budgeted for, but aren't already _saved_ for, and an implicit savings
> goal is created at the time of the charge, to be re-paid on an
> schedule appropriate to the financial picture.

This is where we may have to discuss the role of the budgeting system. I
use it basically as a reporting tool - to tell me how I'm doing based on
the rules that *I* set.  I'm not really interested in the budgeting
system knowing or caring about how/when/why I re-pay my bills.

I may spend money that doesn't exist, or I think *might* exist in
future, but *I* decide how/when to pay that back.  Maybe my policy is
that I "borrow" money from another bucket.  Maybe my policy is that I
leave a particular bucket with a negative balance for the time being,
and make it up in the succeeding months via the natural flow into that
bucket.  Regardless, I think I should have the freedom to treat my
buckets as I like - the budgeting system is just there to help me keep
score and inform my decisions, not to make them for me.

This happens to me all the time, BTW.  I recently charged $567 to my
credit card as a business expense.  When that goes into gnucash, I count
it against the "Miscellaneous" bucket, which immediately goes negative
(and turns red, which is really pretty.  >)).

I don't care, though, because I know that I will be reimbursed for the
expense.  When I *am* reimbursed, that money goes straight back into the
"Miscellaneous" bucket and I'm back where I started.

You could argue that gnucash should know about reimbursable expenses,
and have some logic built into it that allows for it to somehow know
that you're going to have special income flow into that bucket, but I
think that's more complex than it needs to be.  Leave some of that to
the human...  >)

> | And now, to gnucash...  >)   To pull this off in gnucash, I think we
> | need another field in the register, which I'll call "category" for
> now.
> | If we tracked a "category" (notice: separate from expense - I track
> my
> | video rentals and movie tickets separately from an expense
> perspective,
> | but I budget $40 for "Entertainment" every month) for every expense,
> 
> My thought about this has been that the budgeting category for
> "Entertainment" would be mapped to both relevant Expense categories,
> and thus no other "category" field is needed for splits/transactions.
> [terminiology is becoming a bitch, here :)].

I thought we'd already addressed the complication here, namely that
there's not always a convenient mapping between Expense categories and
the budget subsystem.  In fact, I think it was you who said:
	On 27 Sep, Josh Sled wrote:
	<snip>
	> As well, it maybe the case that I have one expense account [for
	> food, for example], but want to budget it in more detail
        > [$A/mo for dinners made by me, $B/mo for dinners out on the
        > town, $C/mo for workday-lunches, &c.]

I don't think I currently have an example of the (one Expense category)
-> (many budget categories) mapping, but, as you did above, I could
forsee such a thing.  But maybe I'm imagining it...

> | it'd be trivial to write a report which read a file containing your
> | monthly allotments and caps, then processed all your expenses and
> | did the math for you.
> 
> Well, I've said before that I don't think the budgeting stuff
> can/should be shoehorned into a "report", but it depends on what the
> overall functionality is.  And I don't think that budgeting info
> should be in anything external to the GnuCash data file.

Well, as I said before, I pretty much use the budgeting system the same
way I would use a report - it's just a really spiffy income/expense
report.  And storing the budget data in the main GnuCash data file may
involve extending the file format, which comes with a higher price than
another external file.  I agree that the main data file is the *correct*
place, and where it should go in the end, but during development it
might be safer to keep it elsewhere.

But maybe I'm too paranoid about corrupting my financial data...  >)

> | Right now I do it using a *much* ickier and complicated procedure. I
> | can make it work in gnucash, so I know the basic philosophy is sound,
> | but without hacking some new code (which I don't have time for right
> | now), I'm forced to use a really kludgy manual system which I won't
> | describe here.
> 
> Oooh.... will you describe it _here_? :)  I'm very curious... about
> both levels of the process...
<snip>

Well, I was going to, but... no.  This e-mail is too long already.  So,
instead, I'll send it as it's own e-mail.  It'll probably start it's own
thread anyway...  >)

Plus, then all the procmail users out there will know how to avoid the
whole thing...  >)

Have fun,

Nato