Budgeting prototype

marthter marthter at yahoo.ca
Fri Sep 5 12:27:25 CDT 2003


Derek Neighbors wrote:

> marthter wrote:
>
> | Maybe I'm psycho but I can think of lots of cases where the budget
> could have to cut across the accounts heirarchy.  (This sort of goes
> back to the 1-dimensional vs. 2-dimensional ideas in account naming.)
> |
> | Maybe my accounts tree goes
> | Expenses:Medical:him
> | Expenses:Medical:her
> | Expenses:Transport:him
> | Expenses:Transport:her
> |
> | But I want to try a budget based on the him/her distinction.
>
>
> Generally in accounting principles you have a focus of some sort.


I sort of gathered that you take budgeting very seriously, do it in some 
professional role, and want it very structured.  That is great, and I 
think we want a budgeting feature that CAN work your way to attract your 
type of user.  I think we also want it to BE ABLE to be used in a less 
structured way because I don't think all home users think your way.  
They WANT to do some changes half way through the year (and then maybe 
undo them - or not save the changes - or have multiple budget files for 
the same year) to see if they can afford a vacation.  They are not held 
to their budget as strictly as a government is.  If they are disciplined 
they may stick to it, but if they aren't they won't.  Maybe having a 
"lock my budget" toggle would be a good little feature?

I think by "structured" we are talking about two aspects without really 
being clear about the distinction:  (1) do we allow or not allow an 
accounting category to be tied to accounts from _more than one_ branch 
of the account tree, (2) do we allow or not allow changes to the budget 
in the middle of the budgetting period.


>   You
> generally budget at a higher level than you spend (unless you are
> unusually anal)  You would in this case set your accounts up how you
> want to see them in relation to that focus.  If your focus is Him vs.
> Her as a primary concern.  You probably need to revisit your chart of
> accounts to add this emphasis.
>
> Expenses:Him:Medical
> Expenses:Him:Transport
> Expenses:Her:Medical
> Expenses:Her:Transport

I agree, that would be the most logical, but sometimes there are other 
considerations that steer you to a slightly less logical approach.  You 
still want it to be _possible_ even if it isn't the way the government 
would do it.

If I have 5 years of data in my GnuCash file with the medical/transport 
"focus", you're saying I  can not budget based on the medical/transport 
distinction one year, and based on the him/her distinction another 
year?  I HAVE to change the focus in my chart of accounts if I want to 
budget that way?  I just don't like.

It seems you are saying that your camp is "right" and only implement it 
for your camp.  I'm not even really joining a camp, I'm just saying try 
to handle both.


> Part of the problem is that the way the chart of accounts exists is
> one giant hierarchy which falls down.  Most accounting systems let you
> define several "elements" to a chart of accounts.  Then you append
> those together to form "accounting strings".

Yes, as I said, this is the 1-dimensional account naming question.  It 
would be cool if Gnucash could do multiple dimensions, but can you image 
the confusion to the new user?  The tree concept is tough enough for the 
average joe (though very well handled in the docs).  This distinction is 
very common in big business.  Do they report based on lines of business, 
or based on regions?  From what I've seen, most companies do both, but 
one of them is dominant because it is the heirarchy along which the 
company's employees are organised, and along which the actual lines of 
responibility are drawn.

Actually I guess that is a bit different.  That is like two heirachies, 
where you only use one or the other at a time to get to all your 
accounts.  Your "multiple elements" way is really like two dimensions 
which both need to be specified to identify a lowest-level account.

But this is another thread which we can leave for now.


>   Often this is more a
> business level usage, but so is what you are proposing to do mapping
> of budgets to expense accounts.
>
> | Maybe *I'm* psycho and I have 100 Expense accounts but only to one
> level of depth (Expenses:whatever).  And I want to budget 70% of my
> money on "accounts that end in vowels" and 30% on "accounts that end
> in consonants".  I mean it is an obtuse example, but why should the
> design force a decision on the user that makes that impossible?
>
> Why?  To a degree financial software is different.  It isn't a window
> manager.  Letting people get "creative" with accounting isn't
> necessarily a good thing.  For example maybe I'm odd and like to
> change every other entry into a negative number eventhough I enter a
> positive number.  Not exactly the best function for an accounting
> system.  Just because you can do something, doesn't mean you should.

Well, my example was obtuse, but could still be followed consistently 
with valid accounting results.  Your "every other number" example goes 
so far as to break the results.

I know that in some cases (like double-entry) Gnucash tries to force the 
user to the more "accounting-principled" way, but I don't think it 
should in this case.


> | Maybe I talk to myself and play my own devil's advocate.  I'm
> Spartacus.  No I'm Spartacus.
>
> It is good to have discussion.  My scope is writing budget software
> for large governments dealing in billions of dollars.  All
> appropriations (spending controls) are done at the fund level (our
> focus) and have strong "commitment control" ties to them.  Analytical
> forecasting and "what if's" are done out side the maintenance of the
> budget.  There is a budget "preparation" and thtere is budget
> "maintenance".  I look at what gnucash needs to a large degree is
> basic prep (get numbers in, no drivers, no analytics) and strong
> budget maintenance.  Plan performance so to speak.

> | All four of us like Darin's direction on this point.
>
> Certainly I am not offerring to code a lick of anything.  So if you
> have willing and able coders and you all agree on something go for
> it.  I am not here to pull the discussion down or shout nasties.  This
> just happens to be what I do professionally for a day job so thought I
> would interject some real world experience.


Absolutely.  You clearly know a lot about budgetting and that real world 
perspective is great to have in this thread.  My scope is as a home user 
and small business user (but still real world, mind you :-).  I'm just 
trying to draw consensus in this discussion.

Cheers.

~Martin




More information about the gnucash-user mailing list