[GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

classic Classic list List threaded Threaded
49 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

Christopher Lam
Hi All

I'm working through balance-sheet.scm and overhauling this report.

At the same time, I can see that balance-sheet.scm and
income-statement.scm can be merged together.

After all

  * balance sheet = asset/liability/equity balance at date X,
  * income statement = difference in income/expense balances at date X and Y

The issue I have is that the balance sheet can call
xaccAccountGetBalanceAsOfDate(acc,date) directly to nicely retrieve the
balance, whereas income statement cannot directly call it because it
also includes closing transactions.

My proposal is to augment xaccAccountGetBalanceAsOfDate to accept a 3rd
boolean argument i.e.
xaccAccountGetBalanceAsOfDate(acc,date,ignoreclosing) which will
selectively produce the balance, ignore closing transactions.

This is partly done in the last commit of
https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances 
- it will augment API everywhere, and also modify Account.cpp,
especially xaccAccountRecomputeBalance which will call
xaccTransGetIsClosingTxn(xaccSplitGetParent(split)) for each split in
the account to determine closing status and cache the balances for each
split. See draft on
https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances 
- this currently fails because I'm not good at C.

*My query is whether it will be too expensive to call
xaccTransGetIsClosingTxn for each split in Account.cpp to produce the
split->noclosing_balance, which will be crucial to calculate income
between two dates.*

*Currently this 'closing-txn' filter is done in income-statement.scm via
a "Closing Entries" string/regex filter and xaccTransGetIsClosingTxn
calls, which IMHO is not ideal either.
*

Any help welcome!

P.S. if this last commit is removed, the
https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances 
branch contains work-so-far for updated balance-sheet. Screenshot
https://screenshots.firefox.com/eelmGQrGCtcP6bqC/null - see the
multilevel subtotals were previously horizonal, are now vertical;
original-currency amounts, and multiple-date balance sheets.

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

John Ralls


> On Jun 22, 2018, at 9:42 PM, Christopher Lam <[hidden email]> wrote:
>
> Hi All
>
> I'm working through balance-sheet.scm and overhauling this report.
>
> At the same time, I can see that balance-sheet.scm and income-statement.scm can be merged together.
>
> After all
>
> * balance sheet = asset/liability/equity balance at date X,
> * income statement = difference in income/expense balances at date X and Y
>
> The issue I have is that the balance sheet can call xaccAccountGetBalanceAsOfDate(acc,date) directly to nicely retrieve the balance, whereas income statement cannot directly call it because it also includes closing transactions.
>
> My proposal is to augment xaccAccountGetBalanceAsOfDate to accept a 3rd boolean argument i.e. xaccAccountGetBalanceAsOfDate(acc,date,ignoreclosing) which will selectively produce the balance, ignore closing transactions.
>
> This is partly done in the last commit of https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances - it will augment API everywhere, and also modify Account.cpp, especially xaccAccountRecomputeBalance which will call xaccTransGetIsClosingTxn(xaccSplitGetParent(split)) for each split in the account to determine closing status and cache the balances for each split. See draft on https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances - this currently fails because I'm not good at C.
>
> *My query is whether it will be too expensive to call xaccTransGetIsClosingTxn for each split in Account.cpp to produce the split->noclosing_balance, which will be crucial to calculate income between two dates.*
>
> *Currently this 'closing-txn' filter is done in income-statement.scm via a "Closing Entries" string/regex filter and xaccTransGetIsClosingTxn calls, which IMHO is not ideal either.
> *
>
> Any help welcome!
>
> P.S. if this last commit is removed, the https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances branch contains work-so-far for updated balance-sheet. Screenshot https://screenshots.firefox.com/eelmGQrGCtcP6bqC/null - see the multilevel subtotals were previously horizonal, are now vertical; original-currency amounts, and multiple-date balance sheets.
>
> _

Chris,

Only profiling will tell how much of a performance hit this creates.

I don’t see where in your commit you’re computing the split’s no-closing balance. Perhaps that’s why it doesn’t work?

Regards,
John Ralls
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

Christopher Lam
Hi John, the split->noclosing_balance is updated in
xaccAccountRecomputeBalance. Will continue copypasta coding until it works!

On Sat, 23 Jun 2018, 23:56 John Ralls <[hidden email]> wrote:

>
>
> > On Jun 22, 2018, at 9:42 PM, Christopher Lam <[hidden email]>
> wrote:
> >
> > Hi All
> >
> > I'm working through balance-sheet.scm and overhauling this report.
> >
> > At the same time, I can see that balance-sheet.scm and
> income-statement.scm can be merged together.
> >
> > After all
> >
> > * balance sheet = asset/liability/equity balance at date X,
> > * income statement = difference in income/expense balances at date X and
> Y
> >
> > The issue I have is that the balance sheet can call
> xaccAccountGetBalanceAsOfDate(acc,date) directly to nicely retrieve the
> balance, whereas income statement cannot directly call it because it also
> includes closing transactions.
> >
> > My proposal is to augment xaccAccountGetBalanceAsOfDate to accept a 3rd
> boolean argument i.e. xaccAccountGetBalanceAsOfDate(acc,date,ignoreclosing)
> which will selectively produce the balance, ignore closing transactions.
> >
> > This is partly done in the last commit of
> https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
> - it will augment API everywhere, and also modify Account.cpp, especially
> xaccAccountRecomputeBalance which will call
> xaccTransGetIsClosingTxn(xaccSplitGetParent(split)) for each split in the
> account to determine closing status and cache the balances for each split.
> See draft on
> https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
> - this currently fails because I'm not good at C.
> >
> > *My query is whether it will be too expensive to call
> xaccTransGetIsClosingTxn for each split in Account.cpp to produce the
> split->noclosing_balance, which will be crucial to calculate income between
> two dates.*
> >
> > *Currently this 'closing-txn' filter is done in income-statement.scm via
> a "Closing Entries" string/regex filter and xaccTransGetIsClosingTxn calls,
> which IMHO is not ideal either.
> > *
> >
> > Any help welcome!
> >
> > P.S. if this last commit is removed, the
> https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
> branch contains work-so-far for updated balance-sheet. Screenshot
> https://screenshots.firefox.com/eelmGQrGCtcP6bqC/null - see the
> multilevel subtotals were previously horizonal, are now vertical;
> original-currency amounts, and multiple-date balance sheets.
> >
> > _
>
> Chris,
>
> Only profiling will tell how much of a performance hit this creates.
>
> I don’t see where in your commit you’re computing the split’s no-closing
> balance. Perhaps that’s why it doesn’t work?
>
> Regards,
> John Ralls
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

Christopher Lam
I think I'll forego a noclosing_balance upgrade in C.

According to https://bugzilla.gnome.org/show_bug.cgi?id=570042 the
"Closing Entries" transactions did not always receive a special
KVP-based flag until the commit on
https://github.com/Gnucash/gnucash/commit/4b2800145 on datafiles
generated from 27-11-2008 and later.

So, to find and exclude these closing entries, we can use the following
strategies:

 1. xaccTransGetIsClosingTxn, will query the KVP flag
 2. Run a QofQuery and add xaccQueryAddClosingTransMatch (also queries
    the KVP flag)
 3. Free-text search "Closing Entries" to seek these old closing entries

So a P&L report will necessarily need to do both filtering for KVP and
free-text search.

The multicolumn report will be different enough from the old
balance-sheet and income-statement that I think I should spin it off
into a different report altogether, and the others will be sunsetted.
Hopefully this new report will be broadly acceptable because the old
reports have a *lot* of supporting unintelligible old code, especially
to handle closing-entries as above.

C

On 24/06/18 00:51, Christopher Lam wrote:

> Hi John, the split->noclosing_balance is updated in
> xaccAccountRecomputeBalance. Will continue copypasta coding until it
> works!
>
> On Sat, 23 Jun 2018, 23:56 John Ralls <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>
>     > On Jun 22, 2018, at 9:42 PM, Christopher Lam
>     <[hidden email] <mailto:[hidden email]>> wrote:
>     >
>     > Hi All
>     >
>     > I'm working through balance-sheet.scm and overhauling this report.
>     >
>     > At the same time, I can see that balance-sheet.scm and
>     income-statement.scm can be merged together.
>     >
>     > After all
>     >
>     > * balance sheet = asset/liability/equity balance at date X,
>     > * income statement = difference in income/expense balances at
>     date X and Y
>     >
>     > The issue I have is that the balance sheet can call
>     xaccAccountGetBalanceAsOfDate(acc,date) directly to nicely
>     retrieve the balance, whereas income statement cannot directly
>     call it because it also includes closing transactions.
>     >
>     > My proposal is to augment xaccAccountGetBalanceAsOfDate to
>     accept a 3rd boolean argument i.e.
>     xaccAccountGetBalanceAsOfDate(acc,date,ignoreclosing) which will
>     selectively produce the balance, ignore closing transactions.
>     >
>     > This is partly done in the last commit of
>     https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
>     - it will augment API everywhere, and also modify Account.cpp,
>     especially xaccAccountRecomputeBalance which will call
>     xaccTransGetIsClosingTxn(xaccSplitGetParent(split)) for each split
>     in the account to determine closing status and cache the balances
>     for each split. See draft on
>     https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
>     - this currently fails because I'm not good at C.
>     >
>     > *My query is whether it will be too expensive to call
>     xaccTransGetIsClosingTxn for each split in Account.cpp to produce
>     the split->noclosing_balance, which will be crucial to calculate
>     income between two dates.*
>     >
>     > *Currently this 'closing-txn' filter is done in
>     income-statement.scm via a "Closing Entries" string/regex filter
>     and xaccTransGetIsClosingTxn calls, which IMHO is not ideal either.
>     > *
>     >
>     > Any help welcome!
>     >
>     > P.S. if this last commit is removed, the
>     https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
>     branch contains work-so-far for updated balance-sheet. Screenshot
>     https://screenshots.firefox.com/eelmGQrGCtcP6bqC/null - see the
>     multilevel subtotals were previously horizonal, are now vertical;
>     original-currency amounts, and multiple-date balance sheets.
>     >
>     > _
>
>     Chris,
>
>     Only profiling will tell how much of a performance hit this creates.
>
>     I don’t see where in your commit you’re computing the split’s
>     no-closing balance. Perhaps that’s why it doesn’t work?
>
>     Regards,
>     John Ralls
>

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

Christopher Lam
Seeking beta testers. This will not be in v3.2.

https://github.com/christopherlam/gnucash/tree/maint-balsheet-pnl

Or, anyone with a relatively recent maint can copy the file directly
into the build's standard-reports folder:
https://raw.githubusercontent.com/christopherlam/gnucash/maint-balsheet-pnl/gnucash/report/standard-reports/balsheet-pnl.scm

Adds new balsheet and new income-statement. I still have further ideas
in the pipeline, just wish to check accuracy of amounts produced. Not
all options have been implemented. Testing closing amounts through KVP
wasn't an issue after all; the closing entries are first sought, cached,
then analyzed as required. For posterity C could also produce noclosing
balances for easier future reports, but I think this works well so far.

C

On 24/06/18 17:50, Christopher Lam wrote:

>
> I think I'll forego a noclosing_balance upgrade in C.
>
> According to https://bugzilla.gnome.org/show_bug.cgi?id=570042 the
> "Closing Entries" transactions did not always receive a special
> KVP-based flag until the commit on
> https://github.com/Gnucash/gnucash/commit/4b2800145 on datafiles
> generated from 27-11-2008 and later.
>
> So, to find and exclude these closing entries, we can use the
> following strategies:
>
>  1. xaccTransGetIsClosingTxn, will query the KVP flag
>  2. Run a QofQuery and add xaccQueryAddClosingTransMatch (also queries
>     the KVP flag)
>  3. Free-text search "Closing Entries" to seek these old closing entries
>
> So a P&L report will necessarily need to do both filtering for KVP and
> free-text search.
>
> The multicolumn report will be different enough from the old
> balance-sheet and income-statement that I think I should spin it off
> into a different report altogether, and the others will be sunsetted.
> Hopefully this new report will be broadly acceptable because the old
> reports have a *lot* of supporting unintelligible old code, especially
> to handle closing-entries as above.
>
> C
>
> On 24/06/18 00:51, Christopher Lam wrote:
>> Hi John, the split->noclosing_balance is updated in
>> xaccAccountRecomputeBalance. Will continue copypasta coding until it
>> works!
>>
>> On Sat, 23 Jun 2018, 23:56 John Ralls <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>
>>
>>     > On Jun 22, 2018, at 9:42 PM, Christopher Lam
>>     <[hidden email] <mailto:[hidden email]>> wrote:
>>     >
>>     > Hi All
>>     >
>>     > I'm working through balance-sheet.scm and overhauling this report.
>>     >
>>     > At the same time, I can see that balance-sheet.scm and
>>     income-statement.scm can be merged together.
>>     >
>>     > After all
>>     >
>>     > * balance sheet = asset/liability/equity balance at date X,
>>     > * income statement = difference in income/expense balances at
>>     date X and Y
>>     >
>>     > The issue I have is that the balance sheet can call
>>     xaccAccountGetBalanceAsOfDate(acc,date) directly to nicely
>>     retrieve the balance, whereas income statement cannot directly
>>     call it because it also includes closing transactions.
>>     >
>>     > My proposal is to augment xaccAccountGetBalanceAsOfDate to
>>     accept a 3rd boolean argument i.e.
>>     xaccAccountGetBalanceAsOfDate(acc,date,ignoreclosing) which will
>>     selectively produce the balance, ignore closing transactions.
>>     >
>>     > This is partly done in the last commit of
>>     https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
>>     - it will augment API everywhere, and also modify Account.cpp,
>>     especially xaccAccountRecomputeBalance which will call
>>     xaccTransGetIsClosingTxn(xaccSplitGetParent(split)) for each
>>     split in the account to determine closing status and cache the
>>     balances for each split. See draft on
>>     https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
>>     - this currently fails because I'm not good at C.
>>     >
>>     > *My query is whether it will be too expensive to call
>>     xaccTransGetIsClosingTxn for each split in Account.cpp to produce
>>     the split->noclosing_balance, which will be crucial to calculate
>>     income between two dates.*
>>     >
>>     > *Currently this 'closing-txn' filter is done in
>>     income-statement.scm via a "Closing Entries" string/regex filter
>>     and xaccTransGetIsClosingTxn calls, which IMHO is not ideal either.
>>     > *
>>     >
>>     > Any help welcome!
>>     >
>>     > P.S. if this last commit is removed, the
>>     https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
>>     branch contains work-so-far for updated balance-sheet. Screenshot
>>     https://screenshots.firefox.com/eelmGQrGCtcP6bqC/null - see the
>>     multilevel subtotals were previously horizonal, are now vertical;
>>     original-currency amounts, and multiple-date balance sheets.
>>     >
>>     > _
>>
>>     Chris,
>>
>>     Only profiling will tell how much of a performance hit this creates.
>>
>>     I don’t see where in your commit you’re computing the split’s
>>     no-closing balance. Perhaps that’s why it doesn’t work?
>>
>>     Regards,
>>     John Ralls
>>
>

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

John Ralls
In reply to this post by Christopher Lam
Chris,

OK, I think that’s a good choice.

As a general design principle I’d like to see the reports use QofQuery as much as possible--and extend QofQuery as necessary--because that makes it easier to reimplement as database queries.

Regards,
John Ralls


> On Jun 24, 2018, at 2:50 AM, Christopher Lam <[hidden email]> wrote:
>
> I think I'll forego a noclosing_balance upgrade in C.
>
> According to https://bugzilla.gnome.org/show_bug.cgi?id=570042 <https://bugzilla.gnome.org/show_bug.cgi?id=570042> the "Closing Entries" transactions did not always receive a special KVP-based flag until the commit onhttps://github.com/Gnucash/gnucash/commit/4b2800145 <https://github.com/Gnucash/gnucash/commit/4b2800145> on datafiles generated from 27-11-2008 and later.
> So, to find and exclude these closing entries, we can use the following strategies:
> xaccTransGetIsClosingTxn, will query the KVP flag
> Run a QofQuery and add xaccQueryAddClosingTransMatch (also queries the KVP flag)
> Free-text search "Closing Entries" to seek these old closing entries
> So a P&L report will necessarily need to do both filtering for KVP and free-text search.
>
> The multicolumn report will be different enough from the old balance-sheet and income-statement that I think I should spin it off into a different report altogether, and the others will be sunsetted. Hopefully this new report will be broadly acceptable because the old reports have a *lot* of supporting unintelligible old code, especially to handle closing-entries as above.
>
> C
>
> On 24/06/18 00:51, Christopher Lam wrote:
>> Hi John, the split->noclosing_balance is updated in xaccAccountRecomputeBalance. Will continue copypasta coding until it works!
>>
>> On Sat, 23 Jun 2018, 23:56 John Ralls <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>
>> > On Jun 22, 2018, at 9:42 PM, Christopher Lam <[hidden email] <mailto:[hidden email]>> wrote:
>> >
>> > Hi All
>> >
>> > I'm working through balance-sheet.scm and overhauling this report.
>> >
>> > At the same time, I can see that balance-sheet.scm and income-statement.scm can be merged together.
>> >
>> > After all
>> >
>> > * balance sheet = asset/liability/equity balance at date X,
>> > * income statement = difference in income/expense balances at date X and Y
>> >
>> > The issue I have is that the balance sheet can call xaccAccountGetBalanceAsOfDate(acc,date) directly to nicely retrieve the balance, whereas income statement cannot directly call it because it also includes closing transactions.
>> >
>> > My proposal is to augment xaccAccountGetBalanceAsOfDate to accept a 3rd boolean argument i.e. xaccAccountGetBalanceAsOfDate(acc,date,ignoreclosing) which will selectively produce the balance, ignore closing transactions.
>> >
>> > This is partly done in the last commit of https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances <https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances> - it will augment API everywhere, and also modify Account.cpp, especially xaccAccountRecomputeBalance which will call xaccTransGetIsClosingTxn(xaccSplitGetParent(split)) for each split in the account to determine closing status and cache the balances for each split. See draft on https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances <https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances> - this currently fails because I'm not good at C.
>> >
>> > *My query is whether it will be too expensive to call xaccTransGetIsClosingTxn for each split in Account.cpp to produce the split->noclosing_balance, which will be crucial to calculate income between two dates.*
>> >
>> > *Currently this 'closing-txn' filter is done in income-statement.scm via a "Closing Entries" string/regex filter and xaccTransGetIsClosingTxn calls, which IMHO is not ideal either.
>> > *
>> >
>> > Any help welcome!
>> >
>> > P.S. if this last commit is removed, the https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances <https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances> branch contains work-so-far for updated balance-sheet. Screenshot https://screenshots.firefox.com/eelmGQrGCtcP6bqC/null <https://screenshots.firefox.com/eelmGQrGCtcP6bqC/null> - see the multilevel subtotals were previously horizonal, are now vertical; original-currency amounts, and multiple-date balance sheets.
>> >
>> > _
>>
>> Chris,
>>
>> Only profiling will tell how much of a performance hit this creates.
>>
>> I don’t see where in your commit you’re computing the split’s no-closing balance. Perhaps that’s why it doesn’t work?
>>
>> Regards,
>> John Ralls
>

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

David Cousens
In reply to this post by Christopher Lam
Chris,
 I have the multicolumn report up and running in V3.2. In addition to adding
your file I also had to incorporate it in the CMakeLists.txt in
~/gnucash/report/standard-reports to have it available from the menu.
Initially I will just comment on the presentation, as I don't have a
testfile setup with which I can check the numbers out yet.

I need to emphasize that these are my personal preferences for clarity of
presentation and not any accounting profession standard as such. IAS-1
(https://www.iasplus.com/en/standards/ias/ias1) the IFRS standard does not
specify any particular layout and format and mainly concentrates on what
content has to be presented in the four standard financial statements (some
individual jurisdictions may be more prescriptive):
    Statement of financial position (balance sheet);
    Statement of profit and loss and other comprehensive income;
    Statement of cash flows;
    Statement of changes in equity.

One of the problems of a multicolumn report is in representing an account
heirarchy which is more than 2 to 3 levels deep as I'm sure you have already
discovered. You run out of ways of clearly delineating the totals at each
level fairly quickly. This is much easier when you can have a column at each
level of the heirarchy.

1. I would put the date headings one line up from the Asset Bold heading.
2. i wouldn't use double lines under sub-totals within the major Asset,
Liability and Equity groups but would just use a single line under them and
reserve the double underline for the total in each of those major sections,
3. With the Totals, I would not incorporate the full account heirarchy in
the heading, but just the parent account that the subtotal is for. Then
indenting of the account heirarchy can then indicate the heirarchy level and
what are totals at that level. You could perhaps augment this by using
decreasing font sixes as the heirarchy level increases.
4. If it is possible, I would have the total of any transactions direct to
the parent account displayed in the same manner as any of its child accounts
and balances so that the total displayed for the parent is the balance of
the direct transactions + any child account totals. If no direct
transactions, drop this as a line item. Since GnuCash does allow this
5. Also consider totalling up rather than down (avoids having to repeat the
Level Heading with a Total label.
6. There is no need for a separate Net Worth item as that is what Equity is.

I have attached a LibreOffice document illustrating what I mean by the above
in case it is not clear. I have illustrated a case where Petty Cash is a
parent account which has transactions into it as well as having a child
account (Ignore any table lines).
MultiColumnBalSheetLayoutSuggestions.odt
<http://gnucash.1415818.n4.nabble.com/file/t375329/MultiColumnBalSheetLayoutSuggestions.odt>  

Hope this helps with some ideas.

Cheers
David



-----
David Cousens
--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
David Cousens
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

Christopher Lam
Hi Stephen, Dave &al

Thank you -

Dave - the changes are merely cosmetic therefore easy.

It sounds there are still 2 desired presentational types - (1) Dave's
approach = *recursive-bal* - 'parent' accounts generally collect their
children account amounts; if they also have their own amount, the latter is
rendered on the next line, indented as a child account. (2) Stephen's
approach = *multilevel-bal* - parent accounts' amounts are hidden unless
they exist.

With *multilevel *balances we expect multiple sublevels; so the following
becomes feasible:
Expenses:Household:Child1           (parent-acc without amount)
Expenses:Household:Child1:Sports = $30
Expenses:Household:Child1:Clothing = $40
TOTAL Expenses:Household:Child1 = $70

Expenses:Household:Child2 = $20 (parent-acc with amounts)
Expenses:Household:Child2:Sports = $20
Expenses:Household:Child2:Clothing = $20
TOTAL Expenses:Household:Child2 = $60
TOTAL Expenses:Household = $xxx
TOTAL Expenses = $yyy
^ notice there will be as many TOTAL lines as there are levels from root.

I'll try to restore the multilevel subtotals - I had received no feedback
and it is rather difficult to debug; as I mentioned to Stephen I'd removed
it, but I expect it can be done.

The existing code is a mess and I want them gone, but will need to know the
amounts are correct.

C

On 30 June 2018 at 18:50, DaveC49 <[hidden email]> wrote:

> Chris,
>  I have the multicolumn report up and running in V3.2. In addition to
> adding
> your file I also had to incorporate it in the CMakeLists.txt in
> ~/gnucash/report/standard-reports to have it available from the menu.
> Initially I will just comment on the presentation, as I don't have a
> testfile setup with which I can check the numbers out yet.
>
> I need to emphasize that these are my personal preferences for clarity of
> presentation and not any accounting profession standard as such. IAS-1
> (https://www.iasplus.com/en/standards/ias/ias1) the IFRS standard does not
> specify any particular layout and format and mainly concentrates on what
> content has to be presented in the four standard financial statements (some
> individual jurisdictions may be more prescriptive):
>     Statement of financial position (balance sheet);
>     Statement of profit and loss and other comprehensive income;
>     Statement of cash flows;
>     Statement of changes in equity.
>
> One of the problems of a multicolumn report is in representing an account
> heirarchy which is more than 2 to 3 levels deep as I'm sure you have
> already
> discovered. You run out of ways of clearly delineating the totals at each
> level fairly quickly. This is much easier when you can have a column at
> each
> level of the heirarchy.
>
> 1. I would put the date headings one line up from the Asset Bold heading.
> 2. i wouldn't use double lines under sub-totals within the major Asset,
> Liability and Equity groups but would just use a single line under them and
> reserve the double underline for the total in each of those major sections,
> 3. With the Totals, I would not incorporate the full account heirarchy in
> the heading, but just the parent account that the subtotal is for. Then
> indenting of the account heirarchy can then indicate the heirarchy level
> and
> what are totals at that level. You could perhaps augment this by using
> decreasing font sixes as the heirarchy level increases.
> 4. If it is possible, I would have the total of any transactions direct to
> the parent account displayed in the same manner as any of its child
> accounts
> and balances so that the total displayed for the parent is the balance of
> the direct transactions + any child account totals. If no direct
> transactions, drop this as a line item. Since GnuCash does allow this
> 5. Also consider totalling up rather than down (avoids having to repeat the
> Level Heading with a Total label.
> 6. There is no need for a separate Net Worth item as that is what Equity
> is.
>
> I have attached a LibreOffice document illustrating what I mean by the
> above
> in case it is not clear. I have illustrated a case where Petty Cash is a
> parent account which has transactions into it as well as having a child
> account (Ignore any table lines).
> MultiColumnBalSheetLayoutSuggestions.odt
> <http://gnucash.1415818.n4.nabble.com/file/t375329/
> MultiColumnBalSheetLayoutSuggestions.odt>
>
> Hope this helps with some ideas.
>
> Cheers
> David
>
>
>
> -----
> David Cousens
> --
> Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

Geert Janssens-4
Op dinsdag 3 juli 2018 02:57:50 CEST schreef Christopher Lam:

> Hi Stephen, Dave &al
>
> Thank you -
>
> Dave - the changes are merely cosmetic therefore easy.
>
> It sounds there are still 2 desired presentational types - (1) Dave's
> approach = *recursive-bal* - 'parent' accounts generally collect their
> children account amounts; if they also have their own amount, the latter is
> rendered on the next line, indented as a child account. (2) Stephen's
> approach = *multilevel-bal* - parent accounts' amounts are hidden unless
> they exist.
>
I'm not sure I understand the difference here. Isn't this expressing the same
thing twice in different ways ? Perhaps I'm missing a subtlety in the English
language...

Or is the difference whether the totals are shown above or below the children
?

Geert


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

Christopher Lam
Broadly yes, one approach is that parent accounts always show totals for
themselves+children, the other approach is the totals appear after each
parent+children.

Same information presented in 2 different ways.

The difference is that the recursive subtotals are easier.... When reaching
an account, it just queries if it has children, and if yes check if they
have own amount, and if yes insert next line for own account.

Multilevel subtotals require collectors to keeping track of amounts while
cycling the account list.

On Tue, 3 Jul 2018, 15:41 Geert Janssens <[hidden email]> wrote:

> Op dinsdag 3 juli 2018 02:57:50 CEST schreef Christopher Lam:
> > Hi Stephen, Dave &al
> >
> > Thank you -
> >
> > Dave - the changes are merely cosmetic therefore easy.
> >
> > It sounds there are still 2 desired presentational types - (1) Dave's
> > approach = *recursive-bal* - 'parent' accounts generally collect their
> > children account amounts; if they also have their own amount, the latter
> is
> > rendered on the next line, indented as a child account. (2) Stephen's
> > approach = *multilevel-bal* - parent accounts' amounts are hidden unless
> > they exist.
> >
> I'm not sure I understand the difference here. Isn't this expressing the
> same
> thing twice in different ways ? Perhaps I'm missing a subtlety in the
> English
> language...
>
> Or is the difference whether the totals are shown above or below the
> children
> ?
>
> Geert
>
>
>
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

Christopher Lam
I've restored multilevel-subtotals... using an easier tack than
previously: instead of keeping lists(1 per account-depth) of lists (1
per column) of collectors, it'll just climb up the hierarchy and print
parent acc's balance+children until the next account-depth is reached.

Please help beta test!

I've made some cosmetic changes too. eg dates in their own row,
double-underline for grand-total only.

I do not think it'll be wise to reduce font sizes for account-depth.

Still remaining:

- fix negative signs strategy


On 03/07/18 16:17, Christopher Lam wrote:

> Broadly yes, one approach is that parent accounts always show totals
> for themselves+children, the other approach is the totals appear after
> each parent+children.
>
> Same information presented in 2 different ways.
>
> The difference is that the recursive subtotals are easier.... When
> reaching an account, it just queries if it has children, and if yes
> check if they have own amount, and if yes insert next line for own
> account.
>
> Multilevel subtotals require collectors to keeping track of amounts
> while cycling the account list.
>
> On Tue, 3 Jul 2018, 15:41 Geert Janssens <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Op dinsdag 3 juli 2018 02:57:50 CEST schreef Christopher Lam:
>     > Hi Stephen, Dave &al
>     >
>     > Thank you -
>     >
>     > Dave - the changes are merely cosmetic therefore easy.
>     >
>     > It sounds there are still 2 desired presentational types - (1)
>     Dave's
>     > approach = *recursive-bal* - 'parent' accounts generally collect
>     their
>     > children account amounts; if they also have their own amount,
>     the latter is
>     > rendered on the next line, indented as a child account. (2)
>     Stephen's
>     > approach = *multilevel-bal* - parent accounts' amounts are
>     hidden unless
>     > they exist.
>     >
>     I'm not sure I understand the difference here. Isn't this
>     expressing the same
>     thing twice in different ways ? Perhaps I'm missing a subtlety in
>     the English
>     language...
>
>     Or is the difference whether the totals are shown above or below
>     the children
>     ?
>
>     Geert
>
>

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

Christopher Lam
Forgot to include a screenshot to illustrate

https://screenshots.firefox.com/Z7HOv5pb2qbRc5NP/null

- recursive balance vs. multilevel (and saner alignment of numbers)
- common-currency vs. original currency (notice better handling of
missing USD/GBP prices than balance-sheet.scm)
- for this illustration periodic columns have been disabled

C


On 04/07/18 20:13, Christopher Lam wrote:

>
> I've restored multilevel-subtotals... using an easier tack than
> previously: instead of keeping lists(1 per account-depth) of lists (1
> per column) of collectors, it'll just climb up the hierarchy and print
> parent acc's balance+children until the next account-depth is reached.
>
> Please help beta test!
>
> I've made some cosmetic changes too. eg dates in their own row,
> double-underline for grand-total only.
>
> I do not think it'll be wise to reduce font sizes for account-depth.
>
> Still remaining:
>
> - fix negative signs strategy
>
>
> On 03/07/18 16:17, Christopher Lam wrote:
>> Broadly yes, one approach is that parent accounts always show totals
>> for themselves+children, the other approach is the totals appear
>> after each parent+children.
>>
>> Same information presented in 2 different ways.
>>
>> The difference is that the recursive subtotals are easier.... When
>> reaching an account, it just queries if it has children, and if yes
>> check if they have own amount, and if yes insert next line for own
>> account.
>>
>> Multilevel subtotals require collectors to keeping track of amounts
>> while cycling the account list.
>>
>> On Tue, 3 Jul 2018, 15:41 Geert Janssens <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>     Op dinsdag 3 juli 2018 02:57:50 CEST schreef Christopher Lam:
>>     > Hi Stephen, Dave &al
>>     >
>>     > Thank you -
>>     >
>>     > Dave - the changes are merely cosmetic therefore easy.
>>     >
>>     > It sounds there are still 2 desired presentational types - (1)
>>     Dave's
>>     > approach = *recursive-bal* - 'parent' accounts generally
>>     collect their
>>     > children account amounts; if they also have their own amount,
>>     the latter is
>>     > rendered on the next line, indented as a child account. (2)
>>     Stephen's
>>     > approach = *multilevel-bal* - parent accounts' amounts are
>>     hidden unless
>>     > they exist.
>>     >
>>     I'm not sure I understand the difference here. Isn't this
>>     expressing the same
>>     thing twice in different ways ? Perhaps I'm missing a subtlety in
>>     the English
>>     language...
>>
>>     Or is the difference whether the totals are shown above or below
>>     the children
>>     ?
>>
>>     Geert
>>
>>
>

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

Christopher Lam
Oops https://screenshots.firefox.com/pttTjFEtYTJLXzam/null

Sorry for spam, fixed screenshot


On 04/07/18 21:20, Christopher Lam wrote:

>
> Forgot to include a screenshot to illustrate
>
> https://screenshots.firefox.com/Z7HOv5pb2qbRc5NP/null
>
> - recursive balance vs. multilevel (and saner alignment of numbers)
> - common-currency vs. original currency (notice better handling of
> missing USD/GBP prices than balance-sheet.scm)
> - for this illustration periodic columns have been disabled
>
> C
>
>
> On 04/07/18 20:13, Christopher Lam wrote:
>>
>> I've restored multilevel-subtotals... using an easier tack than
>> previously: instead of keeping lists(1 per account-depth) of lists (1
>> per column) of collectors, it'll just climb up the hierarchy and
>> print parent acc's balance+children until the next account-depth is
>> reached.
>>
>> Please help beta test!
>>
>> I've made some cosmetic changes too. eg dates in their own row,
>> double-underline for grand-total only.
>>
>> I do not think it'll be wise to reduce font sizes for account-depth.
>>
>> Still remaining:
>>
>> - fix negative signs strategy
>>
>>
>> On 03/07/18 16:17, Christopher Lam wrote:
>>> Broadly yes, one approach is that parent accounts always show totals
>>> for themselves+children, the other approach is the totals appear
>>> after each parent+children.
>>>
>>> Same information presented in 2 different ways.
>>>
>>> The difference is that the recursive subtotals are easier.... When
>>> reaching an account, it just queries if it has children, and if yes
>>> check if they have own amount, and if yes insert next line for own
>>> account.
>>>
>>> Multilevel subtotals require collectors to keeping track of amounts
>>> while cycling the account list.
>>>
>>> On Tue, 3 Jul 2018, 15:41 Geert Janssens <[hidden email]
>>> <mailto:[hidden email]>> wrote:
>>>
>>>     Op dinsdag 3 juli 2018 02:57:50 CEST schreef Christopher Lam:
>>>     > Hi Stephen, Dave &al
>>>     >
>>>     > Thank you -
>>>     >
>>>     > Dave - the changes are merely cosmetic therefore easy.
>>>     >
>>>     > It sounds there are still 2 desired presentational types - (1)
>>>     Dave's
>>>     > approach = *recursive-bal* - 'parent' accounts generally
>>>     collect their
>>>     > children account amounts; if they also have their own amount,
>>>     the latter is
>>>     > rendered on the next line, indented as a child account. (2)
>>>     Stephen's
>>>     > approach = *multilevel-bal* - parent accounts' amounts are
>>>     hidden unless
>>>     > they exist.
>>>     >
>>>     I'm not sure I understand the difference here. Isn't this
>>>     expressing the same
>>>     thing twice in different ways ? Perhaps I'm missing a subtlety
>>>     in the English
>>>     language...
>>>
>>>     Or is the difference whether the totals are shown above or below
>>>     the children
>>>     ?
>>>
>>>     Geert
>>>
>>>
>>
>

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

Christopher Lam
In reply to this post by Christopher Lam
Still at
https://raw.githubusercontent.com/christopherlam/gnucash/maint-balsheet-pnl/gnucash/report/standard-reports/balsheet-pnl.scm

Latest - removed accountname formatting in recursive-bal. Now they are
styled normally but the amounts are bold/bigger if they contain
children-amounts.

https://screenshots.firefox.com/NcMKts75npXbP4Bc/null

C

On 05/07/18 03:40, Stephen M. Butler wrote:

> Could you repost the location to pull the latest?  My memory is
> over-full and appears to be working the LIFO method of cleanup.
>
>
> On 07/04/2018 05:13 AM, Christopher Lam wrote:
>> I've restored multilevel-subtotals... using an easier tack than
>> previously: instead of keeping lists(1 per account-depth) of lists (1
>> per column) of collectors, it'll just climb up the hierarchy and print
>> parent acc's balance+children until the next account-depth is reached.
>>
>> Please help beta test!
>>
>> I've made some cosmetic changes too. eg dates in their own row,
>> double-underline for grand-total only.
>>
>> I do not think it'll be wise to reduce font sizes for account-depth.
>>
>> Still remaining:
>>
>> - fix negative signs strategy
>>
>>
>> On 03/07/18 16:17, Christopher Lam wrote:
>>> Broadly yes, one approach is that parent accounts always show totals
>>> for themselves+children, the other approach is the totals appear
>>> after each parent+children.
>>>
>>> Same information presented in 2 different ways.
>>>
>>> The difference is that the recursive subtotals are easier.... When
>>> reaching an account, it just queries if it has children, and if yes
>>> check if they have own amount, and if yes insert next line for own
>>> account.
>>>
>>> Multilevel subtotals require collectors to keeping track of amounts
>>> while cycling the account list.
>>>
>>> On Tue, 3 Jul 2018, 15:41 Geert Janssens <[hidden email]
>>> <mailto:[hidden email]>> wrote:
>>>
>>>      Op dinsdag 3 juli 2018 02:57:50 CEST schreef Christopher Lam:
>>>      > Hi Stephen, Dave &al
>>>      >
>>>      > Thank you -
>>>      >
>>>      > Dave - the changes are merely cosmetic therefore easy.
>>>      >
>>>      > It sounds there are still 2 desired presentational types - (1)
>>>      Dave's
>>>      > approach = *recursive-bal* - 'parent' accounts generally
>>>      collect their
>>>      > children account amounts; if they also have their own amount,
>>>      the latter is
>>>      > rendered on the next line, indented as a child account. (2)
>>>      Stephen's
>>>      > approach = *multilevel-bal* - parent accounts' amounts are
>>>      hidden unless
>>>      > they exist.
>>>      >
>>>      I'm not sure I understand the difference here. Isn't this
>>>      expressing the same
>>>      thing twice in different ways ? Perhaps I'm missing a subtlety in
>>>      the English
>>>      language...
>>>
>>>      Or is the difference whether the totals are shown above or below
>>>      the children
>>>      ?
>>>
>>>      Geert
>>>
>>>

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

Christopher Lam
In reply to this post by Geert Janssens-4
The state of balsheet-pnl.scm, is as follows:

I think it is stable and featureful enough to be a replacement, but
there are no tests yet to validate a transition. This may happen over
the next few months.

It incorporates all balance-sheet.scm and income-statement.scm
functionality with the following known differences:

  * no option to show double-column ie Asset=left, Expense/Equity=right
    (because I prefer leaving space for multiple data columns <g>)
  * no option to hide/show individual sections/their labels (eg
    Display/show asset section)
  * no display/show accounting-style rules (no space at all)
  * flatten list at depth limit (I don't understand its strategy at all
    and prefer to disable it)
  * balance-sheet.scm with Display/Parent-account-balances=none will
    disable amounts for accounts-with-children, which I think is
    nonsensical -- if an account has children, unless its amount is $0,
    it must be displayed, either recursive or multilevel.
  * choosing a common-report-currency when there are missing prices will
    now leave the amount in its original currency, instead of converting
    to $0.00
  * new balsheet will not compute unrealized gains -- from my
    understanding this doesn't belong in the balance sheet
  * I haven't coded the price source to average-cost or
    weighted-average, both of which will set a single exchange rate
    through all multicolumns -- are these options important???

Future plans:

  * I think the account-amount calculating functions are good enough to
    be reused to replace net-charts, category-barchart etc.
  * Hopefully the unintelligible old code can then be dumped for good.

C


On 03/07/18 15:41, Geert Janssens wrote:

> Op dinsdag 3 juli 2018 02:57:50 CEST schreef Christopher Lam:
>> Hi Stephen, Dave &al
>>
>> Thank you -
>>
>> Dave - the changes are merely cosmetic therefore easy.
>>
>> It sounds there are still 2 desired presentational types - (1) Dave's
>> approach = *recursive-bal* - 'parent' accounts generally collect their
>> children account amounts; if they also have their own amount, the latter is
>> rendered on the next line, indented as a child account. (2) Stephen's
>> approach = *multilevel-bal* - parent accounts' amounts are hidden unless
>> they exist.
>>
> I'm not sure I understand the difference here. Isn't this expressing the same
> thing twice in different ways ? Perhaps I'm missing a subtlety in the English
> language...
>
> Or is the difference whether the totals are shown above or below the children
> ?
>
> Geert
>
>

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

Frank H. Ellenberger-3
Hi Chris,

Am 18.07.2018 um 15:13 schrieb Christopher Lam:

> The state of balsheet-pnl.scm, is as follows:
>
> I think it is stable and featureful enough to be a replacement, but
> there are no tests yet to validate a transition. This may happen over
> the next few months.
>
> It incorporates all balance-sheet.scm and income-statement.scm
> functionality with the following known differences:
>
>  * no option to show double-column ie Asset=left, Expense/Equity=right
>    (because I prefer leaving space for multiple data columns <g>)
That is a problem for users in continental Europe, probably also other
non english speaking countries. We use the traditional T account
representation, while english speaking countries prefer the scaled (from
ital. for step stairs) form.

The T account representation easens also simple liqudity checks (current
assets > current lianilities, medium term assets > medium term
liabilities ...). Similar comparing groups of income & expense is desired.

IMHO the ability to compare groups is as much, if not more important
than compares over time.

Regards
Frank

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

pEpkey.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

Christopher Lam
Hi Frank
Thank you - I can restore the dual-columns when the periods have been
disabled.
I'd prefer to limit the number of options; so, if the "period duration" is
disabled, the report will automatically show dual columns
(Asset/Income=left, Liability+Equity/Expense = right). This works?
Can you please show me good examples of idealised T-account balance
sheet/income statement? Or the scaled form? I have no idea.
C



On 19 July 2018 at 05:17, Frank H. Ellenberger <
[hidden email]> wrote:

> Hi Chris,
>
> Am 18.07.2018 um 15:13 schrieb Christopher Lam:
> > The state of balsheet-pnl.scm, is as follows:
> >
> > I think it is stable and featureful enough to be a replacement, but
> > there are no tests yet to validate a transition. This may happen over
> > the next few months.
> >
> > It incorporates all balance-sheet.scm and income-statement.scm
> > functionality with the following known differences:
> >
> >  * no option to show double-column ie Asset=left, Expense/Equity=right
> >    (because I prefer leaving space for multiple data columns <g>)
>
> That is a problem for users in continental Europe, probably also other
> non english speaking countries. We use the traditional T account
> representation, while english speaking countries prefer the scaled (from
> ital. for step stairs) form.
>
> The T account representation easens also simple liqudity checks (current
> assets > current lianilities, medium term assets > medium term
> liabilities ...). Similar comparing groups of income & expense is desired.
>
> IMHO the ability to compare groups is as much, if not more important
> than compares over time.
>
> Regards
> Frank
>
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

[GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

Frank H. Ellenberger-3
Am 19.07.2018 um 13:09 schrieb Christopher Lam:
> Hi Frank
> Thank you - I can restore the dual-columns when the periods have been
> disabled.
> I'd prefer to limit the number of options; so, if the "period duration" is
> disabled, the report will automatically show dual columns

while intl. IFRS and DE-GOB/HGB reqire one, US-GAAP requires 3 previous
years in the Income statement.
https://de.wikipedia.org/wiki/Gewinn-_und_Verlustrechnung#Vorjahresbetr%C3%A4ge

> (Asset/Income=left, Liability+Equity/Expense = right). This works?

> Can you please show me good examples of idealised T-account balance
> sheet/income statement? Or the scaled form? I have no idea.

To get an impression you could starting from:

https://en.wikipedia.org/wiki/Balance_sheet - which has
#US_small_business in account form and #Sample in scaled form -
or

https://en.wikipedia.org/wiki/Income_statement and an example in account
form: https://debitoor.de/lexikon/gewinn-und-verlustrechnung-guv

Note: There are several different methods for grouping the positions
with differrent pros and cons allowed for different company types:
Gesamtkostenverfahren, Umsatzkostenverfahren & IFRS. Currently I have no
better idea for the grouping than adjusting the account structure.

Optionally select other languages e.g.
https://de.wikipedia.org/wiki/Bilanz#Aufbau_der_Bilanz

HTH
Frank



_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

pEpkey.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

Christopher Lam
Latest iteration of balsheet

  * restored amount-indenting. IMHO this is now producing sane indenting
    for any subtotal strategy
  * restore dual columns (i.e. left=asset/income, right=liability/expense)
  * the above two only enabled when multicols are disabled
  * option to toggle amount/account indenting
  * incorporated bug 623381 recommendations for sections labels/totals
  * added sections for equity, liability+equity
  * modify 'original-currency' display to match eguile report i.e.
    smaller font, precedes converted currency

I would really like feedback on

  * accuracy of amounts
  * accuracy of sections
      o further tweaking of option names/sections/ordering

Screenshot:
https://screenshots.firefox.com/nhaiX1ehSA2GXA97/null

On 25/07/18 15:53, Frank H. Ellenberger wrote:

> Am 19.07.2018 um 13:09 schrieb Christopher Lam:
>> Hi Frank
>> Thank you - I can restore the dual-columns when the periods have been
>> disabled.
>> I'd prefer to limit the number of options; so, if the "period duration" is
>> disabled, the report will automatically show dual columns
> while intl. IFRS and DE-GOB/HGB reqire one, US-GAAP requires 3 previous
> years in the Income statement.
> https://de.wikipedia.org/wiki/Gewinn-_und_Verlustrechnung#Vorjahresbetr%C3%A4ge
>
>> (Asset/Income=left, Liability+Equity/Expense = right). This works?
>> Can you please show me good examples of idealised T-account balance
>> sheet/income statement? Or the scaled form? I have no idea.
> To get an impression you could starting from:
>
> https://en.wikipedia.org/wiki/Balance_sheet - which has
> #US_small_business in account form and #Sample in scaled form -
> or
>
> https://en.wikipedia.org/wiki/Income_statement and an example in account
> form: https://debitoor.de/lexikon/gewinn-und-verlustrechnung-guv
>
> Note: There are several different methods for grouping the positions
> with differrent pros and cons allowed for different company types:
> Gesamtkostenverfahren, Umsatzkostenverfahren & IFRS. Currently I have no
> better idea for the grouping than adjusting the account structure.
>
> Optionally select other languages e.g.
> https://de.wikipedia.org/wiki/Bilanz#Aufbau_der_Bilanz
>
> HTH
> Frank
>
>

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

Adrien Monteleone-2
In reply to this post by Frank H. Ellenberger-3
Frank,

I’ve been following this for a while, and perhaps I’m not understanding, but are the groupings just presentational?

If that’s the case, I would think the place to address this is in the report options, not the account structure. (you could use any structure you need, and easily re-group based on the rule you decide or need to follow.)

Regards,
Adrien

> On Jul 25, 2018, at 2:53 AM, Frank H. Ellenberger <[hidden email]> wrote:
>
> Am 19.07.2018 um 13:09 schrieb Christopher Lam:
>> Hi Frank
>> Thank you - I can restore the dual-columns when the periods have been
>> disabled.
>> I'd prefer to limit the number of options; so, if the "period duration" is
>> disabled, the report will automatically show dual columns
>
> while intl. IFRS and DE-GOB/HGB reqire one, US-GAAP requires 3 previous
> years in the Income statement.
> https://de.wikipedia.org/wiki/Gewinn-_und_Verlustrechnung#Vorjahresbetr%C3%A4ge
>
>> (Asset/Income=left, Liability+Equity/Expense = right). This works?
>
>> Can you please show me good examples of idealised T-account balance
>> sheet/income statement? Or the scaled form? I have no idea.
>
> To get an impression you could starting from:
>
> https://en.wikipedia.org/wiki/Balance_sheet - which has
> #US_small_business in account form and #Sample in scaled form -
> or
>
> https://en.wikipedia.org/wiki/Income_statement and an example in account
> form: https://debitoor.de/lexikon/gewinn-und-verlustrechnung-guv
>
> Note: There are several different methods for grouping the positions
> with differrent pros and cons allowed for different company types:
> Gesamtkostenverfahren, Umsatzkostenverfahren & IFRS. Currently I have no
> better idea for the grouping than adjusting the account structure.
>
> Optionally select other languages e.g.
> https://de.wikipedia.org/wiki/Bilanz#Aufbau_der_Bilanz
>
> HTH
> Frank
>
>
> <pEpkey.asc>_______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
123