Most users will use Scribe adapters to connect data between CRM and NAV. These adapters are very useful, especially with CRM’s restrictions on how data may be written into its database.
Coming back from CRM to NAV, the adapters also do a great job, except for when NAS is needed to support the process.
FULL DISCLOSURE – I DO NOT LIKE NAS AND NEVER HAVE. If you are happy with NAS, you can stop right here.
In general I do not like how NAS requires multiple instances for companies, is prone to crash and is prone to do so without the user knowing something went wrong. Hopefully with the use of web services, the Scribe adapter will be more effective.
Nonetheless for CRM/NAV integration there are other options which should be considered:
- use a SQL Server integration table to pass data between CRM and NAV, especially when you have CRM programmer resources at hand. This completely eliminates the need for Scribe to pass the data between applications and eliminates the need for several Scribe scripts. You will need an NAV and a CRM programmer to update and process the data from the integration table into each respective application.
- use an industry standard application like WINAUTOMATION to process batch jobs instead of the NAV scheduler (which is NAS-dependent). I have only used this in the Classic client, but it works exceptionally well for automating nightly processes, especially when you have to start and stop processes in multiple companies.
With web services, I would look to use something like Winautomation to process jobs, then execute scripts which are not NAS dependent to fire off functions inside NAV to process data.