Stephen John, Geert
In accounting terms there are really only 3 basic account types:
Asset
Liability
Equity
These all *must *satisfy the basic accounting equation Assets=Liabilities
+Equity.
The two sides of this equation are what the German /European system defines
as Activa and Passiva but these groupings are primarily reporting
requirements not account heirarchy. Is there really a need to have an
additional placeholder category as the reporting grouping can be readily
defined from the existing basic account heirarchy structure?
Each type can have function specific sub-types which impose functional
restrictions for that subtype and where the children but these subtypes are
always one of the above basic types. Children of the types and sub-types
must conform to the restriction that they have the same type or subtype as
the parent E.g.
Asset
Top level placeholder
Current
placeholder
Bank
Accounts-Receivable
business - no children
Stock
Trading
Non-current
placeholder
Liability
Top level placeholder
Accounts payable
business functionality-no children
Equity
Top level placeholder
Income
Current period revenue placeholder
Expenses
Current period expenditure placholder
My experimentation and what I have understood of the code is this is already
what GnuCash imposes in its account heirarchy with the exception perhaps
that Income and Expenses are treated as their own types and the Equity type
is enforced in any end of period closing operations and/or in the reporting
and the expanded version of the accounting equation is enforced in the code.
Assets=Liabilities + Equity + Income - Expenses
For business purposes it is usually a requirement that each legal entity
should have it's own set of books. I handle the situation where I need to
separate different individual contributions within an entity in the manner
John suggested (e.g. a household or a partnership) with labelled subaccounts
within each type as defined above. If there really is a need to fully
separate the individuals in terms of separately recording assets,
liabilities and equity, then it is appropriate to run a separate set of
books.
I think it would be useful/nice to clearly document somewhere, perhaps the
wiki, what the existing account structure is at this point and what
attributes accounts currently have and what their intended purpose is from
the developers point of view as well as the other unintended uses that the
user base can come up with. That could then provide a basis for looking at
restructuring those attributes. Something like the design documents that
were produced at times in the past. This would also give the documenters a
chance to reflect that in the documentation.
David Cousens
-----
David Cousens
--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html
_______________________________________________
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
