Budgeting proposal

Matthew Vanecek mevanecek at yahoo.com
Thu Apr 17 20:14:10 CDT 2003


On Thu, 2003-04-17 at 14:04, Dave Fancella wrote:
> On Thursday 17 April 2003 07:22 am, Matthew Vanecek wrote:
> The more I think about it, the more I have to disagree with a budget being a 
> separate entity entirely.  If your budget isn't linked to an account, or the 
> account it gets linked to over time changes,

I think I see where the miscommunication is occurring.  I don't mean
that Accounts and BudgetCategories are *not* linked--quite the
contrary.  It'd not be very useful to have an unlinked BudgetCategory,
when you are generating reports, etc.  How would you measure your
progress against the unlinked BudgetCategory?

OTOH, if you creating a new Budget, it's possible you may not have
created the associated Accounts yet.  Therefore, you'd need the ability
to create BudgetCategories without linking.

Admittedly, this ability can get you in trouble when dealing with
reports, etc.  As with other things in Gnucash, and many other
applications, it's up to the user to make sure all the links are set up
correctly prior to running a report.

However, it would be useful to have a report displaying unlinked
BudgetCategories, and to also not them on budget reports.  The
income/expense amount *on a report* should default to $0, with the entry
marked as an unlinked BudgetCategory.  I feel that should alleviate your
concerns in this area.

> 

> I'd prefer dates myself just because it would simplify a lot of the math.  If 
> it becomes necessary to change it, though, it shouldn't be that hard.
> 

Me, too.  Other methods could be implemented incrementally, as the
system matures.

> I've been thinking about credit limits, actually, and it seems like a credit 
> limit is similar, although not exactly, like projects.  You get a certain 
> amount of money for the life of the card (barring credit increases, of 
> course), but it's revolving.  Presumably in a project budget there's no way 
> to deposit money back into the project, or at least it's not very common.  
> With credit cards you will be depositing money into the account whenever you 
> pay your bill.  I don't know if they should be linked, though, because 
> although functionally similar, they are conceptually different beasts 
> entirely.
> 

Well, Budgets are primarily for tracking income/outcome.  Paying down a
liability such as a credit card is surely an outcome. ;)  Tracking
credit limits should be handled differently, if at all.  They are not
strictly a budget consideration (although they can make for great
juggling acts!!).

> > 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.
> 
> Is this an "industry standard" way of doing it?  The real problem I'm seeing 
> with that, though, is that you'd have to transfer money from your bank 
> account to your Assets:Bank:Electric, and your bank register wouldn't show 
> the real amount.  

No, definitely not.  It's just a handy way someone on the list came up
with.  And yes, you have to transfer money from the parent Bank to the
subaccounts (although you could do it all in one transaction with many
splits).

> My auto budget is fairly straightforward.  There's insurance ( $0 ), gas 
> (split for 3 cars right now), and service ($50).  It's the last one that gets 
> you, though.  If you every have to do any real work on a car, you'll be 
> damned lucky if you can pay less than $50.  So the idea is that every month, 
> the $50 is spent.  Every year or so when we actually have a major expense on 
> fixing a car, the money would be there because it built up every month.  Of 
> course, I suppost just transferring the remaining balance in the service 
> budget to a separate service account for safekeeping would do the same 
> thing...  Um, never mind?  (As you said, why didn't I think of it before?)
> 

What you're describing above is a basic tenet of budgeting.  Annual
expenditures should be divided up as you do above with your service. 
Makes it easier to pay the homeowners insurance next year if you expense
it every month, and track it accordingly on the budget.


> So the accountant just says "how much did we spend?", gets the number and 
> looks at some scrap of paper his manager gave him and does the math in his 
> head?  :)  Ok, it's probably a bit more involved than that....  but I see 
> what you're saying.
> 

Well, it's computerized, and yes, a bit more involved and subject to
higher authority, etc.  But, basically, yes.  Of course, there's
accountability built in for budget overruns--iron maidens, bamboo shoots
under finger nails, etc.

> I've sorta got an idea here...  does GNUCash have any plugin API or anything?  
> I'm wondering, if it did, then I could make a budget plugin rather than 
> budgeting as an integral part of the application.  That would leave room not 
> just for other implementations, but it would also make something that would 
> allow for a lot of other things, such as plugging into a CRM or something.
> 

It's got a modular API.  You can create a Budget module, and it could
get loaded and used at runtime.

> Anyway, to continue.  :)
> 
> If Budgets are a separate entity, then a way is needed to store the amount of 
> the budget, the length of the budget, mmmm, and I think that's it.  (the tree 
> structure is assumed to be part of the architecture no matter what :) ).  

All that is stored within the Budget Object.  Think object-oriented--it
gets easier to conceptualize.

It's really analogous to an AccountGroup--a Budget is a group of
BudgetCategories.  The bottom line is calculated as a sum of the
categories -- one for income, and one for outgo (you have two types of
categories--"money in" and "money out", at its simplest).

> Next we need a way to do math with the budget and accounts.  Traditionally, 
> in financial apps anyway, this is done by linking every single transaction 
> with a budgetted category, and in some applications (can we say Quicken? :) ) 
> it gives the illusion of being double-entry.
> 

I'd rather see the Accounts linked to a budget category.  That way, for
the from/to dates of the budget, you could total up all the Splits in
that Account that fall within the from/to dates.

Gnucash truly is double-entry. ;)

> Now, from a UI point of view, I think it would be confusing (and I *really* 
> don't want to have to explain this to my wife) if you have to chose both an 
> account (that might look like a category) and a budgeted category for every 
> transaction.

You don't do this on a per-transaction basis.  You do it on a
per-Account basis, and you do it once.  The point of the budget is not
to track every single transaction/split.  Rather, you want to see
account totals vs. budgetted amount, where the account totals are for
the budget lifetime.  These totals are calculated dynamically in the
budget compliance report.

Since every transaction must have a source and at least one destination
account, it all works out.

>   Now, I do have a tendency to put the category in the Payee 
> field, but some people really do care about having the Payee field reflect 
> reality, where I don't, and I even have some blank ones.  So, ideally, a way 
> should be found that makes the difference between a budget and an account 
> seamless to the user.  As far as I'm concerned, I'll be happy just putting a 
> budgeted amount on each expense/income account, and leaving the other 
> accounts alone with budget.
> 

You're thinking of a budget as something you do on a per-transaction
basis, which you really don't want to do.  That'd be *way* too much
work!  A budget is something you create once.  On a regular basis, you
compare you money flow to the budget to see how you stand.  It should be
as simple as selecting the report from the reports menu.  Since every
transaction has a source and a destination split, you never have to do
anything special with the transaction or splits.  You just run a report
once in a while.

If your UI is set up like you want, with the columns, then you also get
the real-time comparison in the Account tree.

> Is there a specific situation(s) that would require the budget and accounts to 
> be kept separate entities?  Would it be reasonable for the sake of a 
> practical implementation and UI to marry the two?
> 

No, not really reasonable, IMO.  If you keep them separate, you open up
the ability for multiple budget scenarios, etc., without losing any of
the reporting capability.  You also have the opportunity to re-use the
Account tree code to a certain extent, within the main window.

Any work that you do on this would be greatly appreciated, I suspect.  I
think the priorities right now are Lots, Periods, and then Budgeting.  I
could be wrong, but that's my impression.  You're welcome to implement
as you see fit--I believe my way is best of course! =P but really, I'm
open to a better solution.  I've just thought about this for quite some
time now, while looking over and working with Gnucash code, and data
models, and accounting principles....

Hope I've been clear, and not overly verbose.

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



More information about the gnucash-devel mailing list