Budgeting prototype

[Derek Neighbors]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

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.

| 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, 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.  We do
however revolve ourselves around the "fund" element for the most part
because that is our "driving model".

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

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

| 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQE/WLWKHb99+vQX/88RAlx1AJ0ZSBdhlKPkgGjq9fRuqpIB/HWgZQCfSdc6
wFLwmF4Pi8cRzf1jTSfnNw8=
=wdmp
-----END PGP SIGNATURE-----