Tech Tuesday: Differences between GP Journals and NAV/365 Journals
Recently we have seen an increased interest in our NAV/365 Financials connector. I am writing this article for our existing customers who have more experience in the Dynamics GP space than with NAV. Everything in the article is relevant for NAV on premise, and the online version. When using GP as a destination for creating Journals there are some crucial differences that will causes an import to fail. This article is relevant to General, Cash Receipts, and Payment Journals.
Key Fields and Grouping
When building a map for a GP Journal the key field is based on header. Meaning, the key field will be unique to each document, not the distributions. NAV, on the other hand, will import each line as its own document meaning the key fields need to split your document to individual lines.
Grouping in the Dynamics GP Header Node will be grouped by the Key Fields. Grouping in the NAV destination node is always required when working with the NAV web services. When working with journals you can almost always set the destination grouping to the same fields as your key fields.
Batches versus Journals
In GP, a financial journal consists of Batches with journals inside the Batches, and the individual lines exist inside the Journals. NAV does this differently which is a main cause of confusion when trying to create a journal in NAV. NAV eliminates the journals so you are importing the lines directly inside the Batches.
When importing to GP, eConnect will automatically create batches and journals if the batch does not already exist. You can import into an existing batch using Dynamics GP. Creating NAV batches requires either someone manually creating the batch inside NAV, or exposing the Create Batch web service and run a separate map to create the batch. This is existing logic within NAV web services that currently does not have a work around.
Working with GP rolling columns is a common process when integrating with GP. NAV does this function automatically when importing through the web services. For this reason, certain fields should not be mapped unless you are doing an update. Do not map anything to the NAV field named “Key” unless you want to update an existing record. The Key, is a unique identifier that is automatically assigned by the NAV services.
Field Specified List Option
There will be many list options that say a field name then specified. This is a way for the web service to know if you are passing a value for that field. For almost every field, if you leave this option blank it will default to “False” with the exceptions being the Balance and Total Balance Specified fields. You will need to switch both fields to False, or you will get one of the following errors.
- Field TotalBalance is readonly!
- Field Balance is readonly!
As for the remaining specified fields, they should be left blank unless you mapped them, in which case you will want them to be set to “True”.
Another error when importing to Journals is “Field BalAccName is readonly!”. Unlike the other errors, this one has nothing to do with the specified fields. This error will occur when any of the Balance Account fields are mapped while NAV has a default Balance Account set up. Below are some fields that cause this error.
Screen Shot examples of mapping used for both GP and NAV/365
These, and other templates for NAV/365 Financials are available Here.
Integrate & Automate without Any Code.
SmartList Data has Never Been Faster.
The Easiest Way to Report on GP Data.
Leave a Comment