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

Geert Janssens geert.gnucash at kobaltwit.be
Fri Jun 29 05:24:59 EDT 2018


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.

> Perhaps we could make it a book option?

I like the idea of a book option. For existing books it would not be set. For 
new books it would be set by default. If a user sets it for an existing book 
gnucash can check if the account hierarchy is conform with the stricter 
structure and if not propose to convert it (if that's possible; see my remark 
on stock accounts). It should report clearly to the user what was changed.

Geert




More information about the gnucash-user mailing list