> 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?

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.

Reply via email to