Custom Reports and Backup

[sunfish62 at yahoo.com]

Colin--

This is an interesting idea, but fundamentally flawed in that while account definition might be abstracted to a certain extent, ultimately, a programmer cannot be certain about ANY specific accounts in a file.

As I consider the problem further, I'll note that custom reports are all saved in one saved-reports file in the profile directory. Would it be possible to change the custom reports to save into a file that is identifiably linked to the data file and stored with the data file. I am imagining here that if I have a data file "Company A Books" that in the same folder I would find "Company A Books-saved-reports" which would contain all that file's custom reports.

How does Gnucash finesse the situation currently? It loads the reports, but running them yields no matching transactions. I'm not sure that this is particularly useful.

David

--- On Fri, 6/5/09, Colin Scott <gnucash at double-bars.net> wrote:

> From: Colin Scott <gnucash at double-bars.net>
> Subject: Re: Custom Reports and Backup
> To: sunfish62 at yahoo.com, stepbystepfarm at mtdata.com
> Cc: warlord at MIT.EDU, gnucash-user at gnucash.org, gnucash at double-bars.net
> Date: Friday, June 5, 2009, 6:40 AM
> 
> I have been giving this some thought.  One of the
> major reasons that
> different sets of books will require their own tailor-made
> set of reports
> is that the account list for a report must explicitly
> mention each
> account to be included, and the accounts list in the report
> definition
> will thus differ between different sets of books.
> 
> It seems to me that this part of the problem relates to the
> need to be
> able to say "include in the list Account-X and all it's
> child accounts".
> At the moment, one must list the entire tree beneath
> Account-X.  How much
> simpler it would had the list  a bit of syntax to say
> "this account and
> all its children" - implying that the set of children would
> be evaluated
> when the report is run rather than when it is
> defined.  This would not
> only address the issue of report tailoring, but would also
> address a
> matter I raised some months ago, that if one creates a
> report, and then
> adds a new account, then that new account will be omitted
> from the report
> until the report is re-specified.
> 
> And to extend that concept a little, a bit of syntax that
> said "EXclude
> this account and all its children" (which might be applied
> to a specific
> child within a generically included tree),  similarly
> to be evaluated at
> report run-time, would add even more flexibility - and one
> could then
> probably generate pretty much universal reports, the only
> features now
> necessarily tied to the set of books in use being the
> report title and
> company name.
> 
> Colin
>