[GNC-dev] Reports -- Cleanup

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

[GNC-dev] Reports -- Cleanup

Stephen M. Butler
I think one of the developers here mentioned that there is a lot of
duplication in the reports arena.  I concur.  At first it was very
confusing as to which was the "correct" one.  Finally figured out none
where -- according to the in house SME (pronounced "smee" and standing
for Subject Matter Expert) and needed to roll my own.  Of which, I only
have the Balance Sheet sorta working like she wants it.

Following some email exchange via the bug reporting system regarding the
Transaction report module, I agree that it has too many options already
and requires a near programmer to figure out which options need to be
set what way to get something close to desirable.

Please note that I'm not a smee in this arena and, with my project
manager hat on, my wife barely qualifies.  There are others on this
mailing list better qualified who will have differing opinions. 

However, here are my thoughts:

1.  A transaction report (however it is organized) should always show
the split amount.  I propose that the Amount (None, Single, Double)
option be removed and the report always produces the Amount in two
columns Debit to the left and Credit to the right. 

2.  The Multi-line versus Single-line option may add confusion.  If one
wants to group the splits in a transaction together, then the report
should be organized that way.  When one picks the multi-line option, the
report becomes hard to read and understand especially as the other
splits are not included in the totals.  I suggest that Single-line be
the reporting style and the multi-line (meaning -- as best I can
determine -- multi-splits) removed.

These are just two of many simplifications that could be made to help
guide the end-user into the reports they need rather than letting them
create a report that is useless to them and anybody else.

Along those lines, I see this code needing to generate the following
types of reports:

A.  Transaction Journal -- this one lists the transactions within the
date range in date order and keeps all the splits together on the
report.  A printed version of the General Ledger screen (in multi-split
mode).

B.  Reconciliation Report -- rather than have the user pick the
accounts, a first pass should show the Dates within Accounts for which
there were reconciliations done (with the date range selected).  Let the
user select one or more of these to be reported, but each selection
becomes its own report or page.  Usually show the transactions
reconciled on that date (by account and in date order) optionally
followed by the transactions not yet reconciled within that account.

C.  Account Details -- here the user should pick the account(s) for
which the detailed transaction should be shown for the date range selected.

There may be a couple more variants, but if we start thinking about what
a bookkeeper/accountant needs we can reduce the number of options
available and thus remove complexity from the reports (at least this
particular one).

As a software engineer, I love to gold plate things.  As a project
manager, I realize that gold plates rarely provide the end user with
something useful.  Hey, but it looks good!

So, which options on the transaction report do you never use?  Which
options do you always set one particular way?

--Steve

--
Stephen M Butler, PMP, PSM
[hidden email]
[hidden email]
253-350-0166
-------------------------------------------
GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8


_______________________________________________
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] Reports -- Cleanup

GnuCash - Dev mailing list

Stephen,
I'm sure I would welcome improvement in the reports. 
I don't have many concrete points here, except to suggest that the ideal UI point for a reconciliation report would be at the end of the reconciliation process. A check box on the reconcile window would trigger the report, automatically passing the current account and reconciliation dates along to the report. 
David T.
 
 
  On Tue, Jan 8, 2019 at 4:21, Stephen M. Butler<[hidden email]> wrote:   I think one of the developers here mentioned that there is a lot of
duplication in the reports arena.  I concur.  At first it was very
confusing as to which was the "correct" one.  Finally figured out none
where -- according to the in house SME (pronounced "smee" and standing
for Subject Matter Expert) and needed to roll my own.  Of which, I only
have the Balance Sheet sorta working like she wants it.

Following some email exchange via the bug reporting system regarding the
Transaction report module, I agree that it has too many options already
and requires a near programmer to figure out which options need to be
set what way to get something close to desirable.

Please note that I'm not a smee in this arena and, with my project
manager hat on, my wife barely qualifies.  There are others on this
mailing list better qualified who will have differing opinions. 

However, here are my thoughts:

1.  A transaction report (however it is organized) should always show
the split amount.  I propose that the Amount (None, Single, Double)
option be removed and the report always produces the Amount in two
columns Debit to the left and Credit to the right. 

