Am 30.06.2018 um 22:52 schrieb John Ralls: > > >> On Jun 30, 2018, at 12:00 PM, Christian Kluge <frakturfr...@gmail.com> wrote: >> >> Am 30.06.2018 um 05:37 schrieb John Ralls: >>> >>> >>>> On Jun 29, 2018, at 3:26 PM, Christian Kluge <frakturfr...@gmail.com> >>>> wrote: >>>> >>>> Hi, >>>> >>>> Am 29.06.2018 um 19:26 schrieb John Ralls: >>>>> >>>>> >>>>>> On Jun 29, 2018, at 9:52 AM, Geert Janssens <geert.gnuc...@kobaltwit.be> >>>>>> 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 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). >>>>> >>>>> There’s been an effort over the last several years between the IASB and >>>>> the US’s FASB to reconcile IAS and US GAAP for the obvious reason that >>>>> it’s a royal PITA for international businesses to have to present their >>>>> books in different ways to different regulators. I discovered when >>>>> looking for an IAS example CoA earlier today that it’s apparently come to >>>>> fruition as IFRS and that the standard CoA doesn’t have a “Passive” >>>>> super-category [1], so perhaps the rest of the world is catching up with >>>>> GnuCash. ;-) >>>>> >>>> >>>> Not the whole world. Section 266 of the German HGB requires the balance >>>> sheet to split in active and passive and that’s how it’s displayed in >>>> every German accounting software. >>>> >>>> https://www.gesetze-im-internet.de/hgb/__266.html >>>> <https://www.gesetze-im-internet.de/hgb/__266.html> >>>> >>>> Also while you add it think about new account structures and the >>>> placeholder concept could you also consider the equivalents of the other >>>> types mentioned in the document above. >>> >>> >>> No surprise that individual country’s legislation hasn’t caught up. That >>> will likely take several more years. >> >> I hope this will never happen because the American way of doing it >> destroys the fundamental aesthetic of the balance sheet, that there two >> numerically identical sides which have just one top label each. >> >>> I don’t see any account types there other than the Active/Passive sections >>> that GnuCash doesn’t already support. What I can’t figure out is what parts >>> of the CoA small companies are allowed to leave out. (And no, my German >>> isn’t good enough to thoroughly read the document. I used Google translate >>> and so I may have gotten some of it wrong.) >> >> To summarize which sections each company type has to use: >> >> micro-entities: capital letters >> small sized: capital letters + Roman numerals >> medium sized and large: capital letters + Roman numerals + numbers > > Thanks. > So it's just that larger companies have to report more detail? >
There are some exceptions, like limited partnerships with a limited liability company as general partner (GmbH & Co. KG) being required to list a more detailed break-down of their equity regardless of their size and stock market oriented companies always being treated as large companies but basically yes, the larger the company the more detailed the reports have to be. 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.