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...
_______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