2.  The Multi-line versus Single-line option may add confusion.  If one
wants to group the splits in a transaction together, then the report
should be organized that way.  When one picks the multi-line option, the
report becomes hard to read and understand especially as the other
splits are not included in the totals.  I suggest that Single-line be
the reporting style and the multi-line (meaning -- as best I can
determine -- multi-splits) removed.

These are just two of many simplifications that could be made to help
guide the end-user into the reports they need rather than letting them
create a report that is useless to them and anybody else.

Along those lines, I see this code needing to generate the following
types of reports:

A.  Transaction Journal -- this one lists the transactions within the
date range in date order and keeps all the splits together on the
report.  A printed version of the General Ledger screen (in multi-split
mode).

B.  Reconciliation Report -- rather than have the user pick the
accounts, a first pass should show the Dates within Accounts for which
there were reconciliations done (with the date range selected).  Let the
user select one or more of these to be reported, but each selection
becomes its own report or page.  Usually show the transactions
reconciled on that date (by account and in date order) optionally
followed by the transactions not yet reconciled within that account.

C.  Account Details -- here the user should pick the account(s) for
which the detailed transaction should be shown for the date range selected.

There may be a couple more variants, but if we start thinking about what
a bookkeeper/accountant needs we can reduce the number of options
available and thus remove complexity from the reports (at least this
particular one).

As a software engineer, I love to gold plate things.  As a project
manager, I realize that gold plates rarely provide the end user with
something useful.  Hey, but it looks good!

So, which options on the transaction report do you never use?  Which
options do you always set one particular way?

--Steve

--
Stephen M Butler, PMP, PSM
[hidden email]
[hidden email]
253-350-0166
-------------------------------------------
GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8


_______________________________________________
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] Reports -- Cleanup

Adrien Monteleone-2
In reply to this post by Stephen M. Butler
Stephen, while I agree in principle that the reports need cleanup, as a user, I don’t want to see functionality removed, just moved. Consider the following:

For example on your #1,

Why do I need to see the credit split for every transaction when running the report for an expense account? Maybe I want to know where the money came from, but more likely, I want to know who I paid it to and when and how much. Maybe I’d like some 'how much' totals for the 'who to' and when ‘questions'. To have to see the other side of every transaction even for a few dozen is unnecessary clutter, imagine a report with hundreds of transactions. One purpose of a report is to condense/consolidate information. This would turn the Transaction Report into just a fancy Register Report. I might as well look at the expense register itself then run a report.

On the #2,

So I shouldn’t be able to see what else might have happened in that transaction, but I always have to see both the credit and debit sides of it? How is that consistent? or possible? If I can’t see the other splits, I can’t see the balancing part of the transaction like you want in #1, or, maybe I see a debit to an expense and the credit to checking, but maybe there were other offsetting debits for other expense accounts in that transaction. Now I’m looking at an expense debit that is less than the credit line and things don’t balance at the least, and worst, now I have clutter that gives me no useful information and can’t see the info I might want to see. (such as, is there a pattern that two expenses go together?)

I do agree however that the Transaction report is really more of a ‘master report’ of sorts. The multi-column is another. There might be others.

Those should probably be either in their own sub-menu, or the only ones in the main Reports menu. Then the various useful reports one routinely needs that are based off of those masters can be in the topic specific sub-menus.

I don’t see the myriad of options as ‘gold plating’ I see them as making the report more useful. (though obtuse as well)

Perhaps if some more routine and useful reports were created from this and added to the relevant sub-menus, less people would need the ‘master report’ though it can still be there for those who know how to wield its power.

Just my 2¢.

Regards,
Adrien

