[GNC-dev] Reports -- Cleanup

Stephen M. Butler kg7je at arrl.net
Mon Jan 7 17:50:39 EST 2019


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
Stephen.M.Butler51 at gmail.com
kg7je at arrl.net
253-350-0166
-------------------------------------------
GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8




More information about the gnucash-devel mailing list