Budgeting - Let's decide what we want!

Matthew Vanecek mevanecek at yahoo.com
Mon Sep 1 12:11:09 CDT 2003


Posting to mailing lists for the record. :)

On Mon, 2003-09-01 at 10:16, Darin Willits wrote:
> On Mon, 2003-09-01 at 16:01, Matthew Vanecek wrote:
> > On Mon, 2003-09-01 at 09:06, Stewart V. Wright wrote:
> > > > amounts, etc.  Not the only way to do it, of course, just a suggestion
> > > > and what I thought would be easiest to implement.  I certainly am
> > > > interested in seeing what you have, though, and I'm *certain* we'll all
> > > > appreciate any working implementation!! ;)
> > > > 
> > > > I know I will!
> > > > (Thank God someone is actually going to spew forth code on this)
> > > 
> > > 
> > > I don't want to put a dampener on this, but I think a clearer focus on
> > > what is to be done is a better approach than for someone to go out and
> > > start coding what they would like to see.
> > > 
> > > Code is a "Good Thing(TM)" but there are still two different camps at
> > > least.  Those who want to plan for 'X' dollars to buy a new truck and
> > > those who want to be able to say "OK, 10% of this months income goes
> > > into the Truck Purchasing section of my budget".  I put myself in the
> > > last category.  Then of course there is the "I get 'Y' dollars per
> > > year so I am going to plan my budget for 12 months" camp (which is a
> > > splinter of the last group).
> > > 
> > 
> > I fail to understand the difference.  In each case, you are planning to
> > spend X dollars on a future puchase.  Darin's direction allows you to go
> > into a budget period and change the amount you are allocating to that
> > future expense for that period.  That gives you what you want, I think.
> > 
> > Me, I get Y dollars per year, divided into 26 disbursements.  I spend
> > money based on individual disbursements, not based on my yearly salary
> > (like I really should). I allocate my lunch and gasoline money on a
> > paycheck-by-paycheck method.  Each paycheck, $same goes to lunch and
> > gas.  (The rare) Excess gets moved to savings at the end of the pay
> > period (when I get my next check).  Darin's method doesn't prevent me
> > from budgeting that--it actually makes it a bit easier.  I know during
> > the next 12 months my lunch and gas needs will remain relatively stable.
> > 
> > And in the end, don't you want to plan a specific amount to pay for a
> > major purchase?  Consider a new house.  I know I need a $30,000 down
> > payment for the type of house I want.  I know my wife has a two year
> > timeline for buying that new house.  Therefore, I know how much money I
> > have to accumulate between now and then ($30,000--I know how much, but
> > now how!!), so I can effectively divide that into monthly savings goals
> > that fit nicely into a budget.  Darin's method would, of course, allow
> > me to adjust the periodic goals as needed (say, if I worked hourly and
> > couldn't put in the same amount each paycheck, his table lets me change
> > the amount for a given paycheck/period--this, I think, may help with
> > your percentages requirement--perhaps a field could be
> > percentage-calculated based on planned income for the period).
> > 
> > I just don't see the differences in our end goals--I still plan
> > weekly/bi-weekly expenses based on my paycheck, and I still plan
> > long-term goals based on how much I need to meet them.  Same as you want
> > to do, I think.  I think the direction Darin seems to be taking is the
> > best of both worlds.  A clean separation of budget vs. accounts,
> > editable amounts for budgetary periods, cumulative periods for an
> > overall timeframe, definitive relationships between budget categories
> > and accounts...all we'll need is someone to revive the SWIG bindings to
> > write some Perl reports (no bias there at all, certainly not, not like
> > Perl is the greatest scripting language around--even if it is! ;-P)...
> > 
> > In any case, since he's the only one stepping up to the plate to do the
> > grunt work, we should give him the benefit of the doubt and see what he
> > has to offer.  It's not stone tablets we're talking here--it's
> > electronic signals and magnetic bits that are very malleable...
> > 
> > BTW, the % of income per period would be a nice feature, I agree, but
> > most cash flows won't be based on percentages.  My $#!#% electric bill
> > doesn't care how much my paycheck is!!!
> > 
> > In thinking about this, it seems what you are looking for is something
> > to tell you on a paycheck-by-paycheck basis what you have available to
> > spend on X items, after you get your paycheck (i.e., you get your
> > paycheck, you divide it into various cash flow paths, 10% to savings,
> > $100 to electric, etc.), perhaps because you don't get the same amount
> > each payday.  I'm not sure why there couldn't be room for both, but I
> > think Darin's method could satisfy even this requirement w/o affecting
> > the rest of the codebase.  Just change the budget amounts in the table
> > each paycheck...
> > 
> > Hmm, well, seem to have spewed forth enough dialog.  I think both the
> > main ideas proposed are very useful, but I think the separate budget
> > idea should be able to handle the needs of both camps.  Just depends on
> > how cleanly it is implemented.
> 
> um... yeah... what he said.  (except change the bit about perl into
> python and you are all set! ;-)
> 
> Cheers,
> 
> Darin
-- 
Matthew Vanecek
perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
********************************************************************************
For 93 million miles, there is nothing between the sun and my shadow except me.
I'm always getting in the way of something...



More information about the gnucash-user mailing list