Budgeting proposal

[Dave Fancella]

On Wednesday 16 April 2003 08:20 pm, you wrote:

<snip>
>
> This is, IMO, a bad idea.  A Budget is a separate entity; it should not
> be relegated to the ambiguous netherworld of kvp-dom (KVPs are suitable
> for extending existing objects, I guess, but should be avoided for new
> entities--a Budget is a new entity).

I'm going to have to disagree on the separate entity part, however, with a 
disclaimer that I am not an accountant.  :)  GNUCash is my initiation into 
double-entry, and my sole motivation for budgeting is for my family budget.  
Anybody coming from a business accounting background, or who even knows more 
than I do (which is exactly jack) will be better prepared to define this 
relationship than, but I'll continue farther down.  :)

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

But I've been thinking some more and have something a bit half-baked, but 
might be along the lines of what you're talking about.  And it's potentially 
complicated, but extremely powerful.  :)

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

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

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

Another weakness in my kvp-based proposal is that budgeted amounts in a 
category are a detail relationship to the category master, so the setup 
really needs to allow multiple records to be made.  In this fashion, we can 
also log every single slight change to a budget that is ever made, and who 
makes it (in the database, anyway).

Aha, I remember what I was thinking last night.  :)

An account type "budget" that's handled different than regular accounts.  You 
can still see a ledger, but I'll continue.  :)

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

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

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

Dave

> Good thoughts,

-- 
"I slipped inside the oval office,
I slipped in oh so fast,
Grabbed the president by the necktie
And wiped my funky ass, hey"
                -Soulhat, "Bonecrusher"