The last two days I have been working on implementing Microsoft Dynamics NAV CRM (Relationship Management), in fact it was an oldschool Navision 3.70 implementation (yes, in 2008 companies still do implement Navision 3.70, amazing).
I was implementing the interaction management functionality. In fact functionality that I always evaluated as nice and interesting. Real cool stuff for demo purposes, even in ancient versions.
However, some bits aren't that well designed in my opinion and these things didn't even changed in later versions as far as I can see.
Let's get into the dirty details here. It all relates to working with the interaction templates and more specific with interaction templates to which attachements are stored.
The last two days I have been digging (I needed a bobcat …) in the code behind these kind of functionalities. The least I can say is that for the code you have two type of attachements: those with merge fields and those without. The golf event template as in the above picture is containing an attachement with merge fields:
I created another template containing an attachement but this time no merge fields:
Let's create an interaction now with the greeting card template and let's make sure that we email this interaction to our contact straight from Microsoft Dynamics NAV.
Result of this interaction is:
A draft email to the emailadress of your contact, containing an attachement: the one you worked on during the interaction.
The same exercise with an interaction based on an interaction template containing an attachement that does includes merge fields (like the golf template) results in this:
Conclusions:
Interaction with communication type 'email' based on a interaction template with attachement NOT containing mergefields:
- An email is produced but not send: ends up in drafts
- The email contains the attachement as an attachement to the email itself
Interaction with communication type 'email' based on a interaction template with attachement containing mergefields:
- An email is produced and send immediately to the contact email adress
- The email contains NO attachement, instead the attachement is set in the body
Why this significant difference?
Is there a good valid functional reason?
There is absolutely no good functional reason for this difference. In fact, it causes a lot of confusion and stress for customers. Let's be honest what is the added value of the interactions? It is the uniformization of document interaction with customer combined with the possibility of merging data from your source system into these documents. Does this work? Yes, but putting this content in the body instead of providing it as an attachement is …..:-(
Did we find a technical reason for this?
Yes , there is a clear distinction between code for handling both cases. A lot of code involved, let's concentrate on the basics here.
Most of the code we find in Codeunit 5054
Function ExecuteMerge
In this function we find code that clearly states:
// Handle Word documents without mergefields
In the following code basics are:
Mail.NewMessage(
AttachmentManagement.InteractionEMail(InteractLogEntry),'',
TempDeliverySorter.Subject,'',MainFileName,FALSE);
This illustrates that in case of NO mergefields the email is created and send by using the standard MAIL codeunit in Microsoft Dynamics NAV.
What then for the documents WITH mergefields?
For these documents we find the following:
We can see clearly: No use of standard Mail codeunit but a clear example of the use of Wordautomation. Interesting to know, the standard Mail codeunit uses "Outlook Automation" while we here use "Word Automation".
By previous code the "send Word Doc as Attachement" is set to FALSE.
Result ? The Email will be created with no attachement, but with the content in the body.
How uncool is that?
Solutions?
You all are very smart and you will have seen immediately that by putting send Word Doc as Attachement" to TRUE, the problem will be solved.
Guess what? You were right!
Case closed?
Unfortunately not, because the email will be directly send . This in both cases ( either with or without attachement - if the original contains mergefields). Why is that? This is because of the possibilities of Wordautomation.
So, situation is now: we have succeeded in making an attachement to the email containing our attachement from the interaction template. BUT this will be send immediately with this time NO text in the body, only an attachement. As the email is send automatically and not stored as a draft …. problemas.
So, up to the next challenge: stop the sending part! Can we do this?
NO. The MailMerge.Execute function in Word will do the merge and send the mail immediately.
Why is that ? Well this is by design. If you have a look in Word, in the development environment and open the object explorer, you will see that there's no way to intervene to stop sending the mail immediately. If Dynamics-NAV would have used Outlook Automation to send the emai, then we would not have this problem. By using Word Automation from Dynamics NAV it is not a possibility.
Possible Solutions ?
Suggestions are welcome. We could send the emails to an internal dummy emailadress and trap it there. Or we could write a macro in Word that handles the sending of MailMerges in another way. But this will require some extra programming to handle the dummy mailbox.
This cost me like a year of my life … to gain this back I see myself obliged in continuing with stopping smoking J
In the past year and months, Plataan has been delivering MSDN evenings for Microsoft. In fact my colleague Steven Renders did deliver 7 evening sessions with success. 
Recent Comments