Maximo Open Forum

Pradeep, that information is not stored anywhere.  It might be possible if the BIRT report was run in debug mode, to see the SQL that was executed every time the report was run, but then you would have a file folder on the server filling up with BIRT debug files.  You would then need to open each file, troll through the SQL that is displayed, and find the workorderid, or the wonum if it is available.  Not a very realistic solution I am afraid.

Thanks Stephen for your valuable input. We want to automatically write the where clause used to run the reprot so that this can be tracked at object level rather than navigating to find it from logs. The requirement triggered from a question from QA team asking how we can limit the prints to the reports if some thing is already printed by user for same record we want to restrict for further print due to requirement related to handling physical copies of GMP records.

------------------------------
Pradeep Rout
TCSL
------------------------------


Original Message:
Sent: 01-10-2025 09:20
From: Stephen Hume
Subject: Is there any way to find what record against the BIRT report ran on reportusage log?

Pradeep, that information is not stored anywhere.  It might be possible if the BIRT report was run in debug mode, to see the SQL that was executed every time the report was run, but then you would have a file folder on the server filling up with BIRT debug files.  You would then need to open each file, troll through the SQL that is displayed, and find the workorderid, or the wonum if it is available.  Not a very realistic solution I am afraid.

------------------------------
Stephen Hume
Sheffield Scientific LLC

Hello Pradeep,

I'll like to connect with you and offer a few recommendations. Like Mr. Hume indicated, looking at log files can be tedious but I think it is possible to find a reasonable solution that you can handle in the front end. 

Let me know when will you like to connect.

Thanks

------------------------------
Jhonatan Jerez
------------------------------


Original Message:
Sent: 01-10-2025 11:14
From: Pradeep Rout
Subject: Is there any way to find what record against the BIRT report ran on reportusage log?

Thanks Stephen for your valuable input. We want to automatically write the where clause used to run the reprot so that this can be tracked at object level rather than navigating to find it from logs. The requirement triggered from a question from QA team asking how we can limit the prints to the reports if some thing is already printed by user for same record we want to restrict for further print due to requirement related to handling physical copies of GMP records.

------------------------------
Pradeep Rout
TCSL
------------------------------

Pradeep

One possible solution is to insert a new record into a custom table each time a work order (WO) print is executed, using an insert statement within the report. This custom table can be designed to track specific WOnum values or store where clause. To maintain efficiency, the table should be cleared periodically.

The idea of doing an update in the birt report is possible, but instead a custom table, or the report usage log, why not just add an attribute to the work order table called dateprinted and update when the report is run.  You should also allow for "reprinting" of the workorder because nobody is perfect, so put the "date printed" field in the workorder application and you can protect that field with a signature option, but allow it to be blanked out so that the work order can be reprinted.

In your birt report select statement you will need to add "and dateprinted is null"

Users will need to be trained so that if they try to run the birt report for a workorder, that they may get a blank screen back instead of a work order print.

This could also get complicated if they are printing a list of workorders and not all of them print out.

Also good luck getting the BIRT report to do the update statement, I have seen it before in the asset cost rollup report, but it is not straightforward.

The idea of doing an update in the birt report is possible, but instead a custom table, or the report usage log, why not just add an attribute to the work order table called dateprinted and update when the report is run.  You should also allow for "reprinting" of the workorder because nobody is perfect, so put the "date printed" field in the workorder application and you can protect that field with a signature option, but allow it to be blanked out so that the work order can be reprinted.

In your birt report select statement you will need to add "and dateprinted is null"

Users will need to be trained so that if they try to run the birt report for a workorder, that they may get a blank screen back instead of a work order print.

This could also get complicated if they are printing a list of workorders and not all of them print out.

Also good luck getting the BIRT report to do the update statement, I have seen it before in the asset cost rollup report, but it is not straightforward.

Hi Pardeep,

I think you need a separate table to store the details of the record OR to add a column to the reportusagelog table to store the record details.

Adding a column to the WORKORDER table will only capture the LAST time that someone printed out the report.

If two people print out the report then only the last person wiil be recorded.

The solution you use will depend on what you want to achieve.

if you want to record the where clause then you have to appreicate that sometimes the where clause will refer to multiple records and that the structure of the sql used in the where clause can change depending on how the records are selected for printing e.g. from the list screen

best regards,

Mark

Hi Pradeep,

There seems to be a mismatch between the summary and detail of this thread, but I believe the actual requirement is:

1. To know what report was run against the work order.
2. To know how many times the report was run.
3. If a limit has been set regarding the number of reprints, stop printing if this is reached.

However, this is more about knowing that the report has already been printed than stopping printing.  The WO Print report is usually not something that I would class as a controlled document, but let's think along those lines or like when you get a reprint of a receipt.  Typically, when you do the reprint, it splashes a "REPRINTED" or something else and maybe the original date.  The trick is to capture the fact the report was ever run for a particular record and has been mentioned; no table records down to the record level.

A complicating factor is that the WOPRINT can be run from the main (single work order), or the list tab (multiple work orders) or from the WOLIST report via the hyperlink embedded in the report back to the WOPRINT report.  As Stephen mentioned, you would need to add an INSERT statement to the report that populates a new table.  There are many reports that could be run against any work order, so you need to design this in a plug-and-play statement for other reports if you want to do the same.

Then, in the report, you would read the table finding the first instance of it running and you would then annotate or the like "REPRINTED" onto the report.

At this point, I have not successfully thought of how this could be done via an automation script, and we do know the BIRT is capable of doing updates it's just I have not done that in MAS and there is a reason that IBM removed the update from the likes of the Maintenance Cost Rollup report (excluded a cron task now being used).

Now let's look at Stephen's other suggestion about updating the work order instead of a table as I believe you are only concerned with a single report WOPRINT.  This is the best solution as you only want to know the first time that the report is run.  Then everyone can see that it has been printed, whereas using a new table would involve adding it to the application in a section or new tab and could get missed.  This solution still relies on being able to execute SQL from BIRT, taking note of my earlier comment.

Good luck.