> On Jan 7, 2019, at 4:50 PM, Stephen M. Butler <[hidden email]> wrote:
>
> I think one of the developers here mentioned that there is a lot of
> duplication in the reports arena.  I concur.  At first it was very
> confusing as to which was the "correct" one.  Finally figured out none
> where -- according to the in house SME (pronounced "smee" and standing
> for Subject Matter Expert) and needed to roll my own.  Of which, I only
> have the Balance Sheet sorta working like she wants it.
>
> Following some email exchange via the bug reporting system regarding the
> Transaction report module, I agree that it has too many options already
> and requires a near programmer to figure out which options need to be
> set what way to get something close to desirable.
>
> Please note that I'm not a smee in this arena and, with my project
> manager hat on, my wife barely qualifies.  There are others on this
> mailing list better qualified who will have differing opinions.
>
> However, here are my thoughts:
>
> 1.  A transaction report (however it is organized) should always show
> the split amount.  I propose that the Amount (None, Single, Double)
> option be removed and the report always produces the Amount in two
> columns Debit to the left and Credit to the right.
>
> 2.  The Multi-line versus Single-line option may add confusion.  If one
> wants to group the splits in a transaction together, then the report
> should be organized that way.  When one picks the multi-line option, the
> report becomes hard to read and understand especially as the other
> splits are not included in the totals.  I suggest that Single-line be
> the reporting style and the multi-line (meaning -- as best I can
> determine -- multi-splits) removed.
>
> These are just two of many simplifications that could be made to help
> guide the end-user into the reports they need rather than letting them
> create a report that is useless to them and anybody else.
>
> Along those lines, I see this code needing to generate the following
> types of reports:
>
> A.  Transaction Journal -- this one lists the transactions within the
> date range in date order and keeps all the splits together on the
> report.  A printed version of the General Ledger screen (in multi-split
> mode).
>
> B.  Reconciliation Report -- rather than have the user pick the
> accounts, a first pass should show the Dates within Accounts for which
> there were reconciliations done (with the date range selected).  Let the
> user select one or more of these to be reported, but each selection
> becomes its own report or page.  Usually show the transactions
> reconciled on that date (by account and in date order) optionally
> followed by the transactions not yet reconciled within that account.
>
> C.  Account Details -- here the user should pick the account(s) for
> which the detailed transaction should be shown for the date range selected.
>
> There may be a couple more variants, but if we start thinking about what
> a bookkeeper/accountant needs we can reduce the number of options
> available and thus remove complexity from the reports (at least this
> particular one).
>
> As a software engineer, I love to gold plate things.  As a project
> manager, I realize that gold plates rarely provide the end user with
> something useful.  Hey, but it looks good!
>
> So, which options on the transaction report do you never use?  Which
> options do you always set one particular way?
>
> --Steve
>
> --
> Stephen M Butler, PMP, PSM
> [hidden email]
> [hidden email]
> 253-350-0166
> -------------------------------------------
> GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8
>
>
> _______________________________________________
> 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] Reports -- Cleanup

Stephen M. Butler
On 1/7/19 8:42 PM, Adrien Monteleone wrote:
> Stephen, while I agree in principle that the reports need cleanup, as a user, I don’t want to see functionality removed, just moved. Consider the following:
>
> For example on your #1,
>
> Why do I need to see the credit split for every transaction when running the report for an expense account? Maybe I want to know where the money came from, but more likely, I want to know who I paid it to and when and how much. Maybe I’d like some 'how much' totals for the 'who to' and when ‘questions'. To have to see the other side of every transaction even for a few dozen is unnecessary clutter, imagine a report with hundreds of transactions. One purpose of a report is to condense/consolidate information. This would turn the Transaction Report into just a fancy Register Report. I might as well look at the expense register itself then run a report.

This is a case of what I thought I wrote isn't what you thought you
read!  Your argument is my argument for #2.  You shouldn't have to see
the other splits for each line.  But what I am saying is that if this
split is a debit, put it in the debit column.  If a credit, put it in
the credit column.  That way you can quickly spot a split that is
entered backwards -- "that should have been a credit but was entered as
a debit.

I agree with the unnecessary clutter.

