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

[John Ralls]

> On Jun 29, 2018, at 2:24 AM, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
> 
> Op donderdag 28 juni 2018 19:27:47 CEST schreef John Ralls:
>>> On Jun 28, 2018, at 10:10 AM, Geert Janssens <geert.gnucash at kobaltwit.be>
>>> wrote:> 
>>> Op donderdag 28 juni 2018 18:47:18 CEST schreef Stephen M. Butler:
>>>> On 06/27/2018 04:41 PM, DaveC49 wrote:
>>>>> An active non-placeholder account should not have child/subaccounts,
>>>>> although I don't think GnuCash actually prevents this. In this case, the
>>>>> parent account total is the sum of the child subaccount totals plus the
>>>>> sum
>>>>> of any transactions into the parent account itself. This will make a
>>>>> report
>>>>> look to be incorrect as the sum of transactions into the parent account
>>>>> is
>>>>> not presented separately and its total will not be the sum of the child
>>>>> account totals. I can't think of a use case where this would be
>>>>> desirable,
>>>>> but some people may be happy with that behavior. I don't think this
>>>>> behavior has changed since I first checked it out in an earlier version
>>>>> (around 2.2 I think).
>>>> 
>>>> This is a problem.  In a good report the parent with transactions should
>>>> show a line for the parent so that the column total for that parent (on
>>>> the balance sheet) is correct.
>>> 
>>> This seems to make most sense to me:
>>> If a parent has transactions put it twice:
>>> Once as aggregate account and once as an account on it's own. That would
>>> meet both needs. The aggregate will total it's own transactions with
>>> those of its child accounts. Or put differently the aggregate account
>>> would treat itself as a child account.
>> 
>> +1
>> 
>>>> At least, as a former IT software development manager, I would insist
>>>> that a column total show all of it's inputs.
>>>> 
>>>> Maybe the financial folks can band together to get the developers to
>>>> enforce no-transactions to a parent account.
>>> 
>>> I think we should modify the concepts. "Placeholder" is ambiguous and for
>>> the lack of a better solution is has been abused to make existing
>>> accounts read- only.
>>> 
>>> Perhaps it's time to introduce a "View" type account which is only used to
>>> structure the account tree (and as aggregate account in reports) and next
>>> to that introduce a read-only attribute to normal accounts. Placeholder
>>> could then be phased out in favor of these two. We could even try to
>>> automate this using some heuristics:
>>> - if a placeholder account has no transactions, convert it into a view
>>> account - if a placeholder account does have transactions, make it
>>> read-only instead. Add in an informational message to the user about what
>>> was done so the user can make corrections if needed (like adding view
>>> accounts if an account was being used for both functions).
>> 
>> I propose that we combine “placeholder” and “hidden” to “inactive” which
>> removes an account from the picker list and from the Accounts page unless
>> “show inactive accounts” is selected from the filter.
>> 
> Something to think about as well. So that would define "inactive" as "read-
> only" (placeholder) and "hidden". I think that aligns well with other uses of 
> "Active", like for customers and vendors.
> 
> I wonder whether there are use cases for a read-only flag or hidden flag other 
> than marking an account as inactive. I'm trying to gauge the proper 
> granularity here.
> Would one want to make an account just read-only so it appears in reports but 
> can't be modified where an inactive account won't appear by default ?
> For "hidden" I think hiding can imply setting it read-only. So I don't think 
> we need separation between “hidden" and "inactive".

> 
>> While marking an account “placeholder” prevents adding transactions to it,
>> there’s no requirement in GnuCash that an account with children have the
>> placeholder flag set. To strictly follow David Cousen’s advice we’d have to
>> impose that restriction, but some users might find that a bit drastic.
> 
> To clarify I am thinking of introducing an extra account type rather than 
> continuing to use the placeholder flag. Although I'm proposing it in this 
> context I have a wider scope in mind. It would also allow more freedom in 
> restructuring account hierarchies. For example the European model of 
> structuring a chart of accounts with Active vs Passive (where Passive is the 
> subdivided in Liabilities and Equity) would become possible.
> 
> And I don't know if we currently can enforce this. Isn't there something with 
> stock accounts requiring a parent in the proper currency ? I'm not tracking 
> stock so I don't know the details there.
> 
> So at this point I would encourage where it makes sense. And set an example in 
> our account hierarchy templates. Yet using ordinary accounts as parents would 
> still be allowed. With or without the option to make them read-only.

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 don’t think that creating a generic placeholder type account that can have children of any type is a good idea, 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.

Regards,
John Ralls