[GNC] New Balsheet (and P&L report)

Sat Jun 30 08:42:21 EDT 2018

Latest iteration of balsheet-pnl
https://screenshots.firefox.com/SzeQeQcyTTTGtb1a/null

Rules:
1. All totals will now be shown by the parent account - i.e. the first row
"Asset" has all asset amounts combined.
2. Every account-with-children will be bold and annotated "Total for ..."
to indicate this is an aggregate amount. See "Total Broker 200FUND + $2000"
3. Every account-with-children-with-own-amounts will have that amount shown
underneath the above aggregate. See "Broker $2000"
4. Account without children will be shown similar as 3. See "Broker:Stock
200FUND"

I dare say this strategy is much clearer than the existing balance sheet
reports.
C

On 30 June 2018 at 17:03, Christopher Lam <christopher.lck at gmail.com> wrote:

> 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.h
>> tml
>> _______________________________________________
>> 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.
>>
>
>