>
> On the #2,
>
> So I shouldn’t be able to see what else might have happened in that transaction, but I always have to see both the credit and debit sides of it? How is that consistent? or possible? If I can’t see the other splits, I can’t see the balancing part of the transaction like you want in #1, or, maybe I see a debit to an expense and the credit to checking, but maybe there were other offsetting debits for other expense accounts in that transaction. Now I’m looking at an expense debit that is less than the credit line and things don’t balance at the least, and worst, now I have clutter that gives me no useful information and can’t see the info I might want to see. (such as, is there a pattern that two expenses go together?)
I agree with your sentiments given your point of view.  If you want to
see all the splits then organize the report as a transaction report
where the splits are grouped together.  Then you can see which ones are
Debit and which ones are Credit splits (and if we total both columns you
can verify that the totals are the same).
>
> I do agree however that the Transaction report is really more of a ‘master report’ of sorts. The multi-column is another. There might be others.
>
> Those should probably be either in their own sub-menu, or the only ones in the main Reports menu. Then the various useful reports one routinely needs that are based off of those masters can be in the topic specific sub-menus.
>
> I don’t see the myriad of options as ‘gold plating’ I see them as making the report more useful. (though obtuse as well)
I apologize as I was using a very specific meaning from project
management theory.  "*Gold plating* refers to the addition of any
feature not considered in the original scope plan (PMBoK) or business
case (Prince2) at any point of the *project* since it introduces a new
source of risks to the original planning i.e. additional testing,
documentation, costs, timelines, etc."
>
> Perhaps if some more routine and useful reports were created from this and added to the relevant sub-menus, less people would need the ‘master report’ though it can still be there for those who know how to wield its power.

Interesting thoughts.  Some of which have flowed past me in the last 24
hours also.  My question is how you would limit the options for a
Reconciliation Report for the user to configure while turning around and
invoking the main report module?  I am not that savvy in Scheme to know
how to do that.

The one thing we need to avoid is having the same code spread around in
4-5 different areas and having to update all when a fundamental bug or
enhancement has to be made that affects all reports. 

>
> Just my 2¢.

Postage in the US is going up 5¢ so best add in some inflation and call
if $2 now!  Appreciate your thoughts -- especially as it shows I didn't
express mine very well and you got a different picture than I was trying
to paint (my wife says I don't paint very well either)!

Let's keep talking as together we can arrive at a common point of view.

>
> Regards,
> Adrien
--Steve

>> On Jan 7, 2019, at 4:50 PM, Stephen M. Butler <[hidden email]> wrote:
>>
>> I think one of the developers here mentioned that there is a lot of
>> duplication in the reports arena.  I concur.  At first it was very
>> confusing as to which was the "correct" one.  Finally figured out none
>> where -- according to the in house SME (pronounced "smee" and standing
>> for Subject Matter Expert) and needed to roll my own.  Of which, I only
>> have the Balance Sheet sorta working like she wants it.
>>
>> Following some email exchange via the bug reporting system regarding the
>> Transaction report module, I agree that it has too many options already
>> and requires a near programmer to figure out which options need to be
>> set what way to get something close to desirable.
>>
>> Please note that I'm not a smee in this arena and, with my project
>> manager hat on, my wife barely qualifies.  There are others on this
>> mailing list better qualified who will have differing opinions.
>>
>> However, here are my thoughts:
>>
>> 1.  A transaction report (however it is organized) should always show
>> the split amount.  I propose that the Amount (None, Single, Double)
>> option be removed and the report always produces the Amount in two
>> columns Debit to the left and Credit to the right.
>>
>> 2.  The Multi-line versus Single-line option may add confusion.  If one
>> wants to group the splits in a transaction together, then the report
>> should be organized that way.  When one picks the multi-line option, the
>> report becomes hard to read and understand especially as the other
>> splits are not included in the totals.  I suggest that Single-line be
>> the reporting style and the multi-line (meaning -- as best I can
>> determine -- multi-splits) removed.
>>
>> These are just two of many simplifications that could be made to help
>> guide the end-user into the reports they need rather than letting them
>> create a report that is useless to them and anybody else.
>>
>> Along those lines, I see this code needing to generate the following
>> types of reports:
>>
>> A.  Transaction Journal -- this one lists the transactions within the
>> date range in date order and keeps all the splits together on the
>> report.  A printed version of the General Ledger screen (in multi-split
>> mode).
>>
>> B.  Reconciliation Report -- rather than have the user pick the
>> accounts, a first pass should show the Dates within Accounts for which
>> there were reconciliations done (with the date range selected).  Let the
>> user select one or more of these to be reported, but each selection
>> becomes its own report or page.  Usually show the transactions
>> reconciled on that date (by account and in date order) optionally
>> followed by the transactions not yet reconciled within that account.
>>
>> C.  Account Details -- here the user should pick the account(s) for
>> which the detailed transaction should be shown for the date range selected.
>>
>> There may be a couple more variants, but if we start thinking about what
>> a bookkeeper/accountant needs we can reduce the number of options
>> available and thus remove complexity from the reports (at least this
>> particular one).
>>
>> As a software engineer, I love to gold plate things.  As a project
>> manager, I realize that gold plates rarely provide the end user with
>> something useful.  Hey, but it looks good!
>>
>> So, which options on the transaction report do you never use?  Which
>> options do you always set one particular way?
>>
>> --Steve
>>
>> --
>> Stephen M Butler, PMP, PSM
>> [hidden email]
>> [hidden email]
>> 253-350-0166
>> -------------------------------------------
>> GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8
>>
>>
>> _______________________________________________
>> 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


--
Stephen M Butler, PMP, PSM
[hidden email]
[hidden email]
253-350-0166
-------------------------------------------
GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8


_______________________________________________
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] Reports -- Cleanup

