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