From the point of view of a developer, NAV 2015 consists of about 4,000 potentially customizable off-the-shelf program objects plus the Integrated Development Environment (the C/SIDE development tools), which allow us to modify existing objects and create new ones.
The NAV 2015 system is an object-based system made up of the seven different object types available in NAV. Strictly speaking, NAV is not a full-featured object-oriented system. A full-featured object-oriented system would allow the definition and creation of new object types, while NAV only allows the creation and modification of instances of the seven predefined object types.
Let's start with basic definitions of the NAV 2015 object types:
NAV 2015 includes an extensive set of software development tools. The NAV development tools are accessed through C/SIDE which runs within the Development Environment client. This environment and its complement of tools are usually collectively referred to as C/SIDE. C/SIDE includes the C/AL compiler. All NAV programming uses C/AL. No NAV development can be done without using C/SIDE, but other tools are used to complement C/AL code (such as Visual Studio, .NET, COM controls, and OCX controls among others).
The C/SIDE is referred to as the Object Designer within NAV. It is accessed through a separate shortcut which is installed as part of a typical full system installation. When we open the Object Designer, we see the following screen:
When we open an object in the applicable Designer (Table Designer, Page Designer, and so on) for that object, we will see a set of tool icons at the top of the screen. The following table lists those icons and the object types to which they apply. Occasionally, an icon will appear when it is of no use.
The language in which NAV is coded is C/AL. A small sample of C/AL code within the C/AL Editor is shown next:
C/AL syntax is similar to Pascal syntax. Code readability is always enhanced by careful programmer attention to structure, logical variable naming, process flow consistent with that of the code in the base product, and good documentation both inside and outside of the code.
Good software developer focuses on design before coding and on accomplishing design goals with a minimum of code. Dynamics NAV facilitates that approach. In 2012, a team made up of Microsoft and NAV community members began the NAV Design Patterns project. As defined on Wikipedia, "a design pattern is a general reusable solution to a commonly occurring problem". Links to the NAV Design Patterns project information are as follows:
A primary goal of this project is to document patterns that exist within NAV. In addition, new best practice patterns have been suggested as ways to solve common issues we encounter during our customization efforts. Now, when working on enhancements of NAV, we will be aided by reference to the documentation of patterns within NAV. This allows us to spend more of our time designing a good solution using existing, proven functions (the documented patterns), and spending less time writing and debugging code. A good reference for NAV design and development using patterns can be found at https://www.packtpub.com/application-development/microsoft-dynamics-nav-2013-application-design.
To quote from the NAV 2015 Help:
"Reusing code makes developing applications both faster and easier. More importantly, if you organize your C/AL code as suggested, your applications will be less prone to errors. By centralizing the code, you will not unintentionally create inconsistencies by performing the same calculation in many places, for example, in several triggers that have the same table field as their source expression. If you have to change the code, you could either forget about some of these triggers or make a mistake when you modify one of them."
Much of our NAV development work is done by assembling references to previously defined objects and functions, adding new data structure where necessary. As the tools for NAV design and development provided by both Microsoft and the NAV community continue to mature, our development work becomes more oriented to design and less to coding. The end result is that we are more productive and cost effective on behalf of our customers. Everyone wins.
Following are some important terms used in NAV:
License limits
The NAV license limits access to the C/AL code within tables, pages, and codeunits differently than the C/AL code buried within reports or XMLports. The latter can be accessed with a lower level license (that is, less expensive). If a customer has license rights to the Report Designer, which many do, they can access C/AL code within Report and XMLport objects. But access to C/AL code in a table, page, or codeunit requires a more expensive license with Developer privileges. As a result, C/AL code within tables, pages, and codeunits is more secure than that within report and XMLport objects.
All licenses are now version-specific. From the Microsoft Dynamics NAV 2015 Licensing Guide: "since the release of Microsoft Dynamics NAV 2013 R2 CU10, license keys are version-specific. A Microsoft Dynamics NAV 2015 license key is required to activate Microsoft Dynamics NAV 2015 software and a Microsoft Dynamics NAV 2015 license key will not activate any other versions of the software."
The object numbers from 1 (one) to 50,000 and in the 99,000,000 (99 million) range are reserved for use by NAV as part of the base product. Objects in these number ranges can be modified or deleted with a developer's license, but cannot be created. Field numbers in standard objects often start with 1 (one). Historically, object and field numbers from 50,000 to 99,999 are generally available to the rest of us for assignment as part of customizations developed in the field using a normal development license.
(At the time of this writing, the Developer Help says that object numbers below 50,000 can be used, at least for reports, but the authors' testing doesn't agree.) Field numbers from 90,000 to 99,999 should not be used for new fields added to standard tables as those numbers are sometimes used in training materials. Microsoft allocates ranges of object and field numbers to Independent Software Vendor (ISV) developers for their add-on enhancements. Some such objects (the 14,000,000 range in North America, other ranges for other geographic regions) can be accessed, modified, or deleted, but not created using a normal development license. Others (such as in the 37,000,000 range) can be executed, but not viewed or modified with a typical development license.
The following table summarizes object numbering practice:
Object Number range |
Usage |
---|---|
1 – 9,999 |
Base-application objects |
10,000 – 49,999 |
Country-specific objects |
50,000 – 99,999 |
Customer-specific objects |
100,000 – 98,999,999 |
Partner-created objects |
Above 98,999,999 |
Microsoft territory |
For various application functions, NAV uses terminology more similar to accounting than to traditional data processing. Some examples are listed as follows:
NAV 2015 UI is designed to be role oriented (also called role tailored). The term role oriented means tailoring the options available to fit the user's specific job tasks and responsibilities. If user access is via the Windows client, Web client, or Tablet client, the Role Tailored Client (RTC) will be employed. If the user access is via SharePoint or another client, the developer will have more responsibility to make sure the user experience is role tailored.
The first page that a user will meet is a Role Center Page. The Role Center Page provides the user with a view of work tasks to be done; it acts as the user's home page. The home Role Center Page should be tailored to the job duties of each user, so there will be a variety of Role Center Page formats for any installation.
Someone whose role is focused on Order Entry will likely see a different RTC home page than the user whose role focuses on Invoicing, even though both user roles are in what we generally think of as Sales and Receivables. The NAV 2015 RTC allows a great deal of flexibility for implementers, system administrators, managers, and individual users to configure and reconfigure screen layouts and the set of functions that are visible.
The following image is the out-of-the-box Role Center for a Sales Order Processor:
The key to properly designing and implementing any system, especially a role tailored system, is the quality of the User Profile analysis done as the first step in requirements analysis. User Profiles identify the day-to-day needs of each user's responsibilities relative to accomplishing the business' goals. Each user's tasks must be mapped to individual NAV functions or elements, identifying how those tasks will be supported by the system. A successful implementation requires the use of a proven methodology. It is very important that the upfront work be done and done well. Even the best programming cannot compensate for a bad definition of goals.
In our exercises, we will assume the upfront work has been well done and we will concentrate on addressing the requirements defined by our project team.