Skip to main content

I am using IFS Apps10 and have a problem with Purchase Orders being emailed to the Requisitioner without them requesting it. It appears in the  requisitioner’s inbox with the subject “PDF file for Purchase Order report for result key <result key> is ready”

When I check the Report Archive it says it was ordered by the Requisitioner but he has not ordered it. There is no custom event or scheduled task triggering it. I think it is occurring when the PO is closed but I am not sure. I don’t think it is occurring for everybody, just this one person and has only started occurring recently. 

The only way I am aware of that you can receive this mail is if someone sends it manually from the Purchase Order screen by selecting RMB-“Print Order” and then ticking the “Send Email to” box and entering an email address in the text box below that.

I can’t see how it can be happening in an automated way., I have checked everywhere. I need to stop it however.

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.


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.

Nope, it’s not under PDF_REPORT_CREATED, that was the first place I checked.


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


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

 

Hi, no I was unable to find what is causing this mail to be sent. It occurred last April but hasn’t happened since. Sorry I can’t be of more help.


@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.


Did you ever figure this out ?

 

I have the same problem. Some users (not all, like I am not affected for example) are receiving the “PDF file for Purchase Order report for result key xxx is ready” when they Print a Report. This is not limited to Purchase Orders but happens for other reports as well.

 

I do have a PDF_REPORT_CREATED event action which does send a customized email, which I (and my users) ALSO receive as expected, but some of them receive this “PDF Is Ready” Email in addition to it, and I can’t figure out what controls that behavior ?!

 

For example, one of my users, when she RMB > Prints > Send Email To > Herself ends up getting two emails :

 

 

If I do the exact same steps, I only get one email, the top (customized) one.

 

My users don’t want the automated email one, they just want the customized one, but I can’t figure out what to change to disable that automated “is ready” one?

Again, like @jdoherty said, there is not a secondary event action or anything like that set up to send that second email, it seems to be user specific, and I can’t replicate the problem with my own user account.

Thank you in advance for your input


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.


It’s a bit of a mystery for sure


It’s a bit of a mystery for sure

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  for taking the time to detail that out.  Very concise explanation of the various levers that control this function.


Thank you @SimonTestard

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


Hi @SimonTestard 

 

 

I have a question about sending emails. It works for me for the customer invoice, but not for the purchase order, because they didn't use the switchboard. 

id report = C_PURCHASE_ORDER_PRINT_REP

and I get this error message below 

 

 

How do I do it? Do I have to use report rules?


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.

 


hi @SimonTestard 

 

 

Yes it's spe

Here's what I found

 

 

Shouldn't this table be set to standard so that amils can be sent? 

 

thank you for your help

 


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 

 

I will look into the problem with a developer as it is beyond my skills as I am functional. Thank you very much for your help. 


Hi @SimonTestard 

 

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

many thanks !!


Hi @SimonTestard 

 

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

many thanks !!

 

No problem

 

By the way Arcwide is one of our consulting partners, so normally I’m the one getting help from you guys =p


@SimonTestard Thank you for posting your solution but it didn’t work for me. Even after entering email addresses to the SMTP_MAIL_ADDRESS Property the email is still being sent. Your post referred to two emails being sent but my issue is that I don’t want this mail to be sent at all. But I am unable to see where it is being sent from.


Can you post a copy of the two application messages for each message being sent please, as well as a copy of the user’s set up for SMTP_MAIL_ADDRESS, and the MAIL_SENDER too.


Can you post a copy of the two application messages for each message being sent please, as well as a copy of the user’s set up for SMTP_MAIL_ADDRESS, and the MAIL_SENDER too.

Hi, 

My problem is not that there are two emails being sent for the Purchase Order. I don’t want an email to be sent at all. It should not be being sent because there is no action enabled for Purchase Order in the PDF_REPORT_CREATED event. 

A screen cap of the mail sent from Application Messages is below.

 

 


These “PDF file for Purchase Order report for Result Key” application messages are not based on any event.

 

They’re a Java implementation on the client when someone prints a report and selects “send email to” in the tickbox

 

 

 

Using these text translations:

 

 

These aren’t generated from an event at all. I don’t believe there’s a way to disable access to this tickbox although I could be wrong.

 

Are you saying you’re getting those emails even if you are not ticking this box ?

 

If so can you show us the results from print_job.settings for the print job in question?

 

 


These “PDF file for Purchase Order report for Result Key” application messages are not based on any event.

 

They’re a Java implementation on the client when someone prints a report and selects “send email to” in the tickbox

 

 

 

Using these text translations:

 

 

These aren’t generated from an event at all. I don’t believe there’s a way to disable access to this tickbox although I could be wrong.

 

Are you saying you’re getting those emails even if you are not ticking this box ?

 

If so can you show us the results from print_job.settings for the print job in question?

 

 

I am beginning to think that someone is doing an RMB-Print on the PO screen and then emailing it to the person who is receiving the mail. It is not being emailed by IFS, an individual is doing it.

I don’t know why anyone would do that I though.


Reply