Christopher, " except that Placeholder accounts can also contain transactions therefore must not necessarily accumulate their children account amounts. "
I have to disagree with the above from an accounting perspective. If accounts are setup as Placeholders initially (i.e. the checkbox set in New Account dialog when they are created) they are readonly hence you cannot select them as targets for transactions (Placeholders do not appear in the list of target accounts for a transaction and if you open the account register you are warned that it is read only and you cannot enter transactions from it so they cannot accumulate any balance when they are initially set as Placeholder accounts. If you change an existing account to be a Placeholder and it already has transactions into it then its balance will contain the sum of those transactions. If you then createa sub account of it and create transactions into the sub-account, then the balance of the parent placeholder account balance is correctly the sum of the balances of any sub accounts plus the sum of any transactions into it before it was changed to a placeholder. If it was initially a placeholder, a user could subsequently change it to be a non-placeholder account allowing it to accumulate transactions into it and subsequently change it back. In either of these two cases, the correct balance for the placeholder account is always the balance of any transactions into the placeholder account itself plus the sum of balances of it's sub-accounts. In most accounting practice the balances of the subaccounts would be indented to the right. To maintain consistency with this practice, if it is possible you could present the balance of any direct transactions to the placeholder account indented in the same manner as the sub-accounts as if it was a sub-account and then have the non-indented balance for the placeholder account being the sum of that plus the balances of any subaccounts. Where you are trying to create a multicolumn/multiperiod type report, which I have gathered is your objective, having to have indented sub-accounts will make it very complex and difficult to fit on a fixed page size if you have to preserve indenting of the sub-account structure. I would like to plead that the current Balance and Income Statements and other standard accounting reports not be replaced by a multiperiod report, but that this become an additional optional report. Gnucash is used in many different jurisdictions not all of which have as yet adopted the IFRS produced by the IASB. (The US while moving towards the IFRS uses a GAAP which is not yet compliant). Even if this were the case, many jurisdictions still have local divergences from strict IFRS adherence because of the need to be consistent with other laws in their jurisdiction. Having fairly plain vanilla single period reports which users can then produce customised versions for their specific requirements is fairly essential to meet the need to operate across many jurisdictions, which is one of GnuCash's strengths. That may be more difficult to do with a multiperiod report. A cautious user would hopefully not create the situation where placeholder accounts have transactions into them, but Murphy's law applies and if it can happen it no doubt will and does. The case where after a given date company or reporting policy requires a more detailed breakdown with sub-accounts but prior to that date there was only a single account is one situation where transactions to a parent account might occur. I personally would treat that by creating a sub-account for all transactions into the original account prior to that date to which all existing transactions could be transferred along with the sub-accounts for the future reporting structure for future transactions. At some point in the future that sub-account with the original parent account transactions could possibly be hidden, but the data is still preserved. It would be ideal perhaps if Gnucash on creation of a subaccount required the parent account to be made a placeholder and any existing transactions transferred to either that subaccount (or another appropriate account) but that is not built in currently. There may be other use cases where this is not desirable however. regards 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.
