A developer's overview of NAV 2017

From the point of view of a developer, NAV 2017 consists of about almost five thousand potentially customizable off-the-shelf program objects plus the integrated development environment (IDE)-the Client/Server Integrated Development Environment (C/SIDE) development tools that allow us to modify existing objects and create new ones.

NAV object types

Let's start with basic definitions of the NAV 2017 object types:

• Table: Tables serve both to define the data structure and to contain the data records.
• Page: Pages are the way data is formatted and displayed appropriately for each of the client types and user roles.
• Report: Reports provide for the display of data to the user in hardcopy format, either onscreen (preview mode) or through a printing device. Report objects can also update data in processes with or without data display.
• Codeunit: Codeunits are containers for code utilized by other objects. Codeunits are always structured in code segments called functions.
• Query: Queries support extracting data from one or more tables, making calculations, and outputting in the form of a new data structure. Queries can output data directly to charts, to Excel, to XML, and to OData. They can be used as an indirect source for pages and reports.
• XMLport: XMLports allow the importing and exporting of data to/from external files. The external file structure can be in XML or other file formats.
• MenuSuite: MenuSuites contain menu entries that refer to other types of objects. MenuSuites are different from other objects. Menus cannot contain any code or logic. MenuSuite entries display in the Departments page in the navigation pane in the Windows client only. In the web and tablet clients, these are used to support search functions.

The C/SIDE Integrated Development Environment

NAV 2017 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 (Client Application Language) 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, JavaScript, COM controls, and OCX controls, among others).

The C/SIDE IDE 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:

Object Designer tool icons

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. On occasion, an icon will appear when it is of no use:

C/AL programming language

The language in which NAV is coded is C/AL. A small sample of C/AL code within the C/AL Editor is shown here:

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 development focuses on design before coding and 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 in Wikipedia, a design pattern is a general reusable solution to a commonly occurring problem.  Links to the NAV design patterns project information follow:

• http://blogs.msdn.com/b/nav/archive/2013/08/29/what-is-the-nav-design-patterns-project.aspx
• https://community.dynamics.com/nav/w/designpatterns/default.aspx
• https://www.packtpub.com/big-data-and-business-intelligence/learning-dynamics-nav-patterns

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 NAV enhancements, 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), spending less time writing and debugging code. A good reference for NAV design and development using patterns can be found here: https://www.packtpub.com/application-development/microsoft-dynamics-nav-2013-application-design

The NAV 2017 Reusing Code section states the following:

"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 both by 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.

NAV object and system elements

Here are some important terms used in NAV:

• License: A data file supplied by Microsoft that allows a specific level of access to specific object number ranges. NAV licenses are very clever constructs that allow distribution of a complete system: all objects, modules, and features (including development), while constraining exactly what is accessible and how it can be accessed. Each license feature has its price, usually configured in groups of features. Microsoft Partners have access to full development licenses to provide support and customization services for their clients. End-user firms can purchase licenses allowing them developer access to NAV. A Training License can also be generated, which contains any desired set of features and expires after a specified period of time.

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.

• Field: An individual data item, defined either in a table or in the working storage (temporary storage) of an object.
• Record: A group of fields (data items) handled as a unit in many operations. Table data consists of rows (records) with columns (fields).
• Control: In MSDN, a control is defined as a component that provides (or enables) user interface (UI) capabilities.
• Properties: These are the attributes of the element such as an object, field, record, or control that defines some aspect of its behavior or use. Example property attributes include display captions, relationships, size, position, and whether editable or viewable.
• Trigger: Mechanisms that initiate (fire) an action when an event occurs and is communicated to the application object. A trigger in an object is either empty, contains code that is executed when the associated event fires the trigger, or only contains comments (in a few cases, this affects the behavior of the trigger). Each object type, data field, control, and so on may have its own set of predefined triggers. The event trigger name begins with the word On, such as OnInsert, OnOpenPage, or OnNextRecord. NAV triggers have similarities to those in SQL, but they are not the same (similarly named triggers may not even serve similar purposes). NAV triggers are locations within objects where a developer can place comments or C/AL code. When we view the C/AL code of an object in its designer, we can see non-trigger code groups that resemble NAV event-based triggers:
  • Documentation: This can contain comments only, no executable code. Every object type except MenuSuite has a single Documentation section at the beginning of the C/AL code.
  • Functions: These can be defined by the developer. They are callable routines that can be accessed by other C/AL code from either inside or outside the object where the called function resides. Many functions are provided as part of the standard product. As developers, we may add our own custom functions as needed.
• Object numbers and field numbers: All objects of the same object type are assigned a number unique within the object type. All fields within an object are assigned a number unique within the object (that is, the same field number may be repeated within many objects whether referring to similar or different data). In this book, we will generally use comma notation for these numbers (fifty thousand is 50,000). In C/AL, no punctuation is used. 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. 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:

• Events: Functions can subscribe to events that are raised in the system. NAV 2017 has both platform and manual events. Functions can also be used to raise events.
• Work Date: This is a date controlled by the user operator. It is used as the default date for many transaction entries. The system date is the date recognized by Windows. The work date that can be adjusted at any time by the user, is specific to the workstation, and can be set to any point in the future or the past. This is very convenient for procedures such as the ending sales order entry for one calendar day at the end of the first shift, and then entering sales orders by the second shift dated to the next calendar day. There are settings to allow limiting the range of work dates allowed. The work date can be set by clicking on arrowhead dropdown below the Microsoft Dynamics icon and selecting the Set Work Date... option:

• Clicking on Set Work Date... in the dropdown options displays the Set Work Date screen. Or click on the date in the status bar at the bottom of the RTC window. In either case, we can enter a new Work Date:

NAV functional terminology

For various application functions, NAV uses terminology more similar to accounting than to traditional data processing terminology. Here are some examples:

• Journal: A table of unposted transaction entries, each of which represents an event, an entity, or an action to be processed. There are General Journals for general accounting entries, Item Journals for changes in inventory, and so on.
• Ledger: A detailed history of posted transaction entries that have been processed. For example, General Ledger, Customer Ledger, Vendor Ledger, Item Ledger, and so on. Some ledgers have subordinate detail ledgers, typically providing a greater level of quantity and/or value detail. With minor exceptions, ledger entries cannot be edited. This maintains auditable data integrity.
• Posting: The process by which entries in a journal are validated, and then entered into one or more ledgers.
• Batch: A group of one or more journal entries posted at the same time.
• Register: An audit trail showing a history, by Entry Number ranges, of posted Journal Batches.
• Document: A formatted page such as an Invoice, a Purchase Order, or a Payment Check, typically one page for each primary transaction (a page may require display scrolling to be fully viewed).

User Interface

NAV 2017 user interface (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 through one of the clients, the Role Tailored Client (RTC) will be employed. If the user access is via a custom-built client, the developer will have more responsibility to make sure the user experience is role tailored.

The first page that a user will see is the 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 probably 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 & Receivables. The NAV 2017 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 screenshot 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 up-front work is done and done well. The best programming cannot compensate for a bad definition of goals.

In our exercises, we will assume the up-front work has been well done and we will concentrate on addressing the requirements defined by our project team.