[GNC] New Balsheet (and P&L report)
Christopher Lam
christopher.lck at gmail.com
Sat Jun 30 05:03:50 EDT 2018
Hi Dave
On 28/06/18 17:24, DaveC49 wrote:
> 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.
I was not describing UI restrictions; I was describing Report format.
How to report 'accounts' with children, but with their own amounts?
---Answer 1---
I had a multilevel strategy which (to me) was more clever, but it would
seem is not desired.
1. If account has children, just render its own amount (e.g.
Expenses:Utilities:Home = $10)
2. Move on to its child accounts (e.g. Expenses:Utilities:Home:Electric
= $35, Expenses:Utilities:Beachhouse:Electric = $40)
3. If we are moving to a *higher* level account, then start rendering
all intermediate sublevels will be subtotals, e.g.
Expenses = $0
Expenses:Utilities = $0
Expenses:Utilities:Home = $10 <- note this is a parent
account with own $10 amount, gets its own row
Expenses:Utilities:Home:Water = $40
Expenses:Utilities:Home:Electric = $35
TOTAL Expenses:Utilities:Home = $85
Expenses:Utilities:Beachhouse
Expenses:Utilities:Beachhouse:Electric = $40
Expenses:Utilities:Beachhouse:Water = $20
TOTAL Expenses:Utilities:Beachhouse = $60
TOTAL Expenses:Utilities = $145
However this approach seems to be adding too much complexity so I've
removed it.
---Answer 2---
In my current draft balsheet-pnl I am specifically *not* querying the
account's placeholder flag. As we know it is being used both as a
'grouping' account (e.g. Asset:Fixed) and as a 'disabled' account flag
(e.g. Asset:Closed:MyOldBank:Current).
So the above P&L will be rendered as follows:
Total Expenses:Utilities = $145
Total Expenses:Utilities:Home = $85
Expenses:Utilities:Home = $10 <-- 'parent' account with
own $10 amount
Expenses:Utilities:Home:Water = $40
Expenses:Utilities:Home:Electric = $35
Total Expenses:Utilities:Beachhouse = $60 <- parent
account without amount... it doesn't get its own row
Expenses:Utilities:Beachhouse:Electric = $40
Expenses:Utilities:Beachhouse:Water = $20
This is the 'recursive-balance' strategy. In this one, the Totals will
always be presented in the parent account.
---
Both methods are suitable for the current placeholder strategy.
> 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.
The multicolumns are only enabled if the period option allows it. It can
easily be disabled, or made off by default.
The current balance sheet has the amounts indented in a completely
unpredictable method. I cannot fix it, sorry...
Please beta test the report as it stands, or comment on the screenshots,
especially https://screenshots.firefox.com/3AGgKiSkmdebjOsf/null ...
your input is valuable. I have considered all above possibilities in
designing it, and when I came up with the 2 options it seemed to fit the
type of information obtainable from the Gnucash data format.
> 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 at 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.
More information about the gnucash-user
mailing list