Business processes related to invoicing often require invoices to be emailed to the customers after posting. Companies try to automate these processes and perform them in batch in D365FO, by posting and emailing large number of invoices at once. Here is the problem: sometimes it happens that a customer’s contact email address doesn’t exist in the system, because the customer doesn’t want to be contacted via email, or due to the poor data quality. Anyway, such an invoice can’t be emailed. As a fallback option, you might decide to automatically print such invoices, without the user’s interaction. In other words, you want to email or print invoice from D365FO, based on the customer’s contact email address availability. You can think of this behavior as a report redirection and let’s see how to achieve it.
I will demonstrate the redirection on the example of the Sales invoice report. See the mind map above: if the contact email of the invoiced customer is known, send the report via email. Otherwise, print the Sales invoice to a selected printer and send it via postal mail.
Invoice purpose and email tokens
Let’s say that you want to maintain the email contacts with the Invoice purpose. This requires that you specify the Invoice contact information purpose in the Address and contact information purpose form. Then you can use that purpose when adding email contact information:
In the email print destination settings you would now use the @Invoice@ email token in the To field, to specify that you want this email address to be used:
When the invoice for the customer with the above contact information is printed, the @Invoice@ email token will be resolved as email@example.com and email will be sent to that address.
Unresolved email tokens
Above example demonstrates a "happy flow" and it isn’t anything fascinating. It is more interesting to see what we can do about a customer without the Invoice purpose email contact. Below is an example of one such customer, it has a primary business contact, but no Invoice purpose contact.
@Invoice@ email token in this case will be unresolved and email message To field will become empty, therefore such email message can’t be sent. This is the error message we get when we try to print the invoice for this customer using standard D365FO emailing:
Redirect the report to printer
As stated in the beginning, we want to automatically print this invoice to the printer instead to email. It can be easily achieved with Docentric AX Free Edition. In Docentric report setup there is a link to one whole form dedicated to per-report and per-company Email sending settings, where you can also configure what should be done if the email tokens were not resolved.
In the example above, I have specified to redirect the report to the printer, in particular to the default printer of the user who initiated printing. The redirection should happen if the email message To field is empty due to unresolved tokens.
See more about default printers in Docentric >>
When printing the invoice for the same customer as in the previous example, we will get this result:
We got the following info message: Report (Show invoice) with ID (SalesInvoice.Report) is successfully sent to the printer: @DEFAULT_PRINTER@ >> HPDocentric (HP Officejet Pro 8610)
Useful warning message
While we are at this setting, let’s explain another great feature that comes with it. Notice the Show warning message field in the above image. To truly understand the benefits we have from it, let’s first see the standard D365FO behaviour in the case of unresolved email tokens:
As you can see on the above image, standard D365FO generates the following messages:
- Warning: Tokens for Email(To) output. Customer email address with purpose Invoice was not found.
- Error: The email address in the To field is not valid.
Let’s take a moment and comment on this. We have printed one invoice for the known customer and got these messages, so we know what to do and how to fix the problem. But what if we were posting hundreds of invoices in batch (because, that’s how we usually do it) and several customers didn’t have the required type of the email address? All the invoices will be posted, but some of them won’t be emailed. You will get several warning/error messages like these above, all of them completely useless, because they don’t tell you which invoices haven’t been emailed!
The Show warning message option in the Docentric report setup will give you much more descriptive messages, here is the result of printing when this option is turned on:
In addition to the information about the redirection we also got this warning message: Customer invoice CIV-000031, Customer US-001: Could not resolve tokens in the To field Email address with the purpose Invoice was not found.
Now, this will enable identifying the customers without the adequate contact information. Even if you didn’t configure the redirection, you will know which invoices haven’t been sent and will have the possibility to take the corresponding action.
See the detailed instructions related to the unresolved email tokens handling >>
4 thoughts on “Email or print an invoice from D365FO, depending on the customer’s email address availability”
I’m currently using this functionality and I’m wondering whether it is (or will be) possible to export / import email redirection configuration?
Import/Export of Docentric report setup includes Email token redirection setup data as well.
Please check the related how-to manual.
Thanks, I have reviewed the article you suggested but actually it is a different scenario I am trying to overcome.
Our organisation has over 100 legal entities which are managed by 3 different regional service centers which means there are different email addresses that we need to redirect 5 different reports to in the event of no To token being found from the customer or vendor.
I’m hoping to find a mechanism where per document I can set up an email redirection for one legal entity and then copy that to multiple legal entities within the same environment.
What would be your recommended approach in this scenario?
For the scenario you’ve described, I would go with this approach: