Custom Reports and Backup

[Colin Scott]

> 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.

I think you may have misunderstood where I was going.  I was suggesting a
way that *the user* might define the accounts list in a report.
Currently, all the accounts to be included when the report is run must
exist at the time the report is defined, as the definition explicitly
lists each account.  My proposal was that in defining a report the user
should be able to mark an account so that when the report is run that
account and all its children *existing when the report is run* (but not
necessarily when it was defined) are included in the report.  This would
imply that only a sparse list of accounts need be included in the report
definition;  at report run-time the list of accounts *actually* existant
would be compared with that sparse list and its flags, and the actual
selection of accounts to include in the report would be made then, at
report run-time.

In other words, the list of accounts would only be fully evaluated at
report run-time rather than report definition-time.

To illustrate, let us take a hypothetical accounts hierarchy containing,
amongst the ususal top level accounts, "Income",  with no accounts
beneath it.

If one were (step 1) to define a report, saying that it should include
"Income" *and all its children*, then running the report (step 2) would
only include the "Income" account.  However, if one were then (step 3) to
define sub-accounts "Dept1" and "Dept2" under "Income", and then re-run
the report (step 4) then the newly created sub-accounts would appear in
the report too.  (Currently you would have to re-define the report to
include them).

This, then, was the first part of my proposal, although I would expect
the "and all its children" option to be applicable to any account at any
point within the hierarchy,  *whether or not that account actually exists
at report definition-time*.  If it doesn't exist at report run-time then
the flag should simply be ignored.

The second part of my proposal was perhaps a little less clear, but I
believe it would add to the value of the first part.  To illustrate this,
I would continue the example above.  The suggestion is that at step 1 one
should also to say _exclude_ any account (let us call it
"Income:Dept1:special") and all its children.  At steps 2 and 4 this flag
would be meaningless, so would be ignored.  However, were I then (step 5)
to create the sub-account "Income:Dept1:special" and (step 6) re-run the
report, then the "Income:Dept1" subtree would be included without its
"special" branch.

There are some further variations on this theme that might be useful, but
I think those two suggestions would enable any gnucash user running
multiple sets of books to resolve many of the problems I have described
relating to the generalisation of report definitions.

> 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.

That was my first thought, and it would certainly have some merit, and it
would solve my original problem of keeping reports and the relevant
accounts data together, but it is by no means an ideal solution.  I'm not
actually sure there *is* an ideal solution!  :-)

> 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.

I am not sure what you are getting at here.

Colin