Budgeting prototype

[marthter]

Derek Neighbors wrote:

> marthter wrote:
>
> |> 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
>
>
> Yes possibly too much so, and why I stated I didn't want to impede
> discussions if everyone else was running a single way.
>
> | 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?
>
> Do be perfectly clear.  Forcing people to only be able to budget to
> existing accounts has nothing to do with being able to edit their
> budget in the middle of a cycle.

Yes, you're right, we're agreeing here.  That is why I listed those as 
two separate design questions that need to be answered (see (1) and (2) 
below).  I'm not debating whether the accounts to which you budget 
should exist (I agree they should), just whether a single budget item 
should necessarily be ONLY to a single account (I agree, NORMALLY they 
would, but it shouldn't FORCE that to be the case).

>   Those features are not mutually
> exclusive.  The systems I write force people to only use accounts that
> already exist in the financial system.  However, they can change their
> budget every day.  Also, it is MANDATORY in our system to maintain
> different "versions".  It works something like this....
>
> You build your budget and save that version.  In our case we call it
> "adopted", because the board of supervisors actually adopts it as a
> plan.  You could call it "Original" or something.  This is the budget
> that NEVER changes after you create it.  Then you have your "REVISED"
> budget.  This is the budget that during the year you tweak as things
> happen.. like pay raises, unforeseen necessities, raised utility rates
> etc....  Then you have a "PROJECTED" version.  This is basically your
> ACTUALS for months that have "closed" and your "REVISED" budget for
> months that are "open".
>
> This type of versioning now allows you to see how you did against your
> original plan (Adopted/Original), see how you plan to spend based on
> some moving factors (Revised) and see how you are spending and how
> that makes things look with your budget as you have it laid out
> (Projected).

This elaboration is very illuminating.  These would be good concepts to 
include in the design, or at least design with them in mind for future 
iterations.


> Again the original gripe about mapping accounts is independent of
> being able to modify the budget throughout the year and independent of
> having multiple version (some times called scenarios)
>
> | 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 budgeting period.
>
> I am not sure I agree with point 1.  Yes you need to include number 2
> and add a number 3 (Ability to have multiple versions)
>
> | 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.
>
> No this is another problem you will introduce when you do budgeting.
> :)  That is multiple year comparatives.  What happens when you decide
> to "inactivate" an account.  There needs to be a way to do
> "restatements".  That is allow you to change your chart of accounts
> from year to year and then "map" an old year to a new year (for
> reporting only).  That is if you mapped as you want your budget, but
> did not have a mechanism to do actuals the same way.  Your historical
> budget to actual reports would be fairly whacked.  What I would
> propose is you fix your chart of accounts.  (i.e. inactivate the old
> accounts, make the new accounts) Then charge in the new year to proper
> accounts and build budget properly.  Then in the reporting side have a
> way to do restatements that say x goes to y.

This would be ideal but I think outside the scope of what Gnucash should 
attempt.  And "fixing" my chart of accounts by closing accounts with 5 
years of data is outside what I'd like to attempt, yet, I'd still like 
the flexibility to budget with either focus (the medical/transport focus 
or the him/her focus).

> | 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.
>
> I am not saying that.  I stated in my last mail if you all are in
> agreement and have someone ready to code it by all means do so.   In
> fact, if anything the impression I get is one that says... "Everyone
> thinks we should do X, so we are going to do X."  I hope this
> discussion has not been interpreted as saying no way in hell do X.  It
> is merely a discussion.  I will be happy to see budgeting in about any
> way shape form it is done.

Yes, this sentiment I agree with.  The way it is shaping up, Darin's 
proposal seems flexible enough to handle your way of doing things and my 
hypothetical/obtuse examples too.


> | 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
> hierarchy along which the company's employees are organised, and along
> which the actual lines of responibility are drawn.
>
> Yes.  I stated in this mail that it's probably more a "business"
> feature to have account segments.  You are absolutely correct that its
> common to report on different elements.  Currently I think we deal
> with 8 elements in our chart of accounts with each element have 5
> nested hierarchy levels for different types of reporting.

Wow, interesting.  I can't imagine all 8 elements are independant (in 
the algebraic sense).  I mean, you don't have to give an ordered 
octuplet to fully specify which account you are talking about, do you?

>   We do
> however revolve ourselves around the "fund" element for the most part
> because that is our "driving model".

I think this almost answers the above question, but I'd be curious anyway.


> | 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.
>
> It gets uglier than that, but when you encompass the way of thinking
> its rather powerful.

Yes, I can see it would be very useful.


> | But this is another thread which we can leave for now.
>
> I agree.
>
> | 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.
>
> Yes I was being factious to try to go out of the way to prove a point
> that accounting is much more finite in it's rules.  Some times we can
> do some things that can get what we think is a good intended result,
> but in reality is not.  I think the phrase is something like... "give
> them enough rope to hang themselves with"

Yes, or "Figures don't lie, but liars can figure."

I think in fact we are pretty close to being on the same page, perhaps 
some terminology is still making it appear the gap is bigger than it 
is.  As you say, this is just my two cents, and more power to whoever 
will take this by the horns and provide something (besides talk) to the 
project.

Cheers.

~Martin


> | 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.
> |
> That is fair and a really good assessment of my point.  That is, you
> can do budgeting in a "looser" way (read I'm not saying evil or
> completely wrong etc) or in a "stricter" way.  Much in the same way
> you can do double entry (strict) or quicken style (loose).  Because
> people don't think like accountants generally stricter ways impose a
> greater learning curve.  However, they do have benefits.
>
> | 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.
>
> This brings my last question/gripe probably more for Linas/Derek.
> That is what is GNUCash's focus?  Are you aiming at "home user",
> "small business", "medium business", "stock application"?  If the goal
> is home user.. I would lean more toward loose models of accounting..
> Ease of use is important there... Small business I would still keep an
> ease of use focus, but try to instill good accounting principles..
> Anything beyond small business I would really try to follow best
> accounting practices of FASB, GAAP and GFOA.
>
> My two cents.
>
> Derek Neighbors
> GNU Enterprise
> http://www.gnuenterprise.org
> derek at gnue.org