parent accounts, groups, and classes

[Dave Peticolas]

David Merrill writes:
> On Thu, Dec 21, 2000 at 04:34:00PM -0800, Dave Peticolas wrote:
> > David Merrill writes:
> > > In light of the discussions we have been having over whether the
> > > account group mechanism should be strictly hierarchical or whether an
> > > account should be allowed to exist within more than one group, I am
> > > considering providing both capabilities in the database.
> > > 
> > > First, the group table would define groups. Each group would
> > > contain arbitrary accounts, and accounts can belong to more than one
> > > group via a third table, account_group.
> > > 
> > > Second, the class table would define classes. Each class would contain
> > > arbitrary accounts, but an account can belong to one and only one
> > > class. Possibly, every account must belong to one class or another.
> > > 
> > > These are implemented independently of the GUI, so the GUI can make
> > > use of either or both of these mechanisms as it sees fit. It is easy
> > > enough for me to do both rather than choose one.
> > > 
> > > Regarding the parent account mechanism, can someone please explain to
> > > me what this does for us that the account group mechanism above
> > > doesn't? Are we actually using the account "tree" that it results in,
> > > or just using it as another way to group accounts, where the top level
> > > account is a dummy account?
> > 
> > I'm not sure what you mean here. In the engine, the parent account
> > mechanism is the group mechanism. There is no other way to specify
> > subaccounts other than through groups.
> 
> Somewhere or other I picked up the idea that an account could have a
> "parent" account. Evidently I misread something. Perhaps the gnucash
> code made reference to a parent account and I didn't realize it was
> the same thing as the group? I dunno, and it doesn't matter now
> anyway.

In the diagram:

           A1
           |
           G
          / \
         A2  A3

A1 is the parent account of A2 and A3.


> If I provide the functionality described above, will that meet the
> engine's requirements? That's what I really want to know.

Yes, I believe so, provided that groups (classes) can have sub-groups
(sub-classes).

dave