[GNC-dev] Reports -- Cleanup

Geert Janssens geert.gnucash at kobaltwit.be
Wed Jan 9 09:24:38 EST 2019


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




More information about the gnucash-devel mailing list