[GNC] Rethinking the placeholder account concept (was: Re: Fwd: The two modules)

[Geert Janssens]

Op vrijdag 29 juni 2018 16:59:07 CEST schreef John Ralls:
> Stock accounts need to have a parent denominated the currency in which the
> stock trades in order for the asset roll-up to work correctly on the
> Accounts page. Three-commodity transactions are possible using trading
> accounts, but I haven’t dealt with that stuff in a while and the details
> have gone fuzzy on me.
> 
> Stock accounts aside, let’s not conflate different purposes. We *should*
> have an account type to accommodate the European Passive account with
> Liability and Equity children, so let’s create that. We’ll need to tweak
> some of the reports a bit to accommodate it, but otherwise it won’t have
> much impact. It should, of course, be what we now call a placeholder and it
> should be able to have only Root as a parent and only one each Liability
> and Equity placeholder children.
> 
I was in fact deliberately trying to come up with a solution that's more 
flexible than fitting the currently known use cases. The European Passive 
account was just one example.

However we may be spending more time on it than necessary. I checked in the 
current version of the commercial accounting package* I also have to deal with 
and it doesn't define a Passive type at all. "Passive" it doesn't even appear 
on its default balance sheet. That is a bit uncommon though as the reports I 
get from my accountant do have a passive section. However just like gnucash 
this package is targeting a worldwide audience (though with country specific 
extensions). That may explain why they didn't bother adding the Passive 
section.

Let me add that contrary to other accounting packages I have played with in 
gnucash the chart of accounts takes a very central place. So whether or not we 
want our own Passive type to group liabilities and equity hierarchically on 
the chart of accounts as well is up for debate.

> I don’t think that creating a generic placeholder type account that can have
> children of any type is a good idea,

Here's another example: a household that wants to  track its finances, but 
would want to keep separate account hierarchies per family member. Standard 
response: create two files. However they would benefit from common reporting 
which is cumbersome with two separate files. So what if we would allow to 
create two independent account hierarchies in one file. With a view type 
account one could create two top-levels ("Husband" and "Wife") and create a 
independent hierarchy for each. While this could also be solved if we would 
allow multiple root accounts and make that root visible I'm using it here to 
illustrate there are use cases we are not covering well.

I borrowed the idea of a view type account from an old version of the 
commercial package* we have to use. Looking more closely it turns out the 
current version has dropped view accounts and instead is organizing charts/
reports using a combination of account type (roughly like we do) and 
hierarchical account numbers. So I must admit perhaps the idea was not so 
bright after all :)

The package also doesn't have a hierarchical account tree. It's flat and 
hierarchy is only added in reports as explained above. So there is no such 
thing as a parent account in that package and hence no restriction on which 
account type a certain account can be.

Again in gnucash the chart of accounts is very central and visible so we 
probably shouldn't drop its hierarchical structure just yet.

The downside of this hierarchical structure is then of course we have to think 
about issues like  whether or not we should allow accounts to have any type of 
child or not. I believe parts of gnucash rely on this (I seem to remember a 
relatively recent issue in the export code that it didn't find all liability 
accounts if they had a non-liability parent or such).

> and I think that we already have too
> many overlapping account types with subtle behavior differences that are
> neither documented nor easily discoverable in code.
> 
I'm all for clearing this up. If we can reduce the number of account types 
that would be great. 
For reference this is the list of 17 account types supported by the commercial 
package*:
Receivable, payable, bank and cash (one type), current assets, non-current 
assets, prepayments, fixed assets, current liabilities, non-current-
liabilities, equity, current year earnings, other income, income, 
depreciation, expenses, cost of revenue, credit card.

Gnucash currently has 15 of which a few are internal only:
Bank, cash, credit, asset, liability, stock, mutual, currency, income, 
expense, equity, receivable, payable, root and trading.



The leftovers from this long discussion for immediate use may be summarized 
as:
- on reports display placeholder accounts once as aggregate account and once 
as its own account if it has splits.
- work to be more pedantic about the meaning of "placeholder". It should 
become an empty account used for structuring the account hierarchy and for 
collecting (sub)totals.
- introduce a read-only status for accounts one doesn't want to accidentally 
modify, but that should still appear in the chart of accounts in various 
places
- replace "hidden" combined with current "placeholder" with "inactive".
- consider introducing a passive account type to be able to structure the 
chart of accounts and reports conform European habits.
- think of ways to have more than one chart of account in one file (only 
mentioned first in this message).

Geert


* By no means am I trying to promote another accounting package here. But 
sometimes it is useful to compare how other applications in the same problem 
domain handle certain aspects of that domain.