28
The whole Send to Email functionality in GP is complex, not well documented and there is room for a lot of improvement. Due to the complexity and lack of documentation it takes a long time to troubleshoot these issues for what is a basic feature.
If I can setup a printer to send PDFs via SMTP in 5 minutes, why can’t I do this with GP?
There are so many dependencies to get Send to email to work (not all GPs fault) however what is in control of GP is the documentation, functionality, error reporting and notifications.
1) If you use Exchange Web Services to send to Email then you lose the ability to send PDFs.
2) If you use MAPI to send to Email with PDF you are forced to use Office 32bit (MAPI limitation) however almost everyone is forced to use MAPI because of the inability for Exchange to send PDFs.
3) No SMTP support? It is standard practice for Printers to send PDFs by SMTP, why is SMTP not supported in GP - this would remove the dependency on MAPI and 32 bit Office.
4) Notifications are poor - Emails are marked as sent successfully when they leave GP, if there is an issue with your template the email will fail to send but you will get no error message back from GP.
5) Logging is very poor - when sending an email all you get are the start and finish times of the job, there is no feedback after the command is sent from GP - no reporting whether the template was generated successfully, no reporting on which template field failed, no reporting if there was an error back from EWS or Outlook.
Getting Send to Email to work is a pretty miserable experience of trial and error that needs improving.
If I can setup a printer to send PDFs via SMTP in 5 minutes, why can’t I do this with GP?
There are so many dependencies to get Send to email to work (not all GPs fault) however what is in control of GP is the documentation, functionality, error reporting and notifications.
1) If you use Exchange Web Services to send to Email then you lose the ability to send PDFs.
2) If you use MAPI to send to Email with PDF you are forced to use Office 32bit (MAPI limitation) however almost everyone is forced to use MAPI because of the inability for Exchange to send PDFs.
3) No SMTP support? It is standard practice for Printers to send PDFs by SMTP, why is SMTP not supported in GP - this would remove the dependency on MAPI and 32 bit Office.
4) Notifications are poor - Emails are marked as sent successfully when they leave GP, if there is an issue with your template the email will fail to send but you will get no error message back from GP.
5) Logging is very poor - when sending an email all you get are the start and finish times of the job, there is no feedback after the command is sent from GP - no reporting whether the template was generated successfully, no reporting on which template field failed, no reporting if there was an error back from EWS or Outlook.
Getting Send to Email to work is a pretty miserable experience of trial and error that needs improving.
STATUS DETAILS
Declined
Comments
Recently experienced an issue where a word template report prints well in GP and when sending to email the dialogue says successful however, the template doesn't actually send. Found out the root cause to be a corrupt xml source generating in the report writer source file which affects if the report sends but not the printing to the screen. It seems as though the dialogue that says send is successful is based on the report being generated in GP and not on the actual success of the email.
Category: System
Administrator on 9/20/2022 7:58:28 PM
At this time there are no scheduled plans to change this, documentation is updated all the time and adding an email section below
Dynamics GP Email Troubleshooting Guide - Dynamics GP | Microsoft Docs
Terry Heley | Sr. Escalation Engineer | Microsoft Dynamics
701-492-6376 (o) | 701-412-5619 (m) | theley@microsoft.com