Programming Microsoft Dynamics NAV 2013

4 (1 reviews total)
By David A. Studebaker , Christopher D. Studebaker
    What do you get with a Packt Subscription?

  • Instant access to this title and 7,500+ eBooks & Videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. An Introduction to NAV 2013

About this book

Microsoft Dynamics NAV 2013 is a complete and robust ERP system that is accompanied by a comprehensive set of development tools. You will learn how to master these tools and tailor Microsoft Dynamics NAV 2013 to meet your customer's specific business needs.

Programming Microsoft Dynamics® NAV 2013 will lead you from start to finish, teaching you how to use this incredible ERP software whilst simultaneously making you a more productive developer. You'll learn how to implement your solutions, as well as evaluating, managing and appraising Dynamics NAV 2013 productions and projects.

You will be empowered with the skills and knowledge that you need to get the job done and exceed your client’s expectations. Step by step, you will learn how to use NAV, master the C/AL programming language, as well as the construction and uses of each object type. Ultimately, you will be able to bring your NAV 2013 solution together with fantastic efficiency.

Hands-on development examples and additional material teach you by example and uncover the insider knowledge that only years of experience can provide, truly unleashing your productivity and potential.

Publication date:
February 2013


Chapter 1. An Introduction to NAV 2013


Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do.

 --Steve Jobs

Good design, like good painting, cooking, architecture or whatever you like, is a manifestation of the capacity of the human spirit to transcend its limitations.

 --George Nelson

Microsoft Dynamics NAV has achieved one of the largest installed user bases of any full-featured ERP system in the market. Several years ago, the world-wide installed user base exceeded one million. There is an ever growing community of supporting organizations, consultants, implementers, and developers. Not only do the capabilities of the off-the-shelf product increase with every release, but the variety and depth of the add-on products and services continues to grow and prosper.

The release of Microsoft Dynamics NAV 2013 is the next step down that successful road. NAV 2013 not only has enhanced business functionality, it completes the move from the technology of the 90s and early 2000s, and begins the move to supporting ERP computing in the cloud.

In this chapter, we will take a look at NAV 2013, including the following:

  • A general overview of NAV 2013

  • A technical overview of NAV 2013

  • A hands-on introduction to C/SIDE development in NAV 2013

Our goal in this chapter is to gain a big picture understanding of NAV 2013. We will learn enough to envision how NAV can be used by a business manager or owner to help manage the activities and resources of a business. (Note that NAV is used in many not-for-profits businesses as well as for-profits.) We will also be introduced to the technical side of NAV from a developer's point of view.


NAV 2013 – an ERP system

NAV 2013 is an integrated set of business applications designed to service a wide variety business operations. Microsoft Dynamics NAV 2013 is an ERP system where ERP stands for Enterprise Resource Planning. An ERP system integrates internal and external data across a variety of functional areas including manufacturing, accounting, supply chain management, customer relationships, service operations, management of human and other resources, and others. By having many related applications well integrated, a full-featured ERP system provides an enter once, use many ways information processing toolset.

NAV 2013 ERP includes the following (and more):

  • Basic accounting functions (for example, general ledger, accounts payable, accounts receivable)

  • Order processing and inventory (for example, sales orders, purchase orders, shipping, inventory, receiving)

  • Relationship management (for example, vendors, customers, prospects, employees, contractors, and so on)

  • Planning (for example, MRP, sales forecasting, production forecasting)

  • Other critical business areas (for example, manufacturing, warehouse management, fixed assets)

The following diagram illustrates conceptually how the various functions integrate into a whole to form an ERP system:

A good ERP system, such as NAV 2013, is modular in design, which simplifies implementation, upgrading, modification, integration with third-party products and expansion for different types of clients, for Internet access, and so on. All the modules in the system share a common database and, where appropriate, common data.

The grouping of individual NAV 2013 functions that follows is based on the Departments Menu structure, supplemented by information from Microsoft marketing materials. Some of the groupings are a bit arbitrary; the important thing is to obtain a reasonable grasp of the overall components that make up the NAV 2013 ERP system.

NAV 2013 has two quite different styles of user interfaces. One UI, the Development Environment, is essentially similar to the previously used Classic Client and targets developers. The other UI style, the Role Tailored Client, targets end users. The example images in the following module descriptions are from the Role Tailored Client Departments menu.

Financial Management

Financial Management is the foundation of any ERP system. No matter what the business is, the money must keep flowing, and the flow of money must be tracked. The tools which help to manage the capital resources of the business are part of NAV's Financial Management module. These include all or part of the following application functions:

  • General Ledger: Manages the overall finances of the firm

  • Cash Management and Banking: Manages the inventory of money

  • Accounts Receivables: Tracks the incoming revenue

  • Accounts Payables: Tracks the outgoing funds

  • Analytical Accounting: Analyzes the various flows of funds

  • Inventory and Fixed Assets: Manages the inventories of goods and equipment

  • Multi-Currency and Multi-Language: Supports international business activities

The Financial Management section of the Departments menu is as follows:


NAV Manufacturing is general purpose enough to be appropriate for Make to Stock (MTS), Make to Order (MTO), Assemble to Order (ATO) as well as various subsets and combinations of those. Although off-the-shelf NAV is not particularly suitable for most process manufacturing and some of the very high volume assembly line operations, there are third-party add-on and add-in enhancements available for these applications. As with most of the NAV application functions, Manufacturing can be implemented to be used in a basic mode or as a full-featured system. NAV Manufacturing includes the following functions:

  • Product Design (BOMs and Routings): Manages the structure of product components and the flow of manufacturing processes

  • Capacity and supply requirements planning: Tracks the intangible and tangible manufacturing resources

  • Production scheduling (infinite and finite), Execution, and tracking: Tracks the planned use manufacturing resources, both on an unconstrained and constrained basis

The Manufacturing section of the Departments menu is as follows:

Supply Chain Management (SCM)

Obviously, some of the functions categorized as part of NAV Supply Chain Management (for example, sales, purchasing, and so on) are actively used in almost every NAV implementation. As a whole, these constitute the base components of a system appropriate for a distribution operation. The Supply Chain applications in NAV include all or parts of the following applications:

  • Sales order processing and pricing: Supports the heart of every business, including entering, pricing, and processing sales orders

  • Purchasing (including Requisitions): Includes planning, entering, pricing, and processing purchase orders

  • Inventory Management: Manages inventories of goods and materials

  • Warehouse Management including receiving and shipping: Manages the receipt, storage, retrieval, and shipment of material and goods in warehouses

Even though we might consider Assembly part of Manufacturing, the standard NAV 2013 Departments menu includes it in the Warehouse section.

The Supply Chain Management section of the Departments menu is as follows:

Business Intelligence and reporting (BI)

Although Microsoft marketing materials identify Business Intelligence and reporting as though it were a separate module within NAV, it's difficult to physically identify it as such. Most of the components that are used for BI and reporting purposes are (appropriately) scattered throughout various application areas. In the words of one Microsoft document, Business Intelligence is a strategy, not a product. Functions within NAV that support a Business Intelligence strategy include the following:

  • Standard Reports: These are distributed ready-to-use by end users

  • Account schedules and analysis reports: These use a very specialized report writer targeted only at General Ledger data

  • Query, XMLport and Report Designers: These are developer tools to support the creation of a wide variety of report formats, charts, XML and CSV files

  • Analysis by dimensions: This is a capability embedded in many of the other tools

  • Interfaces into Microsoft Office including Excel: These support the communications of data either into NAV or out of NAV

  • RDLC report viewer: This provides the ability to present NAV data in a variety of textual and graphic formats, includes user interactive capabilities

  • Interface capabilities such as Automation Controllers and web services: These are technologies to support interfaces between NAV 2013 and external software products

Relationship Management (RM)

NAV's Relationship Management functionality is definitely the "little sister" (or, if preferred, "little brother") to the fully featured stand alone Microsoft CRM system. The big advantage of RM is that it's tight integration with the NAV customer and sales data. For those who need the full Microsoft CRM, a module connecting it to NAV 2013 is available.

Also falling under the heading of Customer Relationship module is the NAV Service Management (SM) functionality. While the RM component shows up in the menu as a part of sales and marketing, the SM component is identified as an independent function in the menu structure.

  • Relationship Management:

    • Marketing campaigns: Plans and manages promotions

    • Customer activity tracking: Analyzes customer orders

    • To do lists: Manages what's to be done and tracks what's been done

  • Service Management:

    • Service contracts: Supports service business operations

    • Labor and part consumption tracking: Tracks the resources consumed by the service business

    • Planning and dispatching: Manages service calls

Human Resource management (HR)

NAV Human Resources (HR) is a very small module, but relates to a critical component of the business, the people. Basic employee data can be stored and reported via the master table (in fact, one can use HR to manage data about individual contractors in addition to employees). A wide variety of individual employee attributes can be tracked by use of the following dimensions fields:

  • Employee tracking: Maintains basic employee description data

  • Skills inventory: Maintains an inventory of the capabilities of employees

  • Absence tracking: Maintains basic attendance information

  • Employee statistics: Tracks government required employee attribute data such as age, gender, length of service, and so on

Project Management

The NAV Project Management module consists of the jobs functionality supported by the resources functionality. Projects can be short or long term. They can be external (in other words billable) or internal. This module is often used by third parties as the base for vertical market add-ons (for example, for construction or job-oriented manufacturing). This application area includes parts or all of the following functions:

  • Budgeting and cost tracking: Manages project finances

  • Scheduling: Plans project activities

  • Resource requirements and usage tracking: Manages people and equipment

  • Project accounting: Tracks the results


Significant changes for NAV 2013

In some ways, NAV 2013 is as notable for what is no longer included in the product as what is new. The old Classic Client user interface and Classic Database have been left behind along with the associated two-tier system. NAV 2013 is no longer constrained by the technology limitations those required. All user and development focus is now on the Role Tailored Client.

There are added capabilities in terms of functionality, development tools, Internet compatibility, and increased integration to other Microsoft products along with other improvements. Information on the minimum hardware and software requirements to install and run Microsoft Dynamics NAV 2013 are found in the Developer and IT Pro Help Microsoft Dynamics NAV 2013 Requirements.

Following are some of the specific areas where NAV 2013 contains significant changes (this list is representative, not comprehensive).

Application changes

  • Cash Flow Forecasting

  • Cost Accounting Budgeting, Tracking, and Analysis

  • VAT Management

  • Warehouse Inventory Movement

  • Supply Planning

  • Assembly Management (an expanded version of the previous Kitting functionality)

  • Jobs WIP and Service Usage

  • HR Time Sheets

  • Dimensions data structure (major revision for efficiency)

  • RapidStart Services (implementation tools to help set up a new company)

Client enhancements

  • New SharePoint Client

  • New Web Client

  • Increased control over user interface

  • Increased Office compatibility, both look and feel, and Excel integration

  • New filtering capabilities

  • Copy and Paste between documents

  • Two-way Copy and Paste with Excel

  • Additional Page layout design control

  • Enhanced extensibility and charting

  • Customizable User Help documentation

  • OneNote integration

Development tools

  • New Query object for data view definition and data extraction

  • New Page Design immediate preview capability

  • New Debugger with state-of-the-art functionality and RTC compatibility

  • New Report Data Designer

  • Enhanced integration with Visual Studio for report layout design

Other areas

  • All development work is done in the Development Environment (formerly the Classic Client) combined with Visual Studio for report layout; all of the user work is done in one of the Role Tailored Clients

  • OData support

  • 100 percent 64-bit server

  • NAV Application Server enhanced and runs on the Service Tier

  • Internal data coding is done in Unicode


A developer's overview of NAV 2013

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.

NAV 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.


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 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:


Downloading the example code

You can download the example code files for all Packt books you have purchased from your account at If you purchased this book elsewhere, you can visit and register to have the files e-mailed directly to you.

Object Designer tool icons

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:

C/AL programming language

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.

NAV object and system elements

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


    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.

NAV functional terminology

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.

User Interface

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:


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.


Developing in NAV 2013 – hands-on

One of the best ways to learn a new set of tools, such as a programming environment and language, is to experiment with them. We're going to have some fun doing that throughout this book. We're going to experiment where the cost of errors (otherwise known as Learning) is small. Our development work will be a custom application of NAV 2013 for a relatively simple, but realistic, application.

We're going to do our work using the Cronus demo database that is available with all NAV 2013 distributions and is installed by default when we install the NAV 2013 demo system. The simplest way to install the NAV 2013 demo is to locate all the components on a single workstation. A 64-bit system running Windows 7 Professional will suffice. Additional requirements information is available in the MSDN library ( under the heading System Requirements for Microsoft Dynamics NAV 2013. Other helpful information on installing NAV 2013 (the demo option is a good choice for our purposes) and addressing a variety of setup questions is available in the NAV 2013 area of the MSDN library. In fact, all the Help information for NAV 2013 is accessible in the MSDN library.

The Cronus database contains all of the NAV objects and a small, but reasonably complete, set of data populated in most of the system's functional applications areas. Our exercises will interface very slightly with the Cronus data, but do not depend on any specific data values.

To follow along with our exercises as a developer, you will need a developer license for the system with rights allowing the creation of objects in the 50,000 to 50,099 number range. This license should also allow at least read access to all of the objects numbered below 50,000. If you don't have such a license, check with your Partner or your Microsoft sales representatives to see if they will provide a training license for your use.

Our scenario for development exercises

Our company runs a small, for-profit radio station. The station is WDTU and it broadcasts at 91.5 FM. The radio station is free form, which means there are many different DJs all with their own style and music. Each DJ is given a three-hour slot of time, and is responsible for playing the government required public service announcements (PSAs), sports, news and weather at the top of each hour, and a set amount of paid advertisements.

We have been moving our vast vinyl and compact disc collection to high-quality MP3s on our internal data store, but will still allow DJs to bring in their own music if we don't have it in our library. For the music already converted, we need to have a user-friendly interface to select the songs played and to preview them for entry into the playlist. We also need an easy way for the DJ to create a provisional item if the record cannot be found.

Our DJs must be able to preview all songs that have been converted to MP3s on the show page as well as on their home page. To succeed as a for-profit business, the radio station needs to track what, when, and how many advertisements are broadcast in order to invoice customers. In order to operate as a licensed radio station, there are two major requirements and reporting agencies. ASCAP needs a list of all songs (or other copyrighted material) that is played during the shows during specific time periods. The government requires that the radio station perform public service by broadcasting PSAs, reporting the date and time each was played and reporting the total number of times each was played during a period of time. Currently, both reporting agencies require one month reporting intervals, but this may change.

Getting started with the application design

Our design for our radio station will start with a Radio Show table, a Radio Show Card page, a Radio Show List page, and a simple Radio Show Schedule List Report. Along the way, we will review the basics of each NAV object type.

When we open the NAV Development Environment for the first time, or to work on a different database, we must define what database should be opened. Click on File | Database | Open, then choose a database, as shown in the following screenshot:

Application tables

Table objects are the foundation of every NAV application. Tables contain data structure definitions, as well as properties that describe the behavior of the data, including data validations and constraints.

More business logic is required in complex applications than simple data type validation, and NAV allows C/AL code to be put in the table to control insertion, modification, and deletion of records as well as logic on the field level. When the bulk of the business logic is coded at the table level, it is easier to develop, debug, support, modify, and even upgrade. A good design in NAV requires that as much of the business logic as possible should reside in the tables.

Designing a simple table

Our primary master data table will be the Radio Show table, as this is the link between what we get paid for (advertisements) and what we owe (song royalties), as well as meeting our civic duty requirement (PSAs).

First, we will open the NAV Development Environment, click on Tools| Object Designer and select Table. We can view the design of existing master tables in NAV by highlighting the table (for example, Table 18 - Customer, or Table 27 - Item) and clicking on Design.

Each master table has a standard field for the primary key (a Code data type field of 20 characters called No.) and has standard information regarding the entity the master record represents (for example, Name, Address, City, and so on for the Customer table, and Description, Base Unit of Measure, Unit Cost, and so on for the Item table).

The Radio Show table will have the following field definitions:

Field names



20 character text (code)


10 character text (code)


50 character text

Resource No.

20 character text (code)

Resource Name

50 character text

Run Time


Start Time


End Time
















In the preceding list, three of the fields are defined as Code fields, which are text fields that limit the alphanumeric characters to upper case values. Code fields are used throughout NAV for primary key values. Code fields are used to reference or be referenced by other tables (also known as foreign keys). The No. will be the unique identifier in our table. We will utilize a set of standard internal NAV functions to assign a user-defined No. Series range that will auto increment the value on table insertion and possibly allow for user entry (as long as it is unique in the table) based on a setup value. The Resource No. references the standard Resource table and the Type field will reference a custom table we will create to allow for flexible Type values.

We will need to design and define the reference properties at the field level in the Table Designer window, as well as compile them, before the validation will work. At this point, let's just get started with some field definitions and create the foundation for the Radio Show table.

Creating a simple table

To view the table designer, open the NAV 2013 Development Environment and the database in which we will be doing our development. In the Object Designer window, click on Table (in the left column of buttons) and click on New (in the bottom row of buttons). Enter the first field number as 10 (the default is 1), and increment each remaining field number by 10 (the default is 1). This will allow us to add additional fields in between existing fields later, when necessary.


Once a table is referenced by other objects, or contains any data, the field numbers of previously-defined fields should not be changed.

In the Description field, we will put notes for the fields that will need properties set at a later time. The following screenshot shows our new table definition in the Table Designer window:

Now we can close the table definition. (Click on File | Save or Ctrl + S or press ESC or close the window. The first two options are the explicit methods of saving our work.) We will see a message reminding us to save our changes, as shown in the following screenshot:

Click on Yes to save the changes. We must now assign the object number (in this case use 50000) and a unique name (it cannot duplicate the first 30 characters of another table object in the database). We will name our table Radio Show because that is the type of master record we will be storing in the table. The Save As window is shown in the following screenshot:

Note that the Compiled option is automatically checked, which is the default for NAV. Once we click on OK and the object is successfully compiled, it is immediately ready to be executed within the application. If the object we were working on was not ready to be compiled without error, we could unselect the Compiled option in the Save As window, as shown in the preceding screenshot.


Be careful, as uncompiled objects will not be considered by C/SIDE when changes are made to other objects. Until we have compiled an object, it is a work in progress, not an operable routine. There is a Compiled flag on every object that gives its compilation status. Even when we have compiled an object, we have not confirmed that all is well. We may have made changes that affect other objects which reference the modified object. As a matter of good work habit, we should recompile all objects before we end work for the day.


Pages provide views of data or processes designed for on-screen display (or exposure as web services) and also allow for user data entry into the system. Pages act as containers for action items (menu options).

There are several basic types of display/entry pages in NAV, they are given as follows:

  • List

  • Card

  • Document

  • Journal/Worksheet

There are also page parts (they look and program like a page, but aren't intended to stand alone) as well as user interfaces that appear as pages, but are not page objects. The latter user interfaces are generated by various dialog functions.

List pages

List pages display a simple list of any number of records in a single table. The Customer List page (with its associated FactBoxes) in the following screenshot shows a subset of the data for each customer displayed. List pages/forms often do not allow entry or editing of the data. Journal/Worksheet pages look like list pages, but are intended for data entry. Standard list pages are always displayed with the navigation pane on the left. The Customer List page is seen in the following screenshot:

Card pages

Card pages display one record at a time. These are generally used for the entry or display of individual table records. Examples of frequently accessed card pages include Customer Card for customer data, Item Card for inventory items, and G/L Account Card for General Ledger accounts.

Card pages often have FastTabs (one FastTab consisting of a group of controls with each tab focusing on a different set of related customer data). FastTabs can be expanded or collapsed dynamically, allowing the data visible at any time to be controlled by the user.

Card pages for master records display all the required data entry fields. Typically, they also display summary data about related activity so that the Card page can be used as the primary inquiry point for master records. The following screenshot is a sample of a standard Customer Card:

Document pages

Another page style within NAV consists of what looks like a Card page plus a List page. An example is the Sales Order page as shown in the following screenshot. In this example, the upper portion of the page is in Card page format with several tabs showing sales order data fields that have a single occurrence on the page (in other words, they do not occur in a repeating column). The lower portion of the Document page is in List page format (all fields are in repeating columns) showing the Sales Order line items.

Line items may include product to be shipped, special charges, comments, and other pertinent order details. The information to the right of the data entry is related data and computations (FactBoxes) that have been retrieved and formatted. At the top of the page is the information for the Ordering customer. The bottom right contains information for the item on the selected line. The following screenshot shows an example of the Sales Order Document page:

Journal/Worksheet pages

Journal and Worksheet pages look very much like List pages. They display a list of records in the body of the page. Many have a section at the bottom that shows details about the selected line and/or totals for the displayed data. These pages may also include a Filter pane and perhaps a FactBox. The biggest difference between Journal/Worksheet pages and basic List pages is that Journal and Worksheet pages are designed to be used for data entry (though this may be a matter of personal or site preference). An example of the Requisition Worksheet page in Purchasing is shown in the following screenshot. The Req. Worksheet assists the user in determining and defining which purchases should be made. Refer the following screenshot:

Standard elements of pages

A page consists of page properties and triggers, controls, control properties, and triggers. Data controls generally are either labels displaying constant text or graphics, or containers that display data or other controls. Controls can also be buttons, action items, and page parts. While there are a few instances where we must include C/AL code within a page or page control triggers, it is good practice to minimize the amount of code embedded within pages. Any data-related C/AL code should be located in the table object rather than in the page object.

Creating a List page

Now we will create a List page for the table we created earlier. A List page is the initial page that is displayed when a user accesses any data table. The NAV Development Environment has wizards (object generation tools) to help create basic pages. Generally, we should expect to spend additional time in the Page Designer tool, after our wizard work, to make the layout ready to be presented to users.

Our first List page will be the basis for viewing our Radio Show master records. From the Object Designer window, click on Page, then click on New. The New Page screen will appear. Enter the name (Radio Show) or table object ID (50000) in the Table field. This is the table to which the page will be bound. We can add additional tables to the page object C/AL Global Variables after we close the wizard, as we are then working within the Object Designer. Choose the option Create a page using a wizard: , and select List. Click on OK, as shown in the following screenshot:

The next step in the wizard shows the fields available for the List page. We can add or remove any of the field columns using the >, <, >>, and << buttons. This is shown in the following screenshot:

Add all the fields using >> and click on Next, as shown in the following screenshot:

The next wizard step shows the available Subforms, System FactBoxes, and Charts that are available to add to our page. These can be seen in the following screenshot:

We can add these later in the Page Designer window as needed. Click on Finish to exit the List Page Wizard and enter the Page Designer, which is shown in the following screenshot:

Click on Preview to view the page with the default ribbon. Note that in the Preview mode we cannot insert, modify, or delete any data. The Preview page is not connected to the database data. We will need to compile the page and Run it to manipulate the data. The Page Preview window is shown in the following screenshot:

The availability of some capabilities and icons (such as OneNote) will depend on what software is installed on our development workstation. Close the preview of the List page and close the window or press ESC to save. Number the page 50000 and name the object Radio Show List, as shown in the following screenshot:

Creating a Card page

Next, let's create a Card page. The wizard process for a Card page is almost the same as for a List page, with an additional step. In Object Designer, with the Page option selected, click on New again. Enter the same table (Radio Show) and make sure the Create a page using a wizard: option is selected and that Card is highlighted, as shown in the following screenshot:

The next step in the wizard is specific to Card pages, which allows us to create FastTabs. These are the display tools that allow the user to expand or collapse window sections for ease of viewing. For our Radio Show we will divide our table fields into two FastTab sections as shown in the following screenshot. The FastTabs will be General (primary key, description, resource information, and duration) and Schedule (days of the week), as shown in the following screenshot:

After defining the FastTab names, we must assign the data fields to the tabs on which they are to appear. We will select the tabs based on the FastTab names we assigned. We can select the fields from the Available Fields list and assign the order as we did in List Page Wizard. Click on the Next> button to proceed.

For the General FastTab, select the following fields: No., Type, Description, Resource No., Resource Name, Run Time, Start Time, and End Time, as shown in the following screenshot:

Click on the Schedule tab to populate the Schedule FastTab. Select Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, and Sunday, as shown in the following screenshot:

The last Card Page Wizard step is to add the available Subpages, System FactBoxes, and Charts. Again, if we decide later we want any of those, we will add them from within the Page Designer window. The last step is shown in the following screenshot:

Click on Finish to view the generated code in the Page Designer dialog. We will have the following screen:

Click on Preview to show a view-only display of the card page, which will display as follows:

Exit out of the Preview and Page Designer windows and save the page as ID 50001, and Name as Radio Show Card, as shown in the following screenshot:

Later on we can add an action to the List page which will link to the Card page for to insert and edit Radio Show records. We will also add the List page to the Role Center page for our radio station user.

Creating some sample data

Even though we haven't added all the bells and whistles to our Radio Show table and pages, we can still use them to enter sample data. The Radio Show list page will be the easiest to use for this.

In Object Designer, with pages selected, highlight page 50000, Radio Show list, and click on Run. Then click the New icon on the ribbon. An empty line will open up where we can enter our sample data. Of course, since our table is very basic at this point, without any validation functionality, table references, function calls, and so on, we will need to be creative and enter all the individual data fields accurately and completely on our own. Examples are shown in the following screenshot:

Enter the data shown in the following table. Later on, after we add more capabilities to our table and pages, some of the fields will be either automatically entered or available on a lookup basis. But for now, simply key in each field value. If the data that we key in now conflicts with the validations we create later (such as data in referenced tables), we may need to delete this test data and enter new test data later. Consider this data temporary so that we can see what the page looks like with the data. The data is given in the following table:




Resource No.

Resource Name

Run Time



Marks Morning Talk Show


Mark Hanson

4 hours



Local Show with Dave P


Dave Poulaski

2 hours



What's Up Metro City?


Linda Martin

2 hours



I'm Listening Metro City


Matt Saunders

2 hours



Working It Out Afternoon Show


Matt Richards

3 hours



World News


Phil Petersen

3 hours

Creating a List Report

Open the Object Designer, select Report and click on New. The Report Dataset Designer is empty when it displays, so we need to add the first Data Source (table) to the first blank row. Type 50000 or Radio Show into the Data Source column, as shown in the following screenshot:

To add multiple data fields from the table we can use the Field Menu option, which can be accessed via the icon on the toolbar or the View | Field Menu. The Field Menu option will show a list of all the fields in the Radio Show table. The toolbar is shown in the following screenshot:

Highlight the first six fields in the Field Menu dialog. Then click on the next blank line in Report Dataset Designer, as shown in the following screenshot:

A confirmation box will appear asking if we want to add the fields selected. Click on Yes, highlighted in the following screenshot:

The fields will appear in the Report Dataset Designer dialog without needing to type them in manually, as shown in the following screenshot:

Now we need to proceed to the report layout tool which is part of Visual Studio 2010 (or the free Visual Web Developer 2010 Express). Click on View | Layout, as shown in the following screenshot:

Visual Studio 2010 will open with a blank design surface and no dataset controls visible. Unlike the Page Designer, there is no report wizard to help with the layout of a new report. All the report layout design work must start from scratch with the blank design surface. The report design surface is shown in the following screenshot:

To show the dataset available from NAV, click on View and select Report Data (the last item on the list), as shown in the following screenshot:

A new Report Data pane will show on the left of the Visual Studio layout window, as seen in the following screenshot:

To create our simple list we will insert a simple table object (a data region with fixed number of columns but variable number of rows) to the design surface. Right-click anywhere on the design surface and expand the Insert sub-menu to view the tools available on the report. Click on the Table tool object, then we can use drag-and-drop to bring controls from the toolbox to the design surface. These steps are shown in the following screenshot:

The table layout object defaults to three columns with a Header row (repeated once) and a Data row (repeated for each row of data retrieved from NAV). This is shown in the following screenshot:

Drag-and-drop each of the six columns into the Table object. To add additional columns, right-click on the table object header and select Add Columns (we could also drag-and-drop a field from the dataset to the table). The caption with the basic format of Field Name Table Name will default into the header row (for example, the field name Type followed by the table name Radio Show), as shown in the following screenshot:

Let's do a little clean-up in the header row by making the captions look as they do in standard NAV reports by manually typing in the field names as headings, as shown in the following screenshot. (Later on, we will learn that this is not the optimum method and these headings should be defined in the C/SIDE RD before we get to the VS RD.)

We will save our work by clicking on File | Save All (or Ctrl + Shift + S) and then exit from Visual Studio (File | Exit or Alt + F4). Next, we will see the Save changes? to the RDLC (client report definition data) confirmation box. Click on Yes, as shown in the following screenshot:

Back in NAV Object Designer, exit out of the report or click on File | Save, and we will need to respond to two confirmation boxes. The first asks if we want to save the report layout from Visual Studio. Click on Yes, as shown in the following screenshot:

The second confirmation appears when we change focus to the Report Designer. It allows us to load the RDLC report layout XML into the NAV database report object. Enter 50000 for the ID, and name the report Radio Show List. Click OK to save it, as shown in the following screenshot:

To view the report, make sure the new report object is selected, then click on Run in the Object Designer dialog, as shown in the following screenshot:

An instance of RTC (Role Tailored Client) will open with the Report Request Page showing. This is where the user can set filters, choose a sort sequence and choose print options. For our example, this page is shown in the following screenshot:

Click on Preview to display the report onscreen. The report will show our simple table layout with the fixed definition column captions showing exactly as we typed them. This is seen in the following screenshot:

Much more to come

All we've done so far is scratch the surface. But if you're following along on your own system, especially if you've done a little experimenting along the way, you have a pretty good overview of the development process for NAV 2013.

Other NAV object types

We'll finish up our introductory review of NAV's object types.


A codeunit is a container for chunks of C/AL code to be called from other objects. These chunks of code are called functions. Functions can be called from any of the other NAV object types that can contain C/AL code. Codeunits can also be exposed (published) as web services. This allows the functions within a published codeunit to be invoked by external routines.

Codeunits are suited structurally to contain only functions. Even though functions could be placed in other object types, the other object types have superstructures that relate to their designed primary use as pages, reports, and so on.

Codeunits act only as a container for C/AL-coded functions. They have no auxiliary functions, no method of user interaction, and no pre-defined processing. If we are creating one or two functions that are closely related to the primary activity of a particular report, but these functions are needed from both within and outside of the report, then, by all means, include the functions in the report. Otherwise, use a Codeunit.

There are several codeunits delivered as part of the standard NAV product which are really function libraries. These codeunits consist totally of utility routines, generally organized on some functional basis (for example, associated with Dimensions or with some aspect of Manufacturing or some aspect of Warehouse management). Many of these can be found by filtering the Codeunit Names on the strings "Management" and "Mgt" (the same could be said for some of the tables with the string "Buffer" in their name). Some developers create their own libraries of favorite special functions and include such a function library codeunit in systems on which they work.

If a Codeunit is structured very simply, and can operate in a stand-alone mode, it is feasible to test it in the same way one would test a Report or a Page. Highlight the Codeunit and click on the Run button. The Codeunit will run for a single cycle. However, most codeunits are more complex and must be tested by a calling routine.


Queries are objects whose purpose is to very efficiently create extracted sets of data from the NAV database. NAV 2013 Queries translate directly into T-SQL query statements and run on the server side rather than on the service tier. A Query can extract data from a single table or multiple tables. In the process of extracting data, a Query can do different types of Joins (Inner Join, Outer Join, Cross Join), can filter, can calculate FlowFields (special NAV calculations which are discussed in detail in Chapter 3, Data Types and Fields), can sort, and can create sums and averages. Queries obey the NAV data structure business logic.

The output of a Query can be a CSV file (useful for Excel charts), an XML file (for charts or external applications) or an OData file (for a web service). Queries can be published for web service access similarly to Pages and Codeunits. Query results can also be viewed by Pages and Cues, but are especially powerful when output to charts.


MenuSuites are the objects that are displayed in the Navigation Pane menus. They differ considerably from the other object types we have discussed earlier because they not only have a completely different structure, but they are also maintained differently. MenuSuite entries do not contain triggers. The only customization that can be done with MenuSuites is to add, delete, or edit menu entries which are made up of a small set of properties.

In the Role Tailored Client, the data in the MenuSuites object is presented in the Departments page.


XMLports are a tool for importing and exporting data. XMLports handle both XML-structured data and other external text data formats. XML stands for eXtensible Markup Language and has become the de facto standard for exchanging data between dissimilar systems. For example, XMLports could be used to communicate between our NAV ERP system and our accounting firm's financial analysis and tax preparation system.

XML is designed to be extensible, which means that we can create or extend the definition as long as we communicate the revised XML format to our correspondents. There is a standard set of syntax rules to which XML formats must conform. XML is becoming more and more important because most new software uses XML. For example, the new versions of Microsoft Office are quite XML friendly. All web services communications are in the form of an exchange of XML-structured data.

The non-XML text data files handled by XMLports fall into two categories. One is known as comma separated value or comma delimited files (usually having a .csv file extension). Of course, the delimiters don't actually need to be commas. The other category is fixed format, in which the relative position and length of each field is pre-defined.

XMLports can contain C/AL logic for any type of appropriate data manipulation, either when importing or exporting. Functions such as editing, validating, combining, filtering, and so on, can be applied to the data as it passes through an XMLport.

Backups and documentation

As with any system where we can do development work, careful attention to documentation and backing up our work is very important. C/SIDE provides a variety of techniques for handling each of these tasks.

When we are working within the Object Designer, we can back up individual objects of any type or groups of objects by exporting them. These exported object files can be imported in total, selectively in groups, or individually, to recover the original version of one or more objects.

When objects are exported to text files, we can use a standard text editor to read or even change them. For example, if we wanted to change all of the instances of the field name Customer to Patient, we might export all of the objects to text and execute a mass Find and Replace. Making such code changes in a text copy of an object is subject to a high probability of error, as we won't have any of the many safety features of the C/SIDE environment to limit what we can do.

Internal documentation (that is, inside C/SIDE) of object changes can be done in three areas. First is the Object Version List, a field attached to every object, visible in the Object Designer screen. Whenever a change is made in an object, a notation should be added to the Version List.

The second area for documentation is the Documentation trigger that appears in every object type except MenuSuites . The Documentation trigger is at the top of the object and is the recommended location for noting a relatively complete description of any changes that have been made to the object. Such descriptions should include a brief description of the purpose of the change as well as technical information.

The third area we can place documentation is inline with modified C/AL code. Individual comment lines can be created by starting the line with double forward slashes //. Whole sections of comments (or commented out code) can be created by starting and ending the section with a pair of curly braces { }. Depending on the type of object, and the nature of the specific changes, we should generally annotate each change inline everywhere it affects the code, so all the changes can be easily identified by the next developer looking at this object.

In short, everything that we learned earlier about good documentation practices applies when doing development in NAV C/SIDE. This holds true whether the development is new work or a modification of existing logic.



In this chapter, we covered some basic definitions of terms related to NAV and C/SIDE. We followed with the introduction of seven types of NAV objects (Tables, Pages, Reports, Codeunits, Queries, MenuSuites, and XMLports). We also introduced Page and Report Creation through review and hands-on use beginning with a NAV application for the WTDU Radio Show programming management. Finally, we looked briefly at the tools that we can use to integrate with external entities, and we discussed how different types of backups and documentation are handled in C/SIDE. Now that we have covered these basics in general terms, let's dive into the detail of the primary object types.

In the next chapter, we will focus on Tables, the foundation of an NAV system.


Review questions

  1. An ERP system such as NAV 2013 includes a number of functional areas. Which of the following are part of NAV 2013? Choose four.

    1. Order Processing

    2. Human Resources

    3. Computer Aided Design (CAD)

    4. Inventory Control

    5. General Accounting

  2. New functionality in NAV 2013 includes (choose three):

    1. Assembly Management

    2. Filtering

    3. Copy and Paste with Excel

    4. Enhanced charting

    5. SQL Server database

  3. What are the seven NAV 2013 object types?

  4. NAV 2013 includes support for publishing objects as Web Services. True or False?

  5. NAV 2013 development is done in the C/SIDE IDE and Visual Studio 2010. True or False?

  6. The C/AL programming language is similar to which other language? Choose one.

    1. COBOL

    2. Java

    3. PHP

    4. Pascal

  7. The Work Date can only be changed by the System Administrator. True or False?

  8. All NAV objects except XMLports can contain C/AL code. True or False?

  9. Match the following table types and descriptions for NAV.

    a. Journals

    1) Audit trail

    b. Ledgers

    2) Validation process

    c. Register

    3) Invoice

    d. Document

    4) Transaction entries

    e. Posting

    5) History

  10. Which of the following describe NAV 2013? Choose two.

    1. Object based

    2. C# IDE

    3. Object oriented

    4. Customizable

    5. Includes a Storefront module

  11. Field number increments in a Table design default to what? Choose one.

    1. 10

    2. 1

    3. 64

    4. 100

    5. 10000

  12. The home page for a NAV 2013 User is called what? Choose one.

    1. Role Home

    2. Home Center

    3. Main Page

    4. Role Center

  13. A List Page, not a Card Page, is the initial page that a user sees when the users access any data table. True or False?

  14. Page Previews from the Development Environment can be used for data entry and maintenance. True or False?

  15. Visual Studio 2010 is used in NAV 2013 for what work? Choose one.

    1. Report data definition

    2. Report layout

    3. Role Center design

    4. Query processing

  16. Codeunits are the only NAV 2013 objects that can contain functions. True or False?

  17. Query output can be used as a Data Item for Reports. True or False?

  18. What object number range is available for assignment to customer-specific objects? Choose two.

    1. 20 – 500

    2. 50000 – 60000

    3. 150000 – 200000

    4. 50000 – 99999

    5. 10000 – 100000

  19. XMLports can only process XML formatted data. True or False?

  20. NAV 2013 Reports are often generated automatically through the use of a wizard. True or False?

About the Authors

  • David A. Studebaker

    David Studebaker has been a software consulting entrepreneur and manager most of his career while always maintaining a significant role as an application developer. David has been designing, developing, and teaching software since 1962. He has been a founding partner in five software service firms, most recently Studebaker Technology and Liberty Grove Software. Among his special achievements was the design and development of the very first production SPOOL system, a 1967 AT&T / IBM joint project.

    David has been writing for publication since his college days. His published writings include a decade of technical reviews for the ACM’s Computing Reviews and a variety of articles and reference material on shop floor data collection. David is the author of four other Packt books on programming in Dynamics NAV C/AL, two of which were coauthored with Christopher Studebaker.

    David has a BS in Mechanical Engineering from Purdue University and an MBA from the University of Chicago. He is a life member of the Association for Computing Machinery and was a founding officer of two ACM chapters.

    Browse publications by this author
  • Christopher D. Studebaker

    Christopher Studebaker has worked as a NAV Developer / Implementer since 1999. He has experience designing, developing, implementing, and selling in the NAV and SQL Server environments, specializing in retail, manufacturing, job shop, and distribution implementations, mostly in high user-count, high data volume applications.

    Chris has worked on many NAV implementations with integrations to external databases and third-party add-on products. Some special applications have included high volume order entry, pick-to-light systems, point of sale, procurement analysis, and web front ends.

    Chris acts in a consulting and training role for customers and for peer NAV professionals. He provides training both in informal and classroom situations, often developing custom course material to support courses tailored to specific student group needs. Courses have included various NAV functional and development areas. Chris was a co-author of two previous books on programming in NAV C/AL.

    Before becoming a certified NAV developer, Chris was a certified environmental consultant. His duties included regulatory reporting, data analysis, project management, and subcontractor oversight in addition to managing projects for hazardous material management and abatement.

    Chris is a Microsoft Certified IT Professional, SQL database developer, as well as a Microsoft Certified Business Solutions Professional in NAV Development and NAV Installation and Configuration. He has a Bachelor of Science degree from Northern Illinois University and has done graduate work at Denmark Technical University.

    Chris was a co-author of the Packt books, Programming Microsoft Dynamics NAV 2013 and Programming Microsoft Dynamics NAV 2015.

    Browse publications by this author

Latest Reviews

(1 reviews total)
Programming Microsoft Dynamics NAV 2013
Unlock this book and the full library FREE for 7 days
Start now