Purchase Order automated email

Have you looked for event actions under PDF_REPORT_CREATED?  It is possible to configure the email automatically when a pdf is created which could go back to the requisitioner when the order line is received.  I’m not sure why it would be only one user experiencing the notification, but the message looks similar to the type we send when certain reports are created.

You don’t have to use the Send Email to box just to send it, it can happen anytime a pdf report is generated if the above event action type is active.

Hi @jdoherty were you able to find the root cause? We are also facing the same issue, experienced only by one user. I created a topic yesterday for this.

Reprint PO sends email automatically only for one user | IFS Community

@Asela Munasinghe 

I had one user who caused a large number of previous POs to be resent.  When I went through the methodology he had used to start the process, this is what I found.

I would bet he is doing RMB and Print Order, then when the print dialog comes up, he is sending the email to himself to get a pdf copy, however, this triggers a report archive entry which IFS comes along later and prints on the event.

He needs to select preview only and save a copy

Never print or email from that dialog unless you also want to send it to the supplier, it will do the send in the background when the event sees the new report archive entry

It does this because a new copy of the pdf is created and the event says it needs sent to the list

I think the only way to troubleshoot a single user problem is to watch in detail what they are doing when they are updating or operating on a PO to get to the bottom of the problem.

Also like I said, it happens for a few different users and a few different reports. For instance, Shipment Delivery Notes as well:

The top one is the customized one that I am expecting the recipient to actually receive.

The bottom one is some sort of Automated one that not every user gets, and that I can’t seem to replicate either.

Ok I actually finally figured it out with some extra investigation. Just documenting the details in the event any IFS user comes across this community post in the future and wonders about the same thing we did:

By default, out of the box, if you have no Custom Event Action for sending email, when you print a report and select the “send to email” option, IFS creates an Application Message to send the email out, with this message of the PDF File being ready.

If the user that requested the print has no SMTP_MAIL_ADDRESS Property set (Against their User/User Properties record), it defaults the sender to the default sender associated to the MAIL_SENDER being used (typically MAIL_SENDER1)

If the user DOES have an SMTP_MAIL_ADDRESS Property set, it tries to set the sender to that SMTP Mail Address using the “Send As” functionality on the default account for MAIL_SENDER.

In my case, MAIL_SENDER1 is obviously configured with a specific “generic” no-reply type Mail Account, and that account does not have Send As Privileges on any regular user mailbox.

So, when the application message is run, it fails, and does not send an email, because the Exchange Server API effectively replies to IFS that the MAIL_SENDER mail account is not authorized to “Send As” from the end user account.

However, when using a Custom Event Action to send the Customized Emails, we obviously hardcode the Sender to be either our MAIL_SENDER itself, or an alternate address that our MAIL_SENDER has “Send As” privileges for (not actual end users), and therefore that application message does end up succeeding.

Which means that when you do RMB > Print > Send To Email, it actually triggers 2 Application messages (if you have a custom event action to send an email upon printing).

However, the “PDF File is ready” one will fail for any user with a properly set up SMTP_MAIL_ADDRESS (because of a lack of privileges), and therefore the user only receives the 1 Email.

So all in all, the root cause of that problem was, you guessed it, that my users that were receiving the two emails did not have their SMTP_MAIL_ADDRESS property properly set, therefore the “PDF File is ready” application message defaulted the sender to the default MAIL_SENDER mailbox itself (which obviously has privileges to send as itself), and hence the two Application Messages were succeeding !

Hope this little bit of technical info helps anyone who might come accross it in the future!

Thank you @SimonTestard. 

The issue has not occurred again for me but if it does this will help a lot. 👍

Ok two things, first you seem to be using a customized/modded Purchase Order Report (hence the C_ in fornt of it)

Second, the error here occurs before the sending, the background job itself fails to “create and print” the report archive result key set, which is BEFORE the email actually sends.

From the error message, the code in your customized/modded RPI package, probably C_Purchase_Order_Print_RPI.Execute_Report (although I can’t be sure as I don’t have access to your codebase) seems to be trying to create a duplicate entry for rhSysLogo, whatever that is, against the ArchiveVariable entity.

For example, in the out of the box code, it is this:

Whatever customized code you’re using seems to havel ogic that tries and set ‘rhSysLogo’ twice somehow.

As this is customized code, I can’t really help much more than that unless you provide the code of your customized RPI used to create the report ID result set.

I don’t know that the email sending is your problem here, this code issue happens when it tries to print and create the result set, which is before sending it.

In that particular case, this archive variable is being set twice, as part of the loop.

Whatever your get_p_o_header cursor is, it seems to return more than 1 row, meaning it tries to set the same archive variable ‘rHSysLogo’ twice, which is not allowed in that logical unit.

Hi @SimonTestard 

it came from the REP table in Spe, a developer made a modification and it works fine now. 

many thanks !!