Spam:****, Re: Profit and Loss Statement for Closed Books

Colin Scott gnucash at double-bars.net
Thu Mar 22 17:29:00 EDT 2012


> The issue here is that the reports are a conglomeration and
> accretion over time.  Then new features get added, but that does not
> mean that developers go back over all the reports to make sure each
> one "works" with the new features.  This is a lot of work, so it
> falls by the wayside when other progress is made.
> 


Even though the report set "just growed", as you describe, there is little reason not to ensure that the operation and output of a new report conforms more or less with the operation and output of those preceding it.  Thus I would expect there to be standardised sets of parameters(eg, to include account filter selection) standardised facilities (eg, sub-totalling, grand-totalling, etc etc) and standardised output formats (eg, standard notation for column breaks, page headers and footers including things like report title and date(s), and page numbering in the form "<page number> of <n> pages")  I'm not suggesting that all new features/facilities should be retro-fitted as they appear, but that they *should* be fitted in all subsequent new reports, and whenever a significantly revised version of a report is produced.  

> Are you offering to go and test each report against each new 
> feature to make sure it "works correctly"?

No.  No more, I would guess, than you are suggesting that those contributing reports, and those accepting them for release, don't test that the features used actually work ...  :-)

Colin


More information about the gnucash-user mailing list