budgeting

[Josh Sled]

On Fri, Sep 28, 2001 at 09:27:30PM -0700, nigel_gnucash-devel@unos.net wrote:

| come out of "Savings" anyway).  The following month we then have an
| "extra" $100, which flows down our chain of buckets and into a category
| which doesn't always get filled (like "Discretionary").

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?

| 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...

| (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.

[ I know I'll have the money to pay for the shiney new gadgets I bought
  this week on credit, but I'll just allocate a bit of my income over the
  new few months to that, instead of savings up for it first... [instant
  gratification rules! :) ] ]

| 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 :)].

| 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.

| 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...

| What would be the objections to adding a field to the register?  How
| much pain and suffering are we talking about?  Could we add another
| "style" of ledger, maybe, so that people who don't *want* the category
| don't *have* to use it?

Both options are feasible, and not _too_ hard.  But I don't know if
another field/column for the register is warranted.  Moreso, I think we
should attempt to have a minimal impact on the existing engine structures,
as this is/should be an optional sub-system.

...jsled