Tim - responses as follows:

a) circumstances: I currently have the following reports which use the Current Patient (@pid macro): Patient Weight History (lists and charts current patient weight history); the following use the Current Customer (@cid macro): Extended Statement (generates statement over multiple months, with back to time that the openening balance was zero, or the last time the running balance was zero), Customer Running Balance, Customer Notes and/or Alerts (for either specific or all customers); and I currently have no 'current supplier' reports.

The concept of reporting on the current patient/customer is that the customer and patient workspaces have nice select facilities for finding the customer/patient you are interested in, but if you want to run a report on that customer/patient, then without the @cid/@pid kludge the only way to do this is to write down the customer/patient ID and then enter this number as a report parameter.

b) buttons for common reports - this would be neat - I was trying to keep things as simple as possible and figured that simply using the current Reporting|Reports code with the report type preselected would be good enough.

c) query report type - I was envisioning that the ONLY output from a 'query' report was columns to the screen, no PDF, no export, no print, no email - just the screen output.  In fact, I might not object if only screen output was available from Customers|Reports and Patients|Reports. In fact, maybe we should add not Reports, but rather Queries, and just as Reporting|Reports selects only document templates of type 'Report', then  Customer|Queries selects only document templates of type Query. However, this may be throwing the baby out with the bathwater since the current reporting system is so powerful and flexible. If we were not tight on left panel real estate (and used a drop down menu system) then I perhaps would suggest adding both - however, with a drop down it would be just as fast to select Reports/Queries from the Customer menu as the Reports menu. [I did say that my ideas were not fully formed.]

I also must admit that I have not thought about whether the the SQL query could delete or update records - is some ways it might be neat to run an update query for some things - but it might be wiser (if possible) to make sure that the SQL connection is in readonly mode.

Regards, Tim G

Tim A - I think we need to pick this up again. I am starting on my 'renovate the standard reports' project, and the first one I picked to work on is the current 'Customer Reconciliation Report' - which will be functionally replaced by the 'Customer Running Balance Report' [which adds a running balance column].

This needs the customer id as a parameter. My version uses a text field to allow you to use the @cid macro to get the current customer id - but this is a kludge and I do not really want to use it in the standard reports.

Hence my need for an auto filled $P{CurCustID} parameter - I have a suspicion that we should stay away from 'customer' or 'customerID' as the name of the parameter to avoid conflicts with current reports that users may have.  [The 'Customer Reconciliation Report' uses 'customerId'.]

Also - if it is easier, I would not error the report if there was no current customer, just set it to null and leave it to the report writer to generate an appropriate message.

I would also be happy to go with just setting the CurCustID, CurSuppID, and CurPatID parameters when running a report from Reporting|Reports - and not worry about the other sexy bits for the time being.

Regards, Tim G