Geert Janssens-4
Op dinsdag 8 januari 2019 18:25:33 CET schreef Stephen M. Butler:

> On 1/7/19 8:42 PM, Adrien Monteleone wrote:
> > I do agree however that the Transaction report is really more of a ‘master
> > report’ of sorts. The multi-column is another. There might be others.
> >
> > Those should probably be either in their own sub-menu, or the only ones in
> > the main Reports menu. Then the various useful reports one routinely
> > needs that are based off of those masters can be in the topic specific
> > sub-menus.
> >
> > I don’t see the myriad of options as ‘gold plating’ I see them as making
> > the report more useful. (though obtuse as well)
> I apologize as I was using a very specific meaning from project
> management theory.  "*Gold plating* refers to the addition of any
> feature not considered in the original scope plan (PMBoK) or business
> case (Prince2) at any point of the *project* since it introduces a new
> source of risks to the original planning i.e. additional testing,
> documentation, costs, timelines, etc."
>
> > Perhaps if some more routine and useful reports were created from this and
> > added to the relevant sub-menus, less people would need the ‘master
> > report’ though it can still be there for those who know how to wield its
> > power.
> Interesting thoughts.  Some of which have flowed past me in the last 24
> hours also.  My question is how you would limit the options for a
> Reconciliation Report for the user to configure while turning around and
> invoking the main report module?  I am not that savvy in Scheme to know
> how to do that.
>
> The one thing we need to avoid is having the same code spread around in
> 4-5 different areas and having to update all when a fundamental bug or
> enhancement has to be made that affects all reports.

I have a view similar to Adrien's. To me the code behind the current
transaction report can be viewed as a fairly generic (transaction) reporting
engine. I also think that was the intention of the developers that worked on
it. GnuCash can't possibly provide specific reports for all use cases all
around the world. So if none of the reports available gives the required
result, the transaction report allows you to extract most (transaction) data
in some form or another close to what you need.

As it's so generic in nature it can be used (by a coder) as a basis to build
other reports on top off. The Income & GST report is currently such an
example. It has removed a number of options compared to the transaction report
(or more precisely it uses hardcoded defaults for these options).

I agree with Adrien it could be worth looking for common use cases that could
be coded as simplified versions of the transaction report and add them as
separate reports in the menus. From other discussions I take away a
reconciliation report could be a potential candidate for example.

Regards,

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] Reports -- Cleanup

David Cousens
In reply to this post by Stephen M. Butler
Steve,

I would like to add to Adrien's concerns. The reports are for more than an
accountant or a bookkeeper. Many people using GnuCash are managing personal
finances, investments, not for profits, small businesses etc and while they
may need the basic standard accounting reports (balance sheet, income
statement, transaction, cash flow etc.), they also need to have reports
which give them information which is more related to managing those
activities and sometimes they also need to dig deeper into the information.

We need to remember that the options that are there have grown out of user
requests for reports outside the basic reports and/or the need for more or
different information.

An additional concern is perhaps that many users have produced customized
reports based on the standardized reports. I don't know to what extent these
are standalone, but if changes in the underlying report affect the derived
reports then we will hear screams and gnashing of teeth from the user base.

