Dynamics NAV 2013R2 Development #1

Introduction

This article is aimed at anyone that might be starting out with Microsoft Dynamics NAV 2013R2, the assumption is that you are familiar with Dynamics NAV and the development environment.

Having worked with Dynamics NAV since 1996 the software has changed beyond recognition, over these years the thinking around the way that standard tables and code has been extended does not seem to have changed, as a contractor I often see the same approach to development is still been used.

There were limitations in older versions with only a single sub-form on a card form, this made adding a number of fields to tables and forms the standard way to work, the development path meant adding new functions to tables and field validation trigger code, inserting large blocks of code in the posting codeunits with many reports being written for processing data only and consideration to processing time and limiting the use of keys was required.

When it came to upgrading older versions with many changes to standard objects it was often quoted as a time and cost restriction by the Customer to upgrading the database, there are still some companies that use versions as old as Navision 2.6 on Windows XP terminals, not upgrading due to upgrade cost restrictions makes it harder and costly for the resellers to support historic versions on different platforms.

Since working with 2009 to 2013R2 there has been the scope to change the way development is done which has become more apparent, simply the cost of tables, reports, and codeunits is small compared to the consultancy and development costs of upgrading heavily modified standard objects, when developing we should consider the impact of changes on upgrades, look at working in a new way to reduce the longer term cost of development and make upgrades for the end client a less painful experience.

Adding a field to an existing table is sometimes a better solution, but quite often the new fields do not have to exist in the same table or be added to existing form sections, creating a new table and sub-page can be a cleaner solution.

Scenario

Cronus UK Ltd. manufacture high quality furniture, they do not sell direct to the public but use a number of distributors in Europe, a subsidiary company setup as a Vendor manufacture the furniture in Chiang Mai Thailand and the subsidiary company handle the shipping of the products by sea to Rotterdam and other ports using several third party companies to warehouse the furniture who then deal with the delivery, some of the units could be held as stock, Special Orders can be used for units that can be received, assembled and re-branded in the Warehouse, other units can be sent direct from the factory as Drop Shipments which are collected at the port by the distributor all as standard.

Developing a solution must consider that Cronus UK will be expanding and setting up subsidiary companies in both the USA and the Balkans these will use a local reseller partner and localized databases, therefore the ability to merge any changes into a different localized Dynamics NAV databases in a cost effective and timely manner is a key requirement to the project.

Analysis

Since the release of 2009 with the RTC pages we can work differently, look at one object the Customer table and possibly some fields that are often added, “ANA Code”, “Mobile No.”, “Accounts Contact No.”, “Delivery Instruction 1”, “Delivery Instruction 2”, “Created by User”, “Created Date Time”, there are many more fields that could be added as the solution develops.

Solution 1

The Developer has the detailed design document from the Consultant looks at the field list and adds the fields to the ‘Customer Table’, ‘Customer Card’ and the “Accounts Contact No.” field to the ‘Customer List’, simple changes not a hard task, possibly less than an hours work.

Cons:

• Harder to roll out to new localized databases
• Harder to roll out modifications to localized databases
• More work to upgrade, higher cost (time) to the reseller and end client

Pros:

• Less development time
• No additional object costs
• Easy to add fields to Card Section

Solution 2

The Developer has the detailed design document from the Consultant looks at the field list and considers that these fields will have to be migrated into new localized databases, any future upgrades will require the addition of these fields to the Customer table in the new version, therefore the Developer creates a new table, adds the fields to the new ‘Extended Customer’ Table.

The Developer also creates a sup-page for the new table to add to the ‘Customer Card’, creates a codeunit with five functions passing the Customer record for the Extended Table to insert, modify, rename, delete and get, adding basic code to the functions to maintain the link between the tables, rather than adding the fields to the Customer table the developer adds a CAL Global variable for the codeunit and four function trigger calls for insert, modify, rename, delete, this is not a hard task possibly less than two hours work.

Cons:

• More short term development time
• Possible additional object costs
• Harder to add fields to existing page sections

Pros:

• Easier to roll out to new localized databases
• Easier to roll out modifications to localized databases
• Less work to upgrade, lower cost (time) to the reseller and end client

Conclusion

Before ripping into adding new fields and code considering the bigger picture can change the solution, there is often time pressures to get the objects out to the end Client but the short term gains can have longer term costs.

Check part two to see how Solution Two is developed