> On Jun 29, 2018, at 2:24 AM, Geert Janssens <geert.gnuc...@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.gnuc...@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 _______________________________________________ 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.