GnuCash is also widely used in many jurisdictions and reporting requirements
and standards and practice can vary in more than just language and date
formats. Fortunately there is a strong international push for financial
reporting standards (IFRS) led by the IASB. The FASB in the US is moving the
GAAP towards agreement/compliance with the IFRS, and is a major participant
in the IASB, but has not yet adopted the IFRS as the basis of its internal
standards. Many European countries and others adopt the IFRS standards with
local variation on top to meet legislative requirements in corporate law,
consumer legislation etc as well as local practices.
https://www.ifrs.org/use-around-the-world/use-of-ifrs-standards-by-jurisdiction/#analysis
has a comlete breakdown of the current position.

David Cousens



-----
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] Reports -- Cleanup

Christopher Lam
Thanks for the interest in reports.

I'd like to take opportunity to explain current state of code.

Examples of duplication:
- html-barchart, html-linechart, html-scatter, html-pie have a lot of
duplicated code; there's a pending work for merging the charting
infrastructure into a universal one, and also upgrading from jqplot to
chartjs (responsive and animated). this is not frozen yet.

Pending work
- transaction.scm may receive a CSV export function. see last commit at
https://github.com/christopherlam/gnucash/commits/maint-export-csv/gnucash/report/standard-reports/transaction.scm
for anyone wishing to experiment.
- multicolumn balsheet is still pending and requires cleanup

Future work
- if reconciliation report gets a lot of attention and refinements it may
be spun off into a separate file like income-gst-statement.scm.
- a header for reconciliation report is not difficult, but the
determination of 'starting and ending balance' for the header is
*difficult* - I'd like to mimic the formal reconciliation tool but I'm not
sure how it calculates the balances.
- organising removal of unused old code

On Thu, 10 Jan 2019 at 05:53, David Cousens <[hidden email]>
wrote:

> Steve,
>
> I would like to add to Adrien's concerns. The reports are for more than an
> accountant or a bookkeeper. Many people using GnuCash are managing personal
> finances, investments, not for profits, small businesses etc and while they
> may need the basic standard accounting reports (balance sheet, income
> statement, transaction, cash flow etc.), they also need to have reports
> which give them information which is more related to managing those
> activities and sometimes they also need to dig deeper into the information.
>
> We need to remember that the options that are there have grown out of user
> requests for reports outside the basic reports and/or the need for more or
> different information.
>
> An additional concern is perhaps that many users have produced customized
> reports based on the standardized reports. I don't know to what extent
> these
> are standalone, but if changes in the underlying report affect the derived
> reports then we will hear screams and gnashing of teeth from the user base.
>
> GnuCash is also widely used in many jurisdictions and reporting
> requirements
> and standards and practice can vary in more than just language and date
> formats. Fortunately there is a strong international push for financial
> reporting standards (IFRS) led by the IASB. The FASB in the US is moving
> the
> GAAP towards agreement/compliance with the IFRS, and is a major participant
> in the IASB, but has not yet adopted the IFRS as the basis of its internal
> standards. Many European countries and others adopt the IFRS standards with
> local variation on top to meet legislative requirements in corporate law,
> consumer legislation etc as well as local practices.
>
> https://www.ifrs.org/use-around-the-world/use-of-ifrs-standards-by-jurisdiction/#analysis
> has a comlete breakdown of the current position.
>
> David Cousens
>
>
>
> -----
> 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] Reports -- Cleanup

Stephen M. Butler
In reply to this post by David Cousens
I appreciate all the responses.  The general consensus is to keep the
existing options and build more specific reports on top of it's
capabilities.

From the comments, it appears a coder could hide many of the options in
order to produce a targeted report that an end-user would find easier to
use and configure.

--Steve

On 1/9/19 1:50 PM, David Cousens wrote:

> Steve,
>
> I would like to add to Adrien's concerns. The reports are for more than an
> accountant or a bookkeeper. Many people using GnuCash are managing personal
> finances, investments, not for profits, small businesses etc and while they
> may need the basic standard accounting reports (balance sheet, income
> statement, transaction, cash flow etc.), they also need to have reports
> which give them information which is more related to managing those
> activities and sometimes they also need to dig deeper into the information.
>
> We need to remember that the options that are there have grown out of user
> requests for reports outside the basic reports and/or the need for more or
> different information.
>
> An additional concern is perhaps that many users have produced customized
> reports based on the standardized reports. I don't know to what extent these
> are standalone, but if changes in the underlying report affect the derived
> reports then we will hear screams and gnashing of teeth from the user base.
>
> GnuCash is also widely used in many jurisdictions and reporting requirements
> and standards and practice can vary in more than just language and date
> formats. Fortunately there is a strong international push for financial
> reporting standards (IFRS) led by the IASB. The FASB in the US is moving the
> GAAP towards agreement/compliance with the IFRS, and is a major participant
> in the IASB, but has not yet adopted the IFRS as the basis of its internal
> standards. Many European countries and others adopt the IFRS standards with
> local variation on top to meet legislative requirements in corporate law,
> consumer legislation etc as well as local practices.
> https://www.ifrs.org/use-around-the-world/use-of-ifrs-standards-by-jurisdiction/#analysis
> has a comlete breakdown of the current position.
>
> David Cousens
>
>
>
> -----
> 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
>

--
Stephen M Butler, PMP, PSM
[hidden email]
[hidden email]
253-350-0166
-------------------------------------------
GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8

_______________________________________________
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] Reports -- Cleanup

GnuCash - Dev mailing list
In reply to this post by Stephen M. Butler
If the reports are getting some attention now, I'll note that there are a number of minor bugs in Bugzilla regarding reports that could use attention. I put in 773168, 773169, 773198, 773199, and 773200, which are all pretty superficial, IMHO, and might be despatched by someone with any skill set all (I am unfortunately not that person).

David

On January 10, 2019, at 7:33 AM, Christopher Lam <[hidden email]> wrote:

Thanks for the interest in reports.

I'd like to take opportunity to explain current state of code.

Examples of duplication:
- html-barchart, html-linechart, html-scatter, html-pie have a lot of
duplicated code; there's a pending work for merging the charting
infrastructure into a universal one, and also upgrading from jqplot to
chartjs (responsive and animated). this is not frozen yet.

Pending work
- transaction.scm may receive a CSV export function. see last commit at
https://github.com/christopherlam/gnucash/commits/maint-export-csv/gnucash/report/standard-reports/transaction.scm
for anyone wishing to experiment.
- multicolumn balsheet is still pending and requires cleanup

Future work
- if reconciliation report gets a lot of attention and refinements it may
be spun off into a separate file like income-gst-statement.scm.
- a header for reconciliation report is not difficult, but the
determination of 'starting and ending balance' for the header is
*difficult* - I'd like to mimic the formal reconciliation tool but I'm not
sure how it calculates the balances.
- organising removal of unused old code

On Thu, 10 Jan 2019 at 05:53, David Cousens <[hidden email]>
wrote:

> Steve,
>
> I would like to add to Adrien's concerns. The reports are for more than an
> accountant or a bookkeeper. Many people using GnuCash are managing personal
> finances, investments, not for profits, small businesses etc and while they
> may need the basic standard accounting reports (balance sheet, income
> statement, transaction, cash flow etc.), they also need to have reports
> which give them information which is more related to managing those
> activities and sometimes they also need to dig deeper into the information.
>
> We need to remember that the options that are there have grown out of user
> requests for reports outside the basic reports and/or the need for more or
> different information.
>
> An additional concern is perhaps that many users have produced customized
> reports based on the standardized reports. I don't know to what extent
> these
> are standalone, but if changes in the underlying report affect the derived
> reports then we will hear screams and gnashing of teeth from the user base.
>
> GnuCash is also widely used in many jurisdictions and reporting
> requirements
> and standards and practice can vary in more than just language and date
> formats. Fortunately there is a strong international push for financial
> reporting standards (IFRS) led by the IASB. The FASB in the US is moving
> the
> GAAP towards agreement/compliance with the IFRS, and is a major participant
> in the IASB, but has not yet adopted the IFRS as the basis of its internal
> standards. Many European countries and others adopt the IFRS standards with
> local variation on top to meet legislative requirements in corporate law,
> consumer legislation etc as well as local practices.
>
> https://www.ifrs.org/use-around-the-world/use-of-ifrs-standards-by-jurisdiction/#analysis
> has a comlete breakdown of the current position.
>
> David Cousens
>
>
>
> -----
> 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
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel