IFS Cloud Email Customer Documents: Set-Up Rules

The documentation describes three customer documents, each with its own route. The invoice page is for e-mailing general customer invoices and credit notes to the customer, and the invoice is attached to the e-mail as a Portable Document Format (PDF) file. The quotation page covers e-mailing a sales quotation as a PDF. The order confirmation page describes sending the customer order confirmation via EDI to the customer.

No page found for this article describes e-mailing the order confirmation itself; the E-Mail Reports page lists a parameter row for the confirmation of a customer order, and nothing more. Do not assume that the invoice route applies to it. For invoices sent in a batch, the page on batch printing states that e-mails are only sent to customers that are set up to receive invoices by e-mail and that do not have the INVOICE message type with the Method Default option enabled.

The general E-Mail Reports page describes a lookup in five steps in its section on set-up in IFS/Customer Orders. Its last two steps read: if the earlier steps find no contact, it uses the primary contact for the customer in general, defined on the Customer/Contact page, and if that is empty too, the value from the Reference field on the Customer/Sales/General page.

The document pages add shorter rules of their own, and these are the ones to test for each document. The invoice page says the Comm Method should be set to E-mail and the receiver’s e-mail address must be specified, and that the same customer name should be given as the Customer Contact in the Customer/Address/Order Address Info tab. The quotation page says that if a valid customer contact exists in the Customer/Address/Sales Address Information tab, that value is automatically set as the reference value and used as the e-mail address of the receiver.

The design consequence is that the contact data has an owner. Decide who maintains customer contacts and their communication methods, because the lookup reads contact data from more than one place, and you should record what happens when all of them are empty. On the customer record, the page also names a switch: on the Customer/Sales/Email page, the required toggle for the e-mail options should be enabled.

Each document has its own list of prerequisites, and the table takes every row from the page of that document. The invoice and the quotation both depend on the mail components and the report event; the order confirmation depends on EDI data.

An invoice is locked after it is sent, a quotation changes status by revision, and an order confirmation has no e-mail page to describe. The invoice page states that you cannot modify the customer invoice after the invoice has been e-mailed. It also states that postings are created, and that if the option to set the invoice date to the current date when printing outgoing invoices had been enabled, the invoice date is set to the date on which the invoice is mailed. Finance should know both before anyone presses send. Invoices that are late or missing in the first place are covered in delivered but not invoiced in IFS Cloud.

A quotation behaves differently. The file is marked as Preliminary if the quotation header or any of its lines has not been released. If the quotation header is in Released status when the e-mail is sent, the Printed option is enabled, and a later change creates a new revision, sets the status to Revised and disables the Printed option.

The order confirmation is the one to treat with care. It goes through EDI, per its page, and the order must come from an incoming customer order. Orders that are never confirmed are a separate problem, covered in unconfirmed sales orders, and changes after confirmation in sales orders changed after confirmation. The order types and flows around these steps are described in customer order types and order flow.

For IFS/Purchasing and IFS/Customer Orders, the E-Mail Reports page states that the following information is passed in the event parameters PDF_PARAMETER_1 through PDF_PARAMETER_10. The page has parameter rows for the confirmation of a customer order, the invoice, the pro forma invoice, the order quotation, the customer order delivery note and the shipment delivery note. The invoice row passes, among other values, the e-mail address for the customer contact, the customer, our reference from the invoice and the invoice number.

That list is on the general page and not on the three document pages, so check the row of the document you configure. The conditions, the parameters and the failure behaviour of the same event are described for purchase orders in e-mailing purchase orders in IFS Cloud, and custom events in custom events in IFS Cloud. This article does not repeat them.

Sales administration owns the customer contact data and the customer-side switches, and finance owns the rule for who may send and when. The invoice cannot be modified after it has been e-mailed, so finance decides whether an invoice is sent from a batch or one by one, and who may do it. Mail automation beyond these standard routes is described in automating supply chain processes in IFS Cloud.

Test the set-up with test orders that cover the cases below, and write down the expected result before each one.

The set-up is ready for go-live when each of the checks below has a record behind it.

1. Each document in use has its prerequisites checked against its own page.
2. The customer contact data is maintained, with a named owner.
3. The customer-side e-mail toggle is enabled where documents go out by e-mail.
4. The PDF_REPORT_CREATED event is defined and enabled for the documents that use it.
5. Finance knows that an e-mailed invoice is locked, that postings are created and that the invoice date can change.
6. The order confirmation route is decided: EDI, with its message set-up.
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.