Budgeting - Let's decide what we want!

Stephen Cuppett scuppett at nc.rr.com
Tue Sep 2 08:35:49 CDT 2003


The single budgetary concept along with the separate column would work
nice, be one of the simpler things to implement and generally apply well
to an individual keeping record.  However, if having the program usable
by a vast majority of businesses is important, budgets are an everyday
thing.  From production schedules, advertising, and business plans, all
are very real, extremely necessary, and encompass ranges of time from a
couple weeks to several years as well as all the various account types.

The column concept introduces a conundrum of it's own, especially in the
asset category.  I understand the remaining balance you'd like to see,
but how do you compute it?  You would define a budget with a set amount
or percentage within a category and then base it's deflation on a
particular date, from the transaction you click on, where?  Eventually,
it will run negative as time passes on and going concern outruns your
single budget.  So, regardless of the end implementation, you'll be
editing your budget to adjust either the start time or the amount, and
you'll have created the same problem as the people creating virtual
accounts now.

I will admit that the column idea would be nice; however, having them
there would be a nice alternative to running a report and seeing
everything side by side.

On Tue, 2003-09-02 at 06:43, Scott Minster wrote:
> This is a long thread, but since it's pretty important, I'll throw in my 
> thoughts anyway and hope they're useful...
> 
> Stephen Cuppett wrote:
> > In terms of definition, a budget is a separate entity from financial
> > records used for comparison purposes and tracking at different intervals
> > through a particular time period.  It's representation in GNUCash should
> > be no different.  
> > 
> > I envision the program keeping track of a budget or multiple budgets (by
> > name) separate of the defined Asset, Liability, Equity, Revenue and
> > Expense accounts comprising the actual financial data of the user.
> 
> I agree that this seems to be the right way to go.  For me at least, 
> it's much more intuitive that the budget should be outside the actual 
> account tree and reference back to it instead of using sub/virtual 
> accounts right in the tree.  I know some people are using that method 
> now, and I don't mean to insult them, but using sub accounts seems more 
> like a hack than a real solution.  One of the things I've always liked 
> about Gnucash was that it accurately described my financial situation. 
> Virtual subaccounts aren't what I really have at the bank, so that would 
> break the description.
> 
> However, I think it would be nice if we could add a column to some of 
> the account ledgers that relates to the budget (having multiple budgets 
> might be tricky -- can more than one apply at the same time?).  This 
> column would tell how much money is left in the budget for that account 
> for a given period (month, week, year).  So for example, if you have 
> $100 a month budgeted for food, your Expenses:Food account may look like 
> this:
> 
> Date    Num  Description    Transfer R Expense Rebate Balance  Budget
> 1/1/03       Walmart        A:Cash   n  $15.00         $15.00  $85.00
> 1/2/03       Bakery         A:Cash   n   $9.00         $24.00  $76.00
> 2/1/03       Walmart        A:Cash   n  $23.00         $47.00 $153.00
> 
> and so on.  This way people could more immediately see what's left in 
> the budget for each account without having to run a report.
> 
> > 
> > Each individual budget would consist of all account types such as Asset,
> > Liability, Equity, Revenue and Expense.
>  > ...
> 
> Wouldn't the budget be composed of only money coming in and going out? 
> Even if it the money going out was going to an asset like savings, I 
> don't think it should necessairly be called an asset.  It seems that's 
> more like an outflow of money that happens to go to an Asset account.
-- 
Stephen Cuppett <scuppett at nc.rr.com>



More information about the gnucash-devel mailing list