Recent Posts

Archive

Tags

Dynamics NAV to Dynamics 365 (CRM) Integration Types

This blog describes some things that a NAV developer may discover when integrating with Dynamics 365 (CRM) and Dynamics NAV. I have assumed in this blog that you are a developer and had some experience in this type of integration.

So, you got Dynamics NAV to integrate with Dynamics 365 (CRM). Now you need to extend it further. I’ve found that it is always the simplest things that stump a Dynamics NAV developer when integrating with Dynamics 365 (CRM).

One of these things can be a simple business case where Dynamics NAV needs to update Dynamics 365 (CRM) accounts with payment terms as this is a finance function. On the surface of it, it sounds easily enough and the perception is how hard could it be, you just copying one field to another.

Below are some things you as a Dynamics NAV developer should be aware of and this will hopefully save you a ton of time: (These points are based on the above business case)

  • In Dynamics NAV the payments terms are a CODE field, meanwhile back in CRM this is a dropdown list of values. Because of these two different types just updating the field mappings won’t do the trick in synchronizing changes.

  • There is something very important on how NAV handles CRM dropdown lists. From a NAV developers point of view they are thought of as Options and Option strings where the underlying data is an integer. When you run the New-NAVCrmTable command let NAV does kind of the same, however there is a hidden properties that is specific for CRM called ExternalType=Picklist and OptionOrdinalValues=[-1;1;2]. Apart from wishing these properties were on the object designer these properties handle the values of the CRM dropdown.

  • There is one more thing to get this scenario working. This is the fact that standard NAV only integrates to CRM on the same type. What this means is that you’ll have to dig deep into the code to find and perform a manual type conversion, so that CRM can receive the data. You can find this call in codeunit ‘5336 Integration Record Synch.’ on function TransferFieldData. Below is a sample: (Apologies for the hard code)

LOCAL TransferFieldData(VAR SourceFieldRef : FieldRef;VAR DestinationFieldRef : FieldRef;ValidateDestinationField : Boolean)

//>> Update accounts on option fields

RecordRef := SourceFieldRef.RECORD;

IF RecordRef.NUMBER = DATABASE::Customer THEN BEGIN

IF SourceFieldRef.NUMBER = 27 THEN BEGIN // Payment Terms Code

IF FORMAT(SourceFieldRef.VALUE) = '30DAYS' THEN DestinationFieldRef.VALUE := 1;

IF FORMAT(SourceFieldRef.VALUE) = '60DAYS' THEN DestinationFieldRef.VALUE := 2;

IF FORMAT(SourceFieldRef.VALUE) = '7DAYS' THEN DestinationFieldRef.VALUE := 3;

IF FORMAT(SourceFieldRef.VALUE) = 'COD' THEN DestinationFieldRef.VALUE := 4;

END;

END;

//<<

IF (SourceFieldRef.TYPE = DestinationFieldRef.TYPE) AND (DestinationFieldRef.LENGTH >= SourceFieldRef.LENGTH) THEN BEGIN

IF ValidateDestinationField THEN

DestinationFieldRef.VALIDATE(SourceFieldRef.VALUE)

ELSE

DestinationFieldRef.VALUE := SourceFieldRef.VALUE;

EXIT;

END;

In Summary

Integrating with Dynamics 365 and Dynamics NAV does come with some challenges. Being able to make the right change improves not only your moral, but the customers experience in your ability to become their trusted ERP partner.

I hope this blog helps.