budgeting

[nigel_gnucash-devel@unos.net]

On 30 Sep, Josh Sled wrote:
> On Sun, Sep 30, 2001 at 05:06:00PM -0700, nigel_gnucash-devel@unos.net wrote:
> 
> | FWIW, I don't personally care to know *where* my budgeted money is - I
> | have to manage my *physical* account balances separately from my
> | *logical* bucket system anyway.
> 
> I think some people will care where it is, especially as it influences
> how accessible it is.

You're thinking maybe someone wants to buy groceries using their Debit
Card, so they need to know not only how much is available in their
budget, but how much is physically available in their checking account.
I can see the importance of this, but I still think this is the user's
responsibility, not the budgeting subsystem's.  I think we'll be
creating a monster otherwise...

> I think for medium-to-long-term savings goals, it makes sense to take
> advantage of accounts available, such as moving savings out of my BofA
> savings account [at like 1% or whatever it is] and into a money-market
> [at like 4%]... or into a mutual fund which expects to get 10% over time...

Again, I consider that to be the user's responsibility.  The budgeting
subsystem doesn't have to know about that.  I'm not trying to say that
it doesn't *matter* where the funds are, just that it shouldn't matter
to the *budgeting* subsystem.  Maybe we need a separate "financial
planning" subsystem...

> | the grocery store and charge it to my credit card. Now there's $435 left
> | in my grocery bucket...
> |
> | ... but no physical transfer of funds has taken place, nor is one likely
> | to take place for some time.  
> 
> Well, there's a change in your available credit, which may be interesting
> for other calculations.  As well, there's the change in the 'used' amount
> of the budgeting category/bucket.

Sure, but the latter isn't a *physical* transfer of funds.  There's no
associated *physical* account change.

> | This will generate two *physical* transactions (Savings -> Checking,
> | Checking -> Credit Card) which, in turn, won't affect the buckets at
> | all.
> 
> Well, the Savings -> Checking doesn't, but the Checking -> Credit Card
> does affect the available credit.  If the bucket has the two values
> "allocated" and "used", then yes: the bucket is only affected when
> the charge is made.  If the bucket has the three values "allocated",
> "used:held" and "used:disbursed", then the charge moves $65 from
> "allocated" to "used:held", and the Checking -> Credit Card xfer moves
> it from "used:held" to "used:disbursed".
> 
> If we can do more interesting analysis with those three distinctions,
> we should have them.

Oh, I'm not sure I like the way this is going.  I can see how that data
would be interesting, and why you'd bring it up (and there may be a
really good economic reason, too - I'm not an economics guy), but I'm
concerned that pretty soon my *single* credit card payment needs to be
associated with expenses *all*over*the*place*.

I guess we could assume that a credit card payment changes the status on
all the transactions between the previous payment and the current
payment, but that still adds a level of complexity I'm not sure we need.

What would you use the "used:held" and "used:disbursed" numbers for?
Some kind of "this money as been logically spent but physically exists"
calculation?

<snip>
> |  which
> | will allow me to shift my physical monies between accounts as I see fit.
> 
> If you desire to do so, you should be able to.  However, my preference would
> be "tell me what account to put the money in to maximize utility... and
> better yet, schedule the transfers for me."  Maybe the former is in phase
> II, and the latter in phase III... *shrug*.

I really see this as a separate subsystem - this doesn't have so much to
do with budgeting as with financial planning.  This seems to be more
closely related to stocks/investments managing than budgeting.

> [ As you say in the other mail, we have differing views of how the user
>   and the budgeting system interact :) ]

Yeah, and I'm alright with that.  I'm not saying that "I know the way,
and everyone should follow".  The beauty of open source is that you
implement what you want, and if I don't like it, I can always do it
myself.  I'm just throwing my $0.02 into the mix to be helpful, not to
tell you how to code your feature.  Heck, if you code it, I'll probably
use it, regardless.  >)

> | So, I spend $500/month on groceries, but
> | that $500 is actually sitting in my savings account until the bill is
> | due, so my grocery bucket generates $0.x of interest, which I will
> | probably apply to the "savings" bucket.  I don't see a reason to re-assign
> | that special income to the "grocery" bucket.
> 
> If it's really $0.x, then yes...  But $500 @ 5% is $25, which is a
> tangible amount.  And, in the progression of saving towards a large goal,
> the values involved may become less and less trivial over time.
> 
> If I were smart, I'd be saving $1,000/mo right now.  After 10 months,
> that's $10,000; in a 5% money market, that's $500/mo interest income...
> which is half of the $1000/mo contributions ...  there are two relevant
> options, here:
> 
> 1. Adjust payments to include interest income.
> 2. Don't, and allocate the interest income to some other purpose.
> 
> I want this system to help me make the right decision in that case.
> The right decision is based on total income, other savings/financial goals
> [for instance, I may want to let the interest income go toward the savings
> goal after October, because a) it's already in the account and b) my
> "normal" income will be going towards Christmas gifts].
<snip>

Again, I see this as a financial planning/investment feature.

Have fun, (and thanks!)

Nato

P.S.  The bucket system description is taking longer than I had hoped.
It might take until tomorrow or even Tuesday...