From the point of view of a developer, NAV 2013 consists of several thousand potentially customizable off-the-shelf program objects (consider these as building blocks) plus the Integrated Development Environment (the C/SIDE development tools), which allow us to modify those objects and create new ones.
The NAV 2013 system is an object-based system made up of the seven different object types available in NAV. NAV does not have all of the features of an object-oriented system. A full-featured object-oriented system would allow for the definition and creation of new object types, while NAV only allows for the creation and modification of instances of the seven pre-defined object types.
Let's start with basic definitions of the NAV 2013 object types. They are as follows:
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.
Report: Reports allow the display of data to the user in hardcopy format, either on screen (preview mode) or via a printer device. Report objects can also update data in processes with or without accompanying data display output.
Codeunit: Codeunits are containers for code, which 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, Excel, XML, and OData.
XMLport: XMLports allow the importing and exporting of data from/to external files. The external data 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, especially since they cannot contain any code or logic. MenuSuites are translated into the Departments menu entries in the Navigation Pane for presentation to the users.
NAV 2013 includes an extensive set of software development tools. The NAV development tools are accessed through the C/SIDE (Client/Server Integrated Development Environment) which runs within the Development Environment client. This environment and its complement of tools are generally just 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 Visual Studio tools are required for the report layout work. Prior to NAV 2009, it was possible to do all NAV development within the embedded IDE.
Note
According to Microsoft, NAV 2013 report layout design requires use of Visual Studio 2010, including the Visual Web Developer feature. Claus Lundstrum, in his blog at http://mibuso.com/blogs/clausl/2012/05/31/free-visual-studio-designer-for-editing-reports-in-dynamics-nav-2013-and-other-options/ explains how to get the free Visual Web Developer 2010 Express to work for NAV 2013 report layout designing.
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 first open the Object Designer window, we will see the following screen:
Tip
Downloading the example code
You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
Whenever 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 even when it is of no use. Refer the following table:
The language in which NAV is coded is C/AL (an acronym for Client Application Language). A sample of some C/AL code within the C/AL Editor is shown in the following screenshot:
C/AL syntax has considerable similarity to Pascal. As with any programming language, readability is 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
For several decades, one of the highest goals of software development has been to focus on design before coding and, wherever possible, to accomplish design goals with a minimum amount of code. More than most application software products, Dynamics NAV facilitates that approach. When working on enhancements of NAV, we can spend a majority of our NAV development time determining what to do and what existing capabilities support the task at hand. Then, much of our NAV development work is done by making entries in tables, defining properties of objects ranging from controls to functions to programs, and assembling references to previously defined objects. This approach allows us to minimize the number of lines of code required because we are reusing objects that already exist. As NAV's tools continue to mature, our development work continues to be more heavily weighted in favor of design. Hopefully, the end result is that we are more productive and cost effective on behalf of our customers.
Following are some key terms as used in NAV:
Fields: These are the individual data items, defined either in a table or in the working storage of an object.
Records: These are groups of fields (data items) that are handled as a unit in most Input/Output operations. The table data consists of rows (records) with columns (fields).
Controls: In MSDN, a control is defined as follows:
a component that provides (or enables) user-interface (UI) capabilities
Properties: These are the attributes of the element (for example, object, data field, or control) that define some aspect of its behavior or use. Example attributes include display caption, relationships, and if the elements are either editable or viewable.
Triggers: The generic definition is a mechanism that initiates (fires) an action when an event occurs and is communicated to the application object. A trigger is either empty or contains code that is executed when the associated event fires the trigger. Each object type, data field, control, and so on, may have its own set of pre-defined triggers. The event trigger name begins with the word On such as OnInsert, OnOpenPage, and OnNextRecord. NAV triggers have similarities to those in SQL, but they are not the same (and may not even serve similar purposes). NAV triggers are locations within the various objects where a developer can place comments or C/AL code. When we look at the C/AL code of an object in its Designer, the following have a physical resemblance to the NAV event-based triggers:
Documentation which 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 which can be defined by the developer. They represent callable routines that can be accessed from other C/AL code either inside or outside the object where the called function resides. Many functions are provided as part of the standard product. As a developer, we may add our own custom functions as needed.
Object numbers and field numbers: All objects of the same object type are assigned a unique number. All fields within an object are assigned a unique number within the object (that is, the same field number may be repeated in many objects referring to similar or different data). The object numbers from 1 to 50,000 and in the 99,000,000 range are reserved for use by NAV as part of the base product. Objects in this number range can be modified or deleted, but not created with a developer's license. Field numbers are often assigned in ranges matching the related object numbers (that is starting with 1 for fields relating to objects numbered 1 to 49,999; starting with 99,000,000 for fields in objects in the 99,000,000 and above number range). 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. If feasible, object numbers from 90,000 to 99,999 should not be used for permanent objects as those numbers are sometimes used in training materials. Microsoft allocates other ranges of object and field numbers to Independent Software Vendor (ISV) developers for their add-on enhancements. Some of these (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 user-controlled date which 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 ending a 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. We can set the Work Date by selecting the Microsoft Dynamics icon dropdown and navigating to the Set Work Date… option or clicking on the date in the Status Bar at the bottom of the RTC window, then entering a date in the Set Work Date screen seen here:
Clicking on Set Work Date... in the dropdown options displays the following Set Work Date screen:
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. Microsoft Partners have access to "full development" licenses to provide support and customization services for their clients. End-user firms can also 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 (i.e. less expensive). If our 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.
For various application functions, NAV uses terminology that is more akin to accounting than to traditional data processing terminology. Some examples are 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 in inventory, and so on.
Ledger: A detailed history of posted transaction entries that have been processed. For example, General Ledger, a Customer Ledger, a Vendor Ledger, an 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 that were posted in one group.
Register: An audit trail showing a history, by Entry No. ranges, of the Journal Batches that have been posted.
Document: A formatted page such as an Invoice, a Purchase Order, or a Payment Check, typically one page for each primary transaction.
NAV 2013 user interface is intended 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 or the Web Client, the Role Tailored Client will be employed. If the user access is via the SharePoint client or another client, the developer will have more responsibility to make sure that the user experience is role tailored.
The first page which a user will come in contact with 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 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 firm.
Someone whose role centers on Order Entry will see a different RTC home page than the user whose role centers around Invoicing, even though both are primarily focused in what we generally think of as Sales and Receivables. The RTC, as implemented in NAV 2013, 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 from time to time.
The following screenshot is the out-of-the-box Role Center for Sales Order Processor:
Note
The key to properly designing and implementing any system, but 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 as those relate to accomplishing the businesses goals. The individual users' tasks must be mapped to individual NAV functions or elements, identifying how that task will be supported by the system. The Microsoft Dynamics Sure Step Methodology tools provide a very robust set of guidelines, document templates, and tools for the system implementation process. It is very important that the up-front work be done and done well. The best programming cannot compensate for a bad definition of what the goals are.
In our exercises, we will assume that the up-front work has been well done and we will concentrate on addressing the requirements defined by our project team.