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.
<<snip>>
> 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?
<<snip>>
> 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 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).
>
> Geert
>
>
> * By no means am I trying to promote another accounting package here. But
> sometimes it is useful to compare how other applications in the same problem
> domain handle certain aspects of that domain.
>
>
>
_______________________________________________
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.
