IFS Cloud Email Purchase Orders: Event Set-Up

When a purchase order report is created as a PDF, the PDF_REPORT_CREATED event is raised, and an action of type E-Mail attached to that event sends the mail. Three things therefore have to be in place: the event, the action and a configured mail path. The page states that IFS/Connect has to be installed and the MAIL_SENDER connector has to be configured properly.

Without a condition the mail is attempted each time any PDF file is created, which is why the action needs one (section 3). The approval step that precedes the mail is a separate topic, covered in the purchase order approval workflow, and events that you define yourself are covered in custom events in IFS Cloud.

The page names the event and action prerequisites: an action with type E-Mail must have been created for the PDF_REPORT_CREATED event, and the event must be enabled. Master data has its own prerequisites. On the Supplier/Purchase/Print/Email page, the option E-mail Purchase Order should be enabled, and the supplier contact used must have an e-mail communication method. The page also describes a lookup for the contact; one step reads: if that is empty, use the primary contact for the supplier address.

On the order side, the page on printing a purchase order states that the purchase order must have been released and cannot be Cancelled, and that the Print Purchase Order option must be enabled. When the order is printed, the Communicated option on the purchase order header is enabled. The option alone does not show that the mail arrived, so check that separately.

The REPORT_TITLE condition restricts the action to the intended report. The page says to make sure that the REPORT_TITLE condition is equal to the report title, and it adds a note: without this condition, IFS/Connect will try to send this e-mail each time any PDF file is created.

The consequence for design is that an action without the condition belongs to every report that produces a PDF. A purchase order mail template can then be attempted for a document that is not a purchase order. Write the report title into the design record next to the action, and test with a second report that also creates a PDF.

For purchasing, the information is passed in the event parameters PDF_PARAMETER_1 through PDF_PARAMETER_10, and the page’s table has an eleventh column. The table shows the columns that matter for a purchase order.

In an action, a parameter is written with a leading ampersand, for example &PDF_PARAMETER_1. The page also names REPLY_TO_USER, written &REPLY_TO_USER, which retrieves the e-mail address specified for the coordinator in User Details. That makes it possible for the supplier to reply to the purchase order coordinator.

When PDF_PARAMETER_1 has no value and the event action is triggered, the result is an application message with status Failed. The page suggests guarding against this with the condition (PDF_PARAMETER_1 = %), so that the action runs only when an address is present.

A Failed message is a record that someone has to read. Decide who monitors application messages with status Failed. A supplier whose contact has no e-mail address should be found by a data check before go-live, and not by a missing delivery. The data side is covered by the contact prerequisites in section 2.

The page gives an example action for a purchase order. To is set to &PDF_PARAMETER_1 and From User to &REPLY_TO_USER, the subject is Notification of Purchase, and the message starts Dear &PDF_PARAMETER_4.

To attach the report, use the option Attach when defining the action and enter &PDF_FILE as the file name. The page also describes two refinements. A language-specific message uses the LANGUAGE_CODE condition: if the supplier’s language code is German (de), the condition LANGUAGE_CODE = de can be given. And an action can use a specific mail sender connector, for example where some mails are sent as text/plain and some as text/html.

The page on printing a report states that you can redirect the generated report or report data to different output channels or destinations. You can use the Send to Connect, Send Email or Print To Logical Printer action type to send a generated PDF report as an e-mail. For a one-off mail, the same page describes the Send Email slider, in which you enter the e-mail address you want.

Output routing offers more than one route, so decide which route each purchasing document uses, and record it where the support team looks: see the handover to support. For the files that users attach to records, as opposed to the PDF that this mechanism attaches to a mail, see IFS Cloud document attachments. Workflow design around purchasing steps is covered in IFS Cloud workflows.

Test the set-up with purchase orders that cover the cases the page describes, and write down the expected result before each test. The method for planning such tests is in testing in IFS Cloud.

The e-mail output is ready for go-live when each of the checks below has a record behind it.

1. IFS/Connect is installed and the MAIL_SENDER connector is configured.
2. The PDF_REPORT_CREATED event is enabled and an action of type E-Mail exists for it.
3. The action carries a REPORT_TITLE condition equal to the purchase order report title.
4. The action carries a guard condition for an empty PDF_PARAMETER_1.
5. Suppliers that receive orders by mail have the option E-mail Purchase Order enabled and a contact with an e-mail communication method.
6. Someone monitors application messages with status Failed.
7. The four test cases are recorded with evidence.

Dariusz Myśliwiec: 18 years hands-on with IFS, including IFS Cloud. Based in Kraków, delivering remotely across Europe and globally through an independent practice. You talk to the consultant who does the work, not a sales layer.

IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.