Budgeting - Let's decide what we want!

Stephen Cuppett scuppett at nc.rr.com
Mon Sep 1 23:49:02 CDT 2003


My $0.02 as to the design of budgeting in GNUCash.

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.

Each individual budget would consist of all account types such as Asset,
Liability, Equity, Revenue and Expense.  Each account inside a budget
would have it's own, separate name from those in the actual financial
data (same name allowed, but not required), a target value and a mapping
to one or more accounts from the "real" financial records of the same
type.  I would imagine setting target values as percentages of other
targets within the same budget wouldn't be too difficult.

At any point in time a user could prepare a budget analysis report
whereby the user would define which budget they wish to work with,
select a date range and be presented with the budget's target values
along with a side-by-side comparison of the change in account value
during the determined time frame (A net combination for multiple mapped
budget accounts)  

E.g.
Consider a budget named "Annual Plan".  At any point in time a user
could run this budget against the accounts with an arbitrary range such
as 1/1/xx to 3/31/xx and see if they are 25% to plan or where they are
falling behind/running ahead.

The same user could also have another budget named "Monthly plan". He
could determine where his problems/successes occurred by viewing
individual months against this budget.

On Mon, 2003-09-01 at 12:15, Andrew L. Gould wrote:
> On Monday 01 September 2003 10:01 am, 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.
> 
> I still think we're talking about 2 different tasks, which could be handled in 
> separate "modules".  (I mentioned this in a separate sub-thread of this email 
> topic.)  Currently, I earmark funds by removing funds from my checkbook and 
> allocating them to specific purposes in a spreadsheet.  (I'm still planning 
> the conversion to Gnucash.)  This is similar to the cash management described 
> above and to encumberance accounting used in governmental accounting (yuk!).  
> The amount left in my checkbook is like petty cash, which is used for food, 
> fun, etc.  This method affects my day-to-day, week-to-week activities.  This 
> may be all that's necessary for personal financial management; but a small 
> business should also use a separate budget process that is more strategic in 
> nature.  A budget is something you would put in a Business Plan.
> 
> Andrew
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at lists.gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
-- 
Stephen Cuppett <scuppett at nc.rr.com>



More information about the gnucash-devel mailing list