Budgeting prototype

[Darin Willits]

On Fri, 2003-09-05 at 21:24, Derek Neighbors wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1

> Again, I will be happy if there is a "mirror/copy" accounts function.  I
> don't want to have to rekey all my accounts and I suspect if most of
> your are 1 to 1 neither will you. :)

The way I am thinking is that the default behaviour will be to populate
the budget with categories which have a one-to-one mapping with the
existing account hierarchy.  Most likely this will be all anyone ever
needs.  I suppose we *could* allow the user the option of typing in
their entire account tree again... but that might be a little too
sadistic! ;-)
 
> 
> | This elaboration is very illuminating.  These would be good concepts to
> | include in the design, or at least design with them in mind for future
> | iterations.
> 
> It would be nice to have "versioning" supported early even if basic, but
> I'm so desperate for budgeting I would take single version if available. :)

I would approach "versioning" as was described earlier in this thread
(PROJECTED, REVISED etc) as merely a copy operation.  Maybe I don't
fully understand the concept (very likely) but it seems like once you
set your budget in stone (I *do* like the idea of locking a budget once
it is done) you can then copy it to a new budget object and modify the
new one for unplanned expenses etc.  Maybe this is a simplistic approach
but it might not be that hard to do in the short-middle term.  But like
you, I want to see something in place soon as well, so the more advanced
features might have to wait.  


> 
> | This would be ideal but I think outside the scope of what Gnucash should
> | attempt.  And "fixing" my chart of accounts by closing accounts with 5
> | years of data is outside what I'd like to attempt, yet, I'd still like
> | the flexibility to budget with either focus (the medical/transport focus
> | or the him/her focus).
> 
> I agree it's outside the scope of "personal finance manager".
> 
> | Yes, this sentiment I agree with.  The way it is shaping up, Darin's
> | proposal seems flexible enough to handle your way of doing things and my
> | hypothetical/obtuse examples too.
> 
> Let's be honest it's free software.  We will take the code we can get.
> If it's too bothersome, let it be a motivator for someone to fix it. :)
> ~ That said, I would be more than ecstatic to see Darin's model
> implemented.  Even if I dont 100% agree with it.  The old 80/20 rule.  I
> like more than 80% of it, I won't quibble about the rest.

I'll try not to disappoint. ;-)  

Cheers,

Darin