Re: [GNC] Rethinking the placeholder account concept (was: Re: Fwd: The two modules)
Am 02.07.2018 um 03:05 schrieb Christopher Lam: > Discussions are useful; but would anyone have an idealised template, or > sample output that the balance sheet should produce? Idealy with the > 'account-has-children-and-amounts' peculiarity? > The balsheet in development will, ideally, replace the current (non-eguile) > one. As I’ve written before the template for a German balance sheet is defined in § 266 HGB, but I don’t feel able to provide the English translations. Regards Christian ___ 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.
Re: [GNC] Rethinking the placeholder account concept (was: Re: Fwd: The two modules)
On 07/01/2018 06:05 PM, Christopher Lam wrote: > Discussions are useful; but would anyone have an idealised template, or > sample output that the balance sheet should produce? Idealy with the > 'account-has-children-and-amounts' peculiarity? > The balsheet in development will, ideally, replace the current (non-eguile) > one. > The existing one has amounts in the wrong columns, inflexible accountnames, > no multiple date points reporting, no linkage with other reports. > C Say the broker account has some activity (cash- $200) and also has Stock of $250 and Bonds of $150. Assets y Broker $200 Stock $250 Bonds $150 -- $600 xx > > On 2 July 2018 at 03:18, Christian Kluge wrote: > >> Am 01.07.2018 um 01:57 schrieb DaveC49: >>> Stephen John, Geert >>> >>> In accounting terms there are really only 3 basic account types: >>> Asset >>> Liability >>> Equity >>> >>> These all *must *satisfy the basic accounting equation Assets=Liabilities >>> +Equity. >>> >>> The two sides of this equation are what the German /European system >> defines >>> as Activa and Passiva but these groupings are primarily reporting >>> requirements not account heirarchy. Is there really a need to have an >>> additional placeholder category as the reporting grouping can be readily >>> defined from the existing basic account heirarchy structure? >>> >> In the German system active and passive are seen as the fundamental >> account types. In the end it leads to the same result, but I get your >> point of view. >> >> Hovever I would suggest make changes to the balance sheet report to be >> able to produce European reports. >> >> Regards, >> >> >> Christian Kluge >> >> ___ >> 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. >> > ___ > 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. > -- Stephen M Butler, PMP, PSM stephen.m.butle...@gmail.com kg...@arrl.net 253-350-0166 --- GnuPG Fingerprint: 8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8 ___ 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.
Re: [GNC] Rethinking the placeholder account concept (was: Re: Fwd: The two modules)
Discussions are useful; but would anyone have an idealised template, or sample output that the balance sheet should produce? Idealy with the 'account-has-children-and-amounts' peculiarity? The balsheet in development will, ideally, replace the current (non-eguile) one. The existing one has amounts in the wrong columns, inflexible accountnames, no multiple date points reporting, no linkage with other reports. C On 2 July 2018 at 03:18, Christian Kluge wrote: > Am 01.07.2018 um 01:57 schrieb DaveC49: > > Stephen John, Geert > > > > In accounting terms there are really only 3 basic account types: > > Asset > > Liability > > Equity > > > > These all *must *satisfy the basic accounting equation Assets=Liabilities > > +Equity. > > > > The two sides of this equation are what the German /European system > defines > > as Activa and Passiva but these groupings are primarily reporting > > requirements not account heirarchy. Is there really a need to have an > > additional placeholder category as the reporting grouping can be readily > > defined from the existing basic account heirarchy structure? > > > > In the German system active and passive are seen as the fundamental > account types. In the end it leads to the same result, but I get your > point of view. > > Hovever I would suggest make changes to the balance sheet report to be > able to produce European reports. > > Regards, > > > Christian Kluge > > ___ > 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. > ___ 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.
Re: [GNC] Rethinking the placeholder account concept (was: Re: Fwd: The two modules)
Am 01.07.2018 um 01:57 schrieb DaveC49: > Stephen John, Geert > > In accounting terms there are really only 3 basic account types: > Asset > Liability > Equity > > These all *must *satisfy the basic accounting equation Assets=Liabilities > +Equity. > > The two sides of this equation are what the German /European system defines > as Activa and Passiva but these groupings are primarily reporting > requirements not account heirarchy. Is there really a need to have an > additional placeholder category as the reporting grouping can be readily > defined from the existing basic account heirarchy structure? > In the German system active and passive are seen as the fundamental account types. In the end it leads to the same result, but I get your point of view. Hovever I would suggest make changes to the balance sheet report to be able to produce European reports. Regards, Christian Kluge ___ 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.
Re: [GNC] Rethinking the placeholder account concept (was: Re: Fwd: The two modules)
Am Samstag, 30. Juni 2018, 05:37:28 CEST schrieb John Ralls:
> > On Jun 29, 2018, at 3:26 PM, Christian Kluge
> > wrote:
> >
> > Hi,
> >
> > Am 29.06.2018 um 19:26 schrieb John Ralls:
> >>> On Jun 29, 2018, at 9:52 AM, Geert Janssens
> >>> wrote:>>>
> >>> 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,
Re: [GNC] Rethinking the placeholder account concept (was: Re: Fwd: The two modules)
Stephen John, Geert In accounting terms there are really only 3 basic account types: Asset Liability Equity These all *must *satisfy the basic accounting equation Assets=Liabilities +Equity. The two sides of this equation are what the German /European system defines as Activa and Passiva but these groupings are primarily reporting requirements not account heirarchy. Is there really a need to have an additional placeholder category as the reporting grouping can be readily defined from the existing basic account heirarchy structure? Each type can have function specific sub-types which impose functional restrictions for that subtype and where the children but these subtypes are always one of the above basic types. Children of the types and sub-types must conform to the restriction that they have the same type or subtype as the parent E.g. Asset Top level placeholder Current placeholder Bank Accounts-Receivable business - no children Stock Trading Non-current placeholder Liability Top level placeholder Accounts payable business functionality-no children Equity Top level placeholder Income Current period revenue placeholder Expenses Current period expenditure placholder My experimentation and what I have understood of the code is this is already what GnuCash imposes in its account heirarchy with the exception perhaps that Income and Expenses are treated as their own types and the Equity type is enforced in any end of period closing operations and/or in the reporting and the expanded version of the accounting equation is enforced in the code. Assets=Liabilities + Equity + Income - Expenses For business purposes it is usually a requirement that each legal entity should have it's own set of books. I handle the situation where I need to separate different individual contributions within an entity in the manner John suggested (e.g. a household or a partnership) with labelled subaccounts within each type as defined above. If there really is a need to fully separate the individuals in terms of separately recording assets, liabilities and equity, then it is appropriate to run a separate set of books. I think it would be useful/nice to clearly document somewhere, perhaps the wiki, what the existing account structure is at this point and what attributes accounts currently have and what their intended purpose is from the developers point of view as well as the other unintended uses that the user base can come up with. That could then provide a basis for looking at restructuring those attributes. Something like the design documents that were produced at times in the past. This would also give the documenters a chance to reflect that in the documentation. David Cousens - David Cousens -- Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html ___ 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.
Re: [GNC] Rethinking the placeholder account concept (was: Re: Fwd: The two modules)
Am 30.06.2018 um 22:52 schrieb John Ralls:
>
>
>> On Jun 30, 2018, at 12:00 PM, Christian Kluge wrote:
>>
>> Am 30.06.2018 um 05:37 schrieb John Ralls:
>>>
>>>
On Jun 29, 2018, at 3:26 PM, Christian Kluge
wrote:
Hi,
Am 29.06.2018 um 19:26 schrieb John Ralls:
>
>
>> On Jun 29, 2018, at 9:52 AM, Geert Janssens
>> wrote:
>>
>> 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
Re: [GNC] Rethinking the placeholder account concept (was: Re: Fwd: The two modules)
> On Jun 30, 2018, at 12:00 PM, Christian Kluge wrote:
>
> Am 30.06.2018 um 05:37 schrieb John Ralls:
>>
>>
>>> On Jun 29, 2018, at 3:26 PM, Christian Kluge wrote:
>>>
>>> Hi,
>>>
>>> Am 29.06.2018 um 19:26 schrieb John Ralls:
> On Jun 29, 2018, at 9:52 AM, Geert Janssens
> wrote:
>
> 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
Re: [GNC] Rethinking the placeholder account concept (was: Re: Fwd: The two modules)
Am 30.06.2018 um 05:37 schrieb John Ralls:
>
>
>> On Jun 29, 2018, at 3:26 PM, Christian Kluge wrote:
>>
>> Hi,
>>
>> Am 29.06.2018 um 19:26 schrieb John Ralls:
>>>
>>>
On Jun 29, 2018, at 9:52 AM, Geert Janssens
wrote:
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
Re: [GNC] Rethinking the placeholder account concept (was: Re: Fwd: The two modules)
> On Jun 29, 2018, at 3:26 PM, Christian Kluge wrote:
>
> Hi,
>
> Am 29.06.2018 um 19:26 schrieb John Ralls:
>>
>>
>>> On Jun 29, 2018, at 9:52 AM, Geert Janssens
>>> wrote:
>>>
>>> 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
Re: [GNC] Rethinking the placeholder account concept (was: Re: Fwd: The two modules)
Hi,
Am 29.06.2018 um 19:26 schrieb John Ralls:
>
>
>> On Jun 29, 2018, at 9:52 AM, Geert Janssens
>> wrote:
>>
>> 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
Re: [GNC] Rethinking the placeholder account concept (was: Re: Fwd: The two modules)
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
Re: [GNC] Rethinking the placeholder account concept (was: Re: Fwd: The two modules)
On 06/29/2018 09:52 AM, Geert Janssens wrote:
> 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.
I have been reading up on trading accounts and the similarity between
currencies and stock. Essentially stock is just a different currency
with an exchange rate that changes much to fast!
>>
>> 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.
To my way of thinking, if you want total flexibility, you should be able
to define your top level accounts and name them according to your
language and custom.
Hence, for me:
Assets
Liabilities
Equity
Income
Expense
For friends across the big ocean:
Activa
Assets
Expense
Passiva
Libilities
Equity
Income
(At least I think that is how they organize them.)
Each top level would need an indicator whether it is normally a Debit or
Credit account.
<>
> 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.
Not sure how:
WIFE
HUSBAND
would fit in as top level accounts though. I would think, at a minimum,
they would be sub-accounts with the top level -- else how could you
combine all the assets together for a total?
Then again, with total flexibility, how do you define the generally
accepted accounting formulas?
<>
> 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.
And figuring out when to use which is hard enough without adding more.
Maybe some of these should become indicators rather than account types
and revert back to just the 5 basic?
> 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
Re: [GNC] Rethinking the placeholder account concept (was: Re: Fwd: The two modules)
> On Jun 29, 2018, at 9:52 AM, Geert Janssens
> wrote:
>
> 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
Re: [GNC] Rethinking the placeholder account concept (was: Re: Fwd: The two modules)
> On Jun 29, 2018, at 2:24 AM, Geert Janssens > wrote: > > Op donderdag 28 juni 2018 19:27:47 CEST schreef John Ralls: >>> On Jun 28, 2018, at 10:10 AM, Geert Janssens >>> 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
[GNC] Rethinking the placeholder account concept (was: Re: Fwd: The two modules)
Op donderdag 28 juni 2018 19:27:47 CEST schreef John Ralls: > > On Jun 28, 2018, at 10:10 AM, Geert Janssens > > 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
