gnucash budget

[David Reno]

>  -----Original Message-----
> From: 	David Reno  
> Sent:	Friday, July 27, 2001 11:01 AM
> To:	'gnucash-devel@lists.gnumatic.com'
> Cc:	'jsled@asynchronous.org'; 'bryanlarsen@yahoo.com'
> Subject:	Re: gnucash budget
> 
> 
> Regarding "types" of budget items:
> I think finding a general form for budget items is best.  I think any 
> distinction between things like number of occurrences should be treated as
> an 
> attribute, not as a profoundly different type of item.  To support this,
> lets 
> consider the "types" that have been discussed so far:
> IRA contribution:  $2000 budgeted to be spent over 1 calendar year period.
> To 
> be budgeted yearly, recurring.
> 	budget_item: (comparison expense category =IRA Contribution),
> 	(item start date=1/1/2001),
> 	(item end date=12/31/2001),
> 	(amount=2000)
> Holiday Gifts:  $200 to be budgeted to be spent over 2 months.  To be
> budgeted 
> yearly, recurring.
> 	budget_item: (comparison expense category =Gifts Given),
> 	(item start date=11/1/2001),
> 	(item end date=12/31/2001),
> 	(amount=200)
> Savings Goals:  Increase savings by $2000 this calendar year.  To be
> budgeted 
> yearly, recurring.
> 	budget_item: (comparison expense category =?),
> 	(item start date=1/1/2001),
> 	(item end date=12/31/2001),
> 	(amount=2000)
> Toy:	$500 to be spent next week.  Not recurring.
> 	budget_item: (comparison expense category =Entertainment &
> Recreation),
> 	(item start date=7/29/2001),
> 	(item end date=8/4/2001),
> 	(amount=8)
> So my point about different types is that if we view them as being more
> similar 
> than different and treat the differences as attributes, we may have a
> simpler 
> model to work with.
> 
> Regarding different spending periods:
> One of the features I want out of this is the ability to know my budgeted
> cash 
> position on a daily basis.  I think we should use a time period of 1 day
> for 
> everything; not to say that everything must occur within that period, just
> that 
> we can use multiple days to define when expenses may occur.  This gives
> more 
> freedom for future changes and helps to make budget items more similar
> than 
> dissimilar.
> 
> Regarding budget reports:
> Another feature that I want is the ability to update my budget as the
> expense 
> gets closer and more defined.  For example, a vacation: as the date
> approaches 
> I will have purchased my airfare and want that to adjust my predicted cash
> 
> position in the future.  However, I don't want my original guess to be 
> overwritten.  I want a feature that tells me how good I guess!  It always
> seems 
> that my budget looks good in three months time, but never looks good this 
> month.  That's because I'm not budgeting enough for the unpredictable
> expenses 
> that always come up.  I want this reflected in the budget three months
> from now 
> so that it can be adjusted accordingly.  Bryan, does this contradict your 
> concept of a static budget?
> 
> Regarding the formula: Income - Expense > 0
> I think that the formula should be: Income - Expense = 0.  The reason for
> this 
> is that all income is allocated to something, even if just by not spending
> it.  
> For example, if your budget calls for spending all income except $32, then
> 
> automatically, that $32 has been spent on savings.
> 
> Regarding definition of budget:
> Budgeting is the allocation of income to maximize the ratio of value/cost
> for 
> expenses.  My justification for this definition is that we choose not to
> spend 
> too much on dining out because of the diminishing return.  Instead, we
> believe 
> that at a certain point of value/cost, we should instead spend that money
> on 
> savings since we believe in the future we will have the option to buy
> something 
> with a higher value/cost ration, like rent after we lose our job!  Making
> this 
> definition more complex, buying several things together has a higher value
> than 
> buying only a few.  (e.g. The purchase of a fishing pole has little value
> until 
> a reel is purchased.  Adding in lures and a fishing license, not to
> mention a 
> boat and an SUV to pull it all add up to more value than any individual 
> part:  the sum is greater than the parts)
> 
> Regarding our process:
> Should we keep bringing out these issues in e-mail, or should we attempt
> to 
> capture the core issues that need to be agreed upon by some method of 
> documentation?  I would hate for all of us to just go around in circles
> for 
> a long time talking about all of the issues;  there are so many issues
> that I 
> think we could get lost in pontification very easily.
> 
> My home DSL is not up yet (I just moved), so I won't check e-mail until
> Monday.
> 
> Regards,
> David