Preventing PDF_Report_Created event action sending email when a Purchase Order Work Copy is printed
Hi,
We have recently upgraded to IFS 10 (UPD14).
We have an Event Action configured to email suppliers a copy of the Purchase Order PDF when it is printed, using the system defined PDF_REPORT_CREATED event.
We have noticed that when our users print a “Work Copy” of the purchase order, it is causing this event action to fire and sending the supplier an additional copy of the purchase order.
We would like to prevent the Event Action from firing when a user orders a “Work Copy” of the Purchase Order.
I have tried looking at the Conditions for performing this action to see if I can use the “Report_Parameters” to do this.
When the Purchase Order is printed, the report parameter PUR_ORDER_PRINT_OPTION = Order
When the Purchase Order is printed, the report PUR_ORDER_PRINT_OPTION = Order Work Copy
I believe the PUR_ORDER_PRINT_OPTION is the last data element of the report parameter, so I have tried putting this in the conditions section like below. This does not work (I think because the report parameters are not a string).
Is there a way to achieve this using conditions on report_parameters?
Or has anyone got a different way to achieve this?
Thanks,
Ashley
Page 1 / 1
This is a continuous problem really with the way this event works.
We’ve only been able to work around it by making sure that all users don’t print a work copy, rather they email a copy to themselves or better yet, use print preview and then save a copy if needed.
It is the printing of the PDF going to the report archive that makes the unavoidable issue of the secondary email to the supplier (or however many times it occurs). We haven’t found a way either to separate this so that only the first real printing of the PO gets sent and not subsequent prints or worse the work copies.
The auto pdf send event is useful and a time saver, but also is a big headache because it doesn’t have enough control levers to narrow how you want to use it.
@ShawnBerk, @AshT
I know this is a year old, just posting this in case someone else comes accross this.
Whether the user picks a regular print, a change order print, a work copy or change work copy print is not going to be stored as report parameters.
That being said, It is recorded (at least in UPD17 onwards, haven’t checked before) within REPORT_VARIABLES and is available to the PDF Event Action to look up and filter from.
The following code is used:
It shows up in the Report Substitution Variables as such when the event triggers, although it’s concatenated in a weird way and only seems to return tOption1, so there’s no way of differentiating between order changes and order changes work copy (as tOption1 is the same for both of these)
Print Order :
Print Order Work Copy :
Print Order Changes:
Print Order Changes Work Copy:
So that means you can at least differentiate between Print Order, Print Order Work Copy, and the two others.
So, for instance, if you make your event only trigger when REPORT_VARIABLES = tOption1-1, you should ensure it only triggers for “Print Order” selection, not for any of the other three.
There are other ways to check more in depth whether a particular result key is one of the specific 4, but it’d require changing your event to be Online SQL and not just straight Email type.
Through Online SQL Event, you can check either the ARCHIVE_VARIABLE or ARCHIVE_PARAMETER view for the result key provided, and you’ll get results like this:
Archive Variable:
(You can follow the code above and confirm tOption1 = 1 and tOption2 = 0 means “Order Changes Order Work Copy”)
Archive Parameter::
In which you can see field PARAMETER_NAME for PUR_ORDER_PRINT_OPTION will straight up tell you which button the user clicked.
Hope that helps :)
@SimonTestard > Thanks for that information! We were still struggling, but are on UPD21 now so will have access to this.
