01 Mar What functionalities have suffered more reengineering between Dynamics NAV 2009 and 2018?
Many are the articles that have been published in reference to the new functionalities presented by Dynamics NAV version after version. What has not been written so much is the great reengineering that certain functionalities of NAV have undergone in this evolution.
Although it is noteworthy that most of the changes and reengineering occurred in the 2013 version, we must also highlight some changes in the migrations to the latest versions: Dynamics NAV 2018 and Dynamics 365 Business Central.
In the following article we will discuss in detail the changes in reengineering between NAV 2009 and NAV 2018 and Business Central. We started by remembering which were the most significant between the 2009 and 2013 versions.
Reengineering of objects
The windows went from being objects of Form type to being objects of type Page. This implied that it was no longer as easy as placing a field in the desired area of the window since the graphic environment disappeared.
Another type of object that has also disappeared is Dataports. They were replaced by XMLPorts.
Reengineering in reports
Another big change that occurred is the way in which the design of reports is done. Before they were designed directly from Navision. As of the 2013 version, the table structure is made from Navision, but the printing format is done externally by designing a Layout or from a Word template.
Reengineering in dimensions
Another important change in functional reengineering was in reference to the dimensions. In appearance, the user did not see any change in the functionality. However, technically it changed the way of assigning dimensions to movements. This change streamlined the application’s performance, since each combination of dimensions only exists once and is assigned to all the movements that use it. In versions prior to Dynamics NAV 2013, it was created every time it was used and this had repercussions in the repetition of a lot of information.
RCT client reengineering
Other changes that Dynamics NAV has suffered in the latest versions that use the RCT client, for example in version 2018, is that it has incorporated a functionality that allows configuring the body of the emails for each type of document using reports with Word design . This allows you to configure the body of orders, invoices and subscriptions, among others, in a similar way to how the reports used in the printing of documents are configured.
Most common errors
After having carried out several migrations of Dynamics NAV to new versions of the tool (Dynamics NAV 2018 and Business Central), we also thought it appropriate to explain what are the most common errors.
General reengineering errors
One of the main errors that occur in a migration corresponds to standard fields that have changed their structure. Various reasons can explain it. Either because its length has been extended or because they have changed format.
This change requires a detailed examination of the customer’s own developments, which want to be migrated to new versions, where standard fields of this type are used. Only then can the necessary changes be correctly applied.
A clear example of this reengineering error is the field “Id. user “, which has been extended from 20 to 50 characters. This implies that the extension from 20 to 50 must be taken into account in the personal fields related to “Id. user”. Otherwise, it may be the case that it causes the typical “Overpass in the Code to Code conversion” error.
Errors in the web client
Microsoft has announced that the Windows client will be discontinued in 2020. For this reason, from Triangle we recommend that customers who are considering migrating right now, to work directly with the web client. In this way, the learning cost of the users will be saved, who will work from the first moment with the web client.
The web client of the new versions is not yet 100% debugged. This causes us to find features that are offered in the Windows client but that are not available in the web client.
These errors can be exemplified in the developments that currently use DotNet libraries in the Windows client, which are not compatible in the web client.
Other errors that are detected when migrating to the web client are new properties that have to be reported to work on the web while it is not necessary to report them to work in the Windows client. These include the characteristics of the property “ApplicationArea”, important for the proper functioning of the menu on the web. In addition, this property is not available in objects such as codeunits and xmlports and, therefore, you can not directly execute these types of objects from the web client menu while from the Windows client if possible.