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:
Table: Tables define the data structure and also contain the data records.
Page: Pages are the way the data is formatted and displayed appropriately for each of the client types and user roles.
Report: Reports provide display of the data to the user in hardcopy format, either on screen (preview mode) or via 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. They 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. They can output data directly to charts, Excel, XML, and OData.
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 which 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.
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: A data file supplied by Microsoft that allows a specific level of access to specific object number ranges. NAV licenses are very clever constructs which 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.
Note
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."
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) UI capabilities".
Properties: These are the attributes of the element such as an object, field, record, or control that define some aspect of its behavior or use. Example of 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 contains only 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: It 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: It can be defined by the developer. They are callable routines which 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).
Note
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.
(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
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, which 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 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 drop-down menu below the Microsoft Dynamics icon and selecting the Set Work Date... option.
Clicking on Set Work Date... in the drop-down options displays the Set Work Date screen. Or click on the date in the Status Bar at the bottom of the Role Tailored Client (RTC) window. In either case, we can enter a new Work Date:
For various application functions, NAV uses terminology more similar to accounting than to traditional data processing. Some examples are listed as follows:
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 to 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.
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 the history, by Entry No. 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).
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:
Tip
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.