Budgeting proposal

[Matthew Vanecek]

On Wed, 2003-04-16 at 23:09, Dave Fancella wrote:
> On Wednesday 16 April 2003 08:20 pm, you wrote:
> 
> <snip>
> >

> > Budgets are only loosely linked to Accounts.  Accounts are handy to have
> > when you set up your Budget, because the BudgetCategories can be taken
> > directly from the Account hierarchy.  E.g., "create me a new Budget
> > based on my Account tree".  In a robust system, you would be able to
> > link and delink BudgetCategories to/from Accounts.  A delinked
> > free-standing BudgetCategory may not be very useful without an Account,
> > but there you go...
> 
> Um, thing is, at least the way my account tree is currently setup, each 
> expense account is labeled somewhat descriptively with what was bought.  I.e. 
> Utilities:Internet (yes, it's a utility, not a luxury), Utilities: Gas & 
> Water, etc.  So the account structure already tracks exactly how the money is 
> spent.  A budget would be an overlay on top of the existing account structure 
> that says "This is how much you are supposed to spend, no more, no less".
> 

I think you misunderstand me.  BudgetCategories bear the same name as
its associated Account merely out of convenience.  The fact that you use
the same name for a BudgetCategory as its associated Account is only to
provide a little sanity.  You could easily have different names for
BudgetCategories.  There would, of course, have to be a dialog in which
to associate a BudgetCategory with an Account.  Also, a Budget does not
track how the money is spent.  A Budget tracks how you *want* to spend
the money, as you say above.  It is not an overlay, though.  It's a
separate beast.  You can mirror the Accounts, or not, as you wish
(although it is much easier to mirror the Accounts).

> > Once you have your Budget hierarchy created (either manually, or based
> > on you Account hierarchy), you can enter the period of time for which
> > the Budget is effective, as well as individual amounts for each
> > BudgetCategory.  Note that it would be useful to have the amount entry
> > automated based on the Account history for a period of time (where the
> > period of time is user-specified).
> >
> > The above model is greatly simplified, of course, from my vision of the
> > whole thing.  You should be able to edit the Budget in a similar fashion
> > to editing Accounts.  That is, the hierarchy would be displayed the same
> > as the Account hierarchy, but "opening" a BudgetCategory would bring up
> > a dialog to edit the currency amount, etc.,  instead of bringing up a
> > register.
> >
> > This model also allows for creating several simultaneous Budgets and
> > running scenarios/reports against each one to determine the most
> > favorable outcome, or whatever.  You could, perhaps, mark a given Budget
> > as default, and all reports are run against that Budget by default.
> > Reports could show you how your current expenditures match your Budget,
> > etc.  A lot of the tracking stuff doesn't really need to be stored--it
> > can be captured in reports as needed.
> 
> This is a weakness in the setup I proposed, not having multiple budgets.  It 
> would also be nice if we could track changes, so that if you decrease your 
> budgeted amount in a category, then show a report later you could hit a 
> button that says "Compare to previous changes" or something.  How useful this 
> information is is quite beyond me, but I'd like to look at my previous year's 
> budget and say "If I had stuck to my January budget completely, how would it 
> have looked for the whole year?".
> 

For a business, I guess, the change tracking capability would be pretty
useful.  I'm not sure how truly useful it is for the typical person,
though.  Still, if it's there for the business, there's no reason the
private sector couldn't use it.

The setup I'm thinking about *does* allow for multiple Budgets, which is
the main reason I came up with that method.  Also, if you treat a Budget
hierarchy as a separate entity from the Account hierarchy, it becomes
significantly easier to track changes, etc.  Although, since you can
have multiple Budgets, you could just create a new Budget. ;)

> > As for your columns idea to show the budgeted amount and the current
> > Account balance, I like that idea.  To implement it, you would just mark
> > a given Budget as default (with appropriate date reasonability checks,
> > of course), and you could see the difference.  This would require,
> > though, that the Account balances be captured for the same period for
> > which the Budget is effective.  I think, in the short term, that a
> > dynamic report would be easier to write, though.
> 
> I was actually thinking that you would just query the transactions for the 
> specific time period, kinda like this:  (note: I've no idea how GNUCash 
> handles queries right now, here's some broken SQL)
> 
> SELECT * FROM Utilities:Internet WHERE DATE <in the budgeted range> 
> Summary=SUM(Amount);
> 
> (my SQL isn't real good, I know)
> 
> Basically, get all the transactions for the specific budget for the specific 
> time period, total them up, and show that.
> 

That'd be a change on the main user interface, which is why I think it
would be relegated to a report.  I think the desire is there to maintain
the current account balance in the interface.  You could make it a
configurable option, though.  For the short term, however, I feel that
this type of information will have to be in a report (I'm not speaking
to the rightness or wrongness of one vs. the other--only to reality and
necessity).  Unless you did the work, maybe....

> > I think conceptually, we're pretty close.  One point I'd like to make
> > though:  where you use months/basetimeunits, etc., we need to be sure
> > that the effective time period for a Budget is 100% customizable.  For
> > example, my current project at work certainly has a time limit, but the
> > Budget is actually (or will be, when approved. :( ) effective for the
> > life of the project, as opposed to effective for a period of time.
> > Subtle difference, but critical.
> 
> Ok, I tried twice to explain my understanding of the difference and erased it, 
> but I'm not seeing how it matters one way or the other.  Instead, without a 
> project architecture, I'd have to say that for these situations, it's not 
> necessary to setup a time for a budget.  Say, make any of the numbers 0 would 
> clear out the time period, and just define the if the result of the division 
> of the ratio is 0 then the budget is indefinite, and expires only when it's 
> finished.  We could allow the two date fields (or the one date field, I 
> haven't figured out if expires should be a date field or not) to be made 
> blank to reflect an indefinite length of time, or better yet (since you'll 
> want time-based reports at some point) you get the basetimeunit ratio to come 
> out 0, then set the startdate for the beginning of the project and the 
> expires for the estimated end of the project.  Then you modify expires as 
> needed, and track this change.

I'd prefer two date fields: A from and a to.  We might could utilize the
Lots framework to support projects (although right now they are/will be
used for securities, they seem to loosely fit the need for tracking a
project, too...different discussion).  Now that I think about it, Lots
would probably be a better way to track project expenditures.  You could
have EITHER a from/to date, OR a Lot.  That depends on being able to
associate any given transaction/split with a Lot, though, as opposed to
just securities transactions.

For now, I think just the dates would suffice.

> 
> I'm not entirely sure how to organize this, but each budget is an account, 
> still.  When you receive money in your budget, money is deposited into the 
> budget account.  Then, when you spend the money in that budget account, it is 
> transferred into your Expense account.  In this way, the budget accounts show 
> you how much you have, how much you anticipate having in the future.  The 
> expense accounts show you how much you have spent in the past.  With 
> historical records in the budget accounts, you can compare those to the 
> expense accounts for historical reporting.  The only problem I'm having with 
> this is that it looks like you have to make 3-4 entries for every 
> transaction, instead of just 2.  :(
> 

Some people already do something similar to this, by having sub-accounts
of their bank accounts, and splitting money into the sub-accounts.  When
they pay the Electric bill, the transfer money from Assets:Bank:Electric
to Expenses:Utilities:Electric.  It's a pretty nifty way to work around
the lack of budgeting capabilities.  Instead of anticipation, you have
current balance.


> One thing I'm trying to make happen, somehow, is to transfer money from one 
> budget to another.  So let's say you get your electric bill and it's $20 
> higher than budgeted, you transfer a total of $20 from other budgeted 
> categories to make up the difference, but it's only temporary.  Next month 
> everything goes back to normal (except for any budgets you borrowed from that 
> haven't moved into their next recursion).
> 

Your trying to make the budget too much like the accounts.  They really
are two totally separate things.  You don't transfer monies around in a
Budget.  You simply adjust allowed amounts.  There is no double entry in
a Budget.  I'm pretty strict, so I probably wouldn't adjust amounts, but
others would want to increase, say, Budget:Expenses:Electric, and
decrease, say, Budget:Expenses:Movies.  You can't really impose a
requirement for a "balanced transaction", though, in a Budget.

> How do paper accountants handle budgeting for companies?  Is there a standard 
> procedure?
> 

The accountants don't, really.  My manager creates a budget based on
planned projects.  It details salaries, raises, software licenses, group
outings, etc., that are planned for the year.  Portions of the Budget
are approved, others are disapproved.  The final Budget is what he uses
to spend money.  The financial people can run reports and compare his
Budget with his actual expenditures (and so can he).

The Budget really is its own little entity.  It's changeable, portable,
and can bite you in the butt. On the other hand, it's nice to know how
much money you plan on having, and how much you plan on spending. 
However, it's association with the Accounts is only incidental (albeit
important).  What happens in the Accounts doesn't affect the Budget, and
what happens in the Budget doesn't affect the Accounts.  It's the
*comparison* of the two that will  make you cringe. =P

Hopefully this all makes sense.  The point is, you don't need the
Accounts to create a budget.  You could just as easily create a Budget
in Gnumeric, and plug in numbers on occasion from Gnucash to get your
progress in the Budget.  Hmm, wonder why I hadn't thought of that
before...

-- 
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...