We have a custom report that prints for every job within a specified date parameter. It is important that we don’t print the job report after they are printed the first time. (The job traveler report has similar logic built in).
Does anyone have any examples of how this could be done?
For example, I choose tomorrow’s date and jobs 1, 2, and 3 print. How could I stop them from printing the from again?
Please let me know if I am not explaining myself clearly.
I would approach that by adding UD fields to the JobHead table, (a date and a check box), then hang a BPM on whatever process you are using to print the report and then update that date, and set the checkbox to true.
I have something similar for sending a rest call out to our task management platform to create a task. (except the checkbox is what sends it)
Once you figure it out, it opens up a whole new world of possibilities. You can make UBAQ’s that you call using DynamicQueryAdapter so you can put all of your fancy logic server side.
An example of when I use it is to check if files exist. I put a BPM on post processing for get list, and run a custom code block to check for the file name and change a check box to true if it finds it. Works great!
I will warn you though that the JobEntryBO can be kind of slow if you attach the fields to JobHead. I’ve made solutions where I just used a UD table and duplicated the necessary header info. It made things much faster since the UD tables don’t have any rules on them.
If are using a UD table, you can do a regular UBAQ with the BO like this. You can just make the UD table join a left one, so if there isn’t a matching record, you can make a new row. Not sure how that would work with the report though…
So you would make a UD table then write the Job that was printed to the UD table instead of making a UD field on job because there are so many BOs connected to it… that isn’t a bad idea.
Keep in mind that if you put it on get list, it will do it every time you getlist on the BAQ, so be prepared to not be able to test real well. There is probably some context fields that you can put a condition on, but I’m not sure exactly what it would be.
@Banderson has probably the best solution for your particular case, but it’s also worth mentioning that if you want confirmation that a report has been successfully printed rather than only sent to print, you can hook a BPM on the SysRpt tables … with great care, obviously, because you don’t want to bog the system down every time every report runs.
