Programming Microsoft Dynamics NAV - Fifth Edition

4.5 (10 reviews total)
By Mark Brummel , David Studebaker , Chris Studebaker
  • Instant online access to over 8,000+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Introduction to NAV 2017

About this book

Microsoft Dynamics NAV is a full business solution suite, and a complete ERP solution, which contains a robust set of development tools to support customization and enhancement. These tools help in greater control over financials and can simplify supply chain, manufacturing, and operations.

This book will take you from an introduction to Dynamics NAV and its integrated development tools to being a productive developer in the Dynamics NAV Development Environment. You will find this book very useful if you want to evaluate the product's development capabilities or need to manage Dynamics NAV based projects. It will teach you about the NAV application structure, the C/SIDE development environment, the C/AL language paired with the improved editor, the construction and uses of each object type, and how it all fits together to build universal applications. With this new edition, you will be able to understand how to design and develop using Patterns and new features such as Extensions and Events.

Publication date:
April 2017
Publisher
Packt
Pages
706
ISBN
9781786468192

 

Chapter 1. Introduction to NAV 2017

"Time changes all things; there is no reason why language should escape this universal law."                                                                                                          - Ferdinand de Saussure

"When we use a language, we should commit ourselves to knowing it, being able to read it, and writing it idiomatically."                                                                                                             - Ron Jeffries

Microsoft Dynamics NAV has one of the largest installed user bases of any enterprise resource planning (ERP) system serving over 100,000 companies and one million plus individual users at the time of this writing. The community of supporting organizations, consultants, implementers, and developers continues to grow and prosper. The capabilities of the off-the-shelf product increase with every release. The selection of the add-on products and services expands both in variety and depth.

The release of Microsoft Dynamics NAV 2017 continues its 20+ year history of continuous product improvement. It provides more user options for access and output formatting. For new installations, NAV 2017 includes tools for rapid implementation. For all installations, it provides enhanced business functionality and more support for ERP computing in the cloud, including integration with Microsoft Office 365.

NAV 2017 is also the base foundation for Microsoft Dynamics 365 for Financials, which is a cloud-based subset of the product that you can customize using extensions. We will discuss the concept of extensions in this book.

Our goal in this chapter is to gain a big picture understanding of NAV 2017. You will be able to envision how NAV can be used by the managers (or owners) of an organization to help manage activities and the resources, whether the organization is for-profit or not-for-profit. You will also be introduced to the technical side of NAV from a developer's point of view.

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

  • A general overview of NAV 2017
  • A technical overview of NAV 2017
  • A hands-on introduction to C/SIDE development in NAV 2017
 

NAV 2017 - An ERP system


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

NAV 2017 ERP addresses the following functional areas (and more):

  • Basic accounting functions (for example, general ledger, accounts payable, and accounts receivable)
  • Order processing and inventory (for example, sales orders, purchase orders, shipping, inventory, and receiving)
  • Relationship management (for example, vendors, customers, prospects, employees, and contractors)
  • Planning (for example, MRP, sales forecasting, and production forecasting)
  • Other critical business areas (for example, manufacturing, warehouse management, marketing, cash management, and fixed assets)

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

The groupings of individual NAV 2017 functions following is based on the Departments menu structure, supplemented by information from Microsoft marketing materials. The important thing is to understand the overall components that make up the NAV 2017 ERP system:

NAV 2017 has two quite different styles of user interface (UI). One UI, the development environment, targets developers. The other UI style, the RoleTailored client, targets end users. In NAV 2017, there are four instances of the RoleTailored client - for Windows, for web interaction, for tablet use, and a phone client, which was introduced in NAV 2016. The example images in the following module descriptions are from the RoleTailored client's Departments menu in the Windows client.

Financial management

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

  • General ledger - managing overall finances of the firm
  • Cash management and banking - managing inventory of money
  • Accounts receivable - tracking incoming revenue
  • Accounts payable - tracking outgoing funds
  • Analytical accounting - analyzing various flows of funds
  • Inventory and fixed assets - managing inventories of goods and equipment
  • Multi-currency and multi - language-supporting international business activities

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

Manufacturing

NAV 2017 manufacturing is general-purpose enough to be appropriate for Make to Stock (MTS), Make to Order (MTO), and 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) - managing the structure of product components and the flow of manufacturing processes
  • Capacity and supply requirements planning - tracking the intangible and tangible manufacturing resources
  • Production scheduling (infinite and finite), execution, and tracking quantities and costs, plus tracking 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

Obviously, some of the functions categorized as part of NAV 2017 supply chain management (SCM), for example, sales and purchasing) are actively used in almost every NAV implementation. The supply chain applications in NAV include all or parts of the following applications:

  • Sales order processing and pricing - supporting the heart of every business
  • Purchasing (including Requisitions) - planning, entering, pricing, and processing purchase orders
  • Inventory management - managing inventories of goods and materials
  • Warehouse management including receiving and shipping - managing the receipt, storage, retrieval, and shipment of material and goods in warehouses

 

 

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

As a whole, these functions constitute the base components of a system appropriate for distribution operations, including those that operate on an ATO basis.

Business Intelligence and reporting

Although Microsoft marketing materials identify Business Intelligence (BI) and reporting as though it were a separate module within NAV, it's difficult to physically identify it as such. Most of the components 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 BI strategy include the following:

  • Standard reports - distributed ready-to-use by end users
  • Account schedules and analysis reports - a specialized report writer for General Ledger data
  • Query, XMLport and Report designers - developer tools to support the creation of a wide variety of report formats, charts, and XML and CSV files
  • Analysis by dimensions - a capability embedded in many of the other tools
  • Interfaces into Microsoft Office and Microsoft Office 365 including Excel-communications of data either into NAV or out of NAV
  • RDLC report viewer - provides the ability to present NAV data in a variety of textual and graphic formats, including user interactive capabilities
  • Interface capabilities such as DotNet interoperability and web services - technologies to support interfaces between NAV 2017 and external software products
  • NAV 2017 has standard packages for Power BI, both integrated on the role center as well as dashboards

Artificial Intelligence

A new feature of NAV 2017 is integration with Cortana intelligence, which is used for forecasting. The algorithms used in Artificial Intelligence (AI) can be used to give users extra information to make business decisions.

Relationship Management

NAV's Relationship Management (RM) functionality is definitely the little sister (or, if you prefer, little brother) of the fully featured standalone Microsoft CRM system and the new Dynamics 365 for Sales and Dynamics 365 for Marketing. The big advantage of NAV RM is its tight integration with NAV customer and sales data. With NAV 2016, Microsoft introduced a new way of integrating with CRM using OData.

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

  • Relationship management:
    • Marketing campaigns - plan and manage promotions
    • Customer activity tracking - analyze customer orders
    • To do lists - manage what is to be done and track what has been done
  • Service management:
    • Service contracts - support service operations
    • Labor and part consumption tracking - track the resources consumed by the service business
    • Planning and dispatching - managing service calls

Human resource management

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

  • Employee tracking - maintain basic employee description data
  • Skills inventory - inventory of the capabilities of employees
  • Absence tracking - maintain basic attendance information
  • Employee statistics - tracking government required employee attribute data such as age, gender, length of service

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 (such as construction or job oriented manufacturing). This application area includes parts or all of the following functions:

  • Budgeting and cost tracking - managing project finances
  • Scheduling - planning project activities
  • Resource requirements and usage tracking - managing people and equipment
  • Project accounting - tracking the results
 

A developer's overview of NAV 2017


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

NAV object types

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

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

The C/SIDE Integrated Development Environment

NAV 2017 includes an extensive set of software development tools. The NAV development tools are accessed through C/SIDE, which runs within the development environment client. This environment and its complement of tools are usually collectively referred to as C/SIDE. C/SIDE includes the C/AL (Client Application Language) compiler. All NAV programming uses C/AL. No NAV development can be done without using C/SIDE, but other tools are used to complement C/AL code (such as Visual Studio, .NET, JavaScript, COM controls, and OCX controls, among others).

The C/SIDE IDE is referred to as the Object Designer within NAV. It is accessed through a separate shortcut, which is installed as part of a typical full system installation. When we open the Object Designer, we see the following screen:

Object Designer tool icons

When we open an object in the applicable Designer (Table Designer, Page Designer, and so on) for that object, we will see a set of tool icons at the top of the screen. The following table lists those icons and the object types to which they apply. On occasion, an icon will appear when it is of no use:

C/AL programming language

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

C/AL syntax is similar to Pascal syntax. Code readability is always enhanced by careful programmer attention to structure, logical variable naming, process flow consistent with that of the code in the base product and good documentation both inside and outside of the code.

Note

Good software development focuses on design before coding and accomplishing design goals with a minimum of code. Dynamics NAV facilitates that approach. In 2012, a team made up of Microsoft and NAV community members began the NAV design patterns project. As defined in Wikipedia, a design pattern is a general reusable solution to a commonly occurring problem.  Links to the NAV design patterns project information follow:

A primary goal of this project is to document patterns that exist within NAV. In addition, new best practice patterns have been suggested as ways to solve common issues we encounter during our customization efforts. Now, when working on NAV enhancements, we will be aided by reference to the documentation of patterns within NAV. This allows us to spend more of our time designing a good solution using existing, proven functions (the documented patterns), spending less time writing and debugging code. A good reference for NAV design and development using patterns can be found here:https://www.packtpub.com/application-development/microsoft-dynamics-nav-2013-application-design

The NAV 2017 Reusing Code section states the following:

"Reusing code makes developing applications both faster and easier. More importantly, if you organize your C/AL code as suggested, your applications will be less prone to errors. By centralizing the code, you will not unintentionally create inconsistencies by performing the same calculation in many places, for example, in several triggers that have the same table field as their source expression. If you have to change the code, you could either forget about some of these triggers or make a mistake when you modify one of them."

 

 

Much of our NAV development work is done by assembling references to previously defined objects and functions, adding new data structure where necessary. As the tools for NAV design and development provided both by Microsoft and the NAV community continue to mature, our development work becomes more oriented to design and less to coding. The end result is that we are more productive and cost effective on behalf of our customers. Everyone wins.

NAV object and system elements

Here are some important terms used in NAV:

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

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.

  • Field: An individual data item, defined either in a table or in the working storage (temporary storage) of an object.
  • Record: A group of fields (data items) handled as a unit in many operations. Table data consists of rows (records) with columns (fields).
  • Control: In MSDN, a control is defined as a component that provides (or enables) user interface (UI) capabilities.
  • Properties: These are the attributes of the element such as an object, field, record, or control that defines some aspect of its behavior or use. Example property attributes include display captions, relationships, size, position, and whether editable or viewable.
  • Trigger: Mechanisms that initiate (fire) an action when an event occurs and is communicated to the application object. A trigger in an object is either empty, contains code that is executed when the associated event fires the trigger, or only contains comments (in a few cases, this affects the behavior of the trigger). Each object type, data field, control, and so on may have its own set of predefined triggers. The event trigger name begins with the word On, such as OnInsert, OnOpenPage, or OnNextRecord. NAV triggers have similarities to those in SQL, but they are not the same (similarly named triggers may not even serve similar purposes). NAV triggers are locations within objects where a developer can place comments or C/AL code. When we view the C/AL code of an object in its designer, we can see non-trigger code groups that resemble NAV event-based triggers:
    • Documentation: This can contain comments only, no executable code. Every object type except MenuSuite has a single Documentation section at the beginning of the C/AL code.
    • Functions: These can be defined by the developer. They are callable routines that can be accessed by other C/AL code from either inside or outside the object where the called function resides. Many functions are provided as part of the standard product. As developers, we may add our own custom functions as needed.
  • Object numbers and field numbers: All objects of the same object type are assigned a number unique within the object type. All fields within an object are assigned a number unique within the object (that is, the same field number may be repeated within many objects whether referring to similar or different data). In this book, we will generally use comma notation for these numbers (fifty thousand is 50,000). In C/AL, no punctuation is used. The object numbers from 1 (one) to 50,000 and in the 99,000,000 (99 million) range are reserved for use by NAV as part of the base product. Objects in these number ranges can be modified or deleted with a developer's license, but cannot be created. Field numbers in standard objects often start with 1 (one). Historically, object and field numbers from 50,000 to 99,999 are generally available to the rest of us for assignment as part of customizations developed in the field using a normal development license. Field numbers from 90,000 to 99,999 should not be used for new fields added to standard tables as those numbers are sometimes used in training materials. Microsoft allocates ranges of object and field numbers to Independent Software Vendor (ISV) developers for their add-on enhancements. Some such objects (the 14,000,000 range in North America, other ranges for other geographic regions) can be accessed, modified, or deleted, but not created using a normal development license. Others (such as in the 37,000,000 range) can be executed, but not viewed or modified with a typical development license.

The following table summarizes object numbering practice:

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

NAV functional terminology

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

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

User Interface

NAV 2017 user interface (UI) is designed to be role oriented (also called role tailored). The term role oriented means tailoring the options available to fit the user's specific job tasks and responsibilities. If user access is through one of the clients, the Role Tailored Client (RTC) will be employed. If the user access is via a custom-built client, the developer will have more responsibility to make sure the user experience is role tailored.

The first page that a user will see is the Role Center page. The Role Center page provides the user with a view of work tasks to be done; it acts as the user's home page. The home Role Center page should be tailored to the job duties of each user, so there will be a variety of Role Center page formats for any installation.

Someone whose role is focused on order entry will probably see a different RTC home page than the user whose role focuses on invoicing, even though both user roles are in what we generally think of as Sales & Receivables. The NAV 2017 RTC allows a great deal of flexibility for implementers, system administrators, managers, and individual users to configure and reconfigure screen layouts and the set of functions that are visible.

The following screenshot is the out-of-the-box Role Center for a Sales Order Processor:

The key to properly designing and implementing any system, especially a role tailored system, is the quality of the User Profile analysis done as the first step in requirements analysis. User Profiles identify the day-to-day needs of each user's responsibilities relative to accomplishing the business' goals. Each user's tasks must be mapped to individual NAV functions or elements, identifying how those tasks will be supported by the system. A successful implementation requires the use of a proven methodology. It is very important that the up-front work is done and done well. The best programming cannot compensate for a bad definition of goals.

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

 

Hands-on development in NAV 2017


One of the best ways to learn a new set of tools, like those that make up a programming language and environment, 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 2017 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 2017 distributions and is installed by default when we install the NAV 2017 demo system. The simplest way to install the NAV 2017 demo is to locate all the components on a single workstation. A 64-bit system running Windows 10 will suffice. Additional requirements information is available in the MSDN library (https://msdn.microsoft.com/en-us/dynamics-nav/system-requirements-for-microsoft-dynamics-nav) under the heading System Requirements for Microsoft Dynamics NAV 2017. Other helpful information on installing NAV 2017 (the demo option is a good choice for our purposes) and addressing a variety of setup questions is available in the NAV 2017 area of the MSDN library. In fact, all the help information for NAV 2017 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 will not depend on any specific data values.

To follow along with all 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 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.

NAV 2017 development exercise scenario

Our business is a small radio station that features a variety of programming, news, music, listener call-ins, and other program types. Our station call letters are WDTU. Our broadcast materials come from several sources and in several formats: vinyl records, CDs, MP3s, and downloaded digital (usually MP3s). While our station has a large library, especially of recorded music, sometimes our program hosts (also called disc jockeys or DJs) want to share material from other sources. For that reason, we need to be able to easily add items to our playlists (the list of what is to be broadcast) and also have an easy-to-access method for our DJs to preview MP3 material.

Like any business, we have accounting and activity tracking requirements. Our income is from selling advertisements. We must pay royalties for music played, fees for purchased materials such as prepared text for news, sports, and weather information, and service charges for our streaming Internet broadcast service. As part of our licensed access to the public airwaves, a radio station is required to broadcast public service programming at no charge. Often, that is in the form of Public Service Announcements (PSAs) such as encouraging traffic safety or reduction in tobacco use. Like all radio stations, we must plan what is to be broadcast (create schedules) and track what has been broadcast (such as ads, music, purchased programming, and PSAs) by date and time. We bill our customers for the advertising, pay our vendors their fees and royalties, and report our public service data to the appropriate government agency.

Getting started with application design

The 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 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... and then choose a database:

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 in simple data type validation, and NAV allows C/AL code to be put in the table to control the insertion, modification, and deletion of records as well as logic on the field level. When the bulk of the business logic is coded on the table level, it is easier to develop, debug, support, modify, and even upgrade. Good design in NAV requires that as much of the business logic as possible resides in the tables. Having the business logic coded on the table level doesn't necessarily mean the code is resident in the table. NAV 2017 Help recommends the following guidelines for placing C/AL code:

Note

In general, put the code in codeunits, instead of on the object on which it operates. This promotes a clean design and provides the ability to reuse code. It also helps enforce security. For example, typically users do not have direct access to tables that contain sensitive data, such as the General Ledger Entry table, nor do they have permission to modify objects. If you put the code that operates on the general ledger in a codeunit, give the codeunit access to the table, and give the user permission to execute the codeunit, then you will not compromise the security of the table and the user will be able to access the table. If you must put code on an object instead of in a codeunit, then put the code as close as possible to the object on which it operates. For example, put code that modifies records in the triggers of the table fields.

Designing a simple table

Our primary master data table will be the Radio Show table. This table lists our inventory of shows available to be scheduled.

First, open the NAV Development Environment, click on Tools | Object Designer and select Table. We can view or modify 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 (we may add more later):

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 (foreign keys). 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 Host No. references the standard Resource table and the Radio Show Type field will reference a custom table we will create to allow for flexible Type values.

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

Creating a simple table

To invoke the table designer, open the NAV 2017 Development Environment and the database in which we will be doing our development. In the Object Designer, click on Table (in the left column of buttons) and click New (in the bottom row of buttons). Enter the first field number as 1 (the default is 1), and increment each remaining field number by 10 (the default is 1). Sometimes, it is useful to leave large gaps (such as jumping from 80 to 200 or 500) when the next set of fields have a particular purpose not associated with the prior set of fields.

Note

The fields combining the primary key can use the numbers up to 9 since they are very unlikely to change. If this is changed, there is a substantial amount of refactoring to be done.

NAV 2017 Help says to not leave gaps in field numbers. Based on many years of experience, the authors disagree. Leaving numbering gaps will allow us to later add additional fields between existing fields, if necessary. The result will be data structures that are (at least initially) easier to read and understand. Once a table is referenced by other objects or contains any data, the field numbers of previously defined fields should not be changed.

The following screenshot shows our new table definition in the Table Designer:

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:

Click on Yes. We must now assign the object number (use 50000) and a unique name (it cannot duplicate the same first 30 characters of another table object in the database). We will name our table Radio Show based on the master record to be stored in the table:

Note that the Compiled option is automatically checked and the Synchronize Schema option is set to Now - with validation, which are the defaults for NAV. Once we press 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 uncheck the Compiled option in the Save As window.

Note

Uncompiled objects will not be considered by C/SIDE when changes are made to other objects. Be careful. 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.

The Synchronize Schema option choice determines how table changes will be applied to the table data in SQL Server. When the changes are validated, any changes that would be destructive to existing data will be detected and handled either according to a previously defined upgrade codeunit or by generating an error message. The Synchronize Schema option choices are shown in the following screenshot:

Refer to the documentation (https://msdn.microsoft.com/en-us/dynamics-nav/synchronizing-table-schemas) in the section called Synchronizing Table Schemas for more detail.

Pages

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

  • List
  • Card
  • Document
  • Journal/Worksheet
  • List Plus
  • Confirmation Dialog
  • Standard Dialog

There are also page parts (they look and program like a page, but aren't intended to stand alone) as well as UIs that display like pages, but are not page objects. The latter user interfaces are generated by various dialog functions. In addition, there are special page types such as Role Center pages and Navigate pages (for Wizards).

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

List pages

List pages display a simple list of any number of records in a single table. The Customers 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:

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 have FastTabs (a FastTab consists 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. Important data elements can be promoted to be visible even when a FastTab is collapsed.

Card pages for master records display all the required data entry fields. If a field is set to ShowMandatory (a control property we will discuss in Chapter 4, Pages - the Interactive Interface), a red asterisk will display until the field is filled. Typically, card pages also display FactBoxes containing summary data about related activity. Thus cards can be used as the primary inquiry point for master records. The following screenshot is a sample of a standard Customer Card:

Document pages

A document page looks like a card page with one tab containing a List Part page. An example is the Sales Order page shown in the following screenshot. In this example, the first tab and last four tabs are in card page format showing Sales Order data fields that have a single occurrence on the page (in other words, do not occur in a repeating column).

The second tab from the top is in List Part page format (all fields are in repeating columns) showing the Sales Order line items. Sales Order 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 area is related data and computations (FactBoxes) that have been retrieved and formatted. The top FactBox contains information about the ordering customer. The bottom FactBox contains information about the item on the currently highlighted sales line:

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 also have a section at the bottom that shows details about the selected line and/or totals for the displayed data. These pages may 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 General Journal page in Finance is shown in the following screenshot:

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, after our Wizard work is done, we will spend additional time in the Page Design tool to make the layout ready for presentation to users.

Our first List page will be the basis for viewing our Radio Show master records. From the Object Designer, 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 then we will be working in the Page Designer. Choose the Create a page using a wizard: option and select List, as shown in the following screenshot. Click on OK:

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:

Add all the fields using >> and click on Next >:

The next Wizard step shows the Subforms, System FactBoxes, and Charts that are available to add to our page:

Note

Subforms should properly be named Subpages. Such a change is being considered by Microsoft.

We can add these later in the Page Designer as needed. Click Finish to exit the wizard and enter the Page Designer:

Click on Preview to view the page with the default ribbon. Note that in Preview mode, we cannot insert, modify, or delete any of the layout or enter data. The Preview page is not connected to the database data. We need to compile the page and Run it to manipulate data. In the following screenshot, some fields are out of sight on the right-hand side:

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:

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 Page selected, click New again. Enter the same table (Radio Show) and make sure the Create a page using a wizard: option is selected and Card is highlighted:

The next step in the wizard is specific to Card pages. It 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 card we will divide our table fields into two sections, General (primary key, description, resource information, and duration) and Statistics (data about the show):

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

For the General FastTab, select the following fields: No., Show Code, Name, Run Time, Host Code, and Host Name, as shown in the following screenshot:

Click on the Statistics tab to populate the Statistics FastTab, select Average Listeners, Audience Share, Advertising Revenue, and Royalty Cost:

The last Card Page Wizard step is to choose from the available Subforms (Subpages), System FactBoxes, and Charts. If we decide later we want any of those, we will add them using the Page Designer:

Click Finish to view the generated code in the Page Designer:

Click the Preview button to show a view-only display of the Card page:

Exit the preview and Page Designer and save the page as ID as 50001, and Name as Radio Show Card:

Later on, we can add an action to the List page which will link to the Card page for inserting and editing radio show records and 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 Run. Then click the New icon on the ribbon. An empty line will open, 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 have to be creative (and careful) to enter all the individual data fields accurately and completely without guidance:

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

Note

We will use the testability framework for automated testing later in this book. A test codeunit is provided in the downloads, but for now, it is recommended to key in the data manually.

No.

Radio Show Type

Description

Host Code

Host Name

Run Time

RS001

TALK

CeCe and Friends

CECE

CeCe Grace

2 hours

RS002

MUSIC

Alec Rocks and Bops

ALEC

Alec Benito

2 hours

RS003

CALL-IN

Ask Cole!

COLE

Cole Henry

2 hours

RS004

CALL-IN

What do you think?

WESLEY

Wesley Ernest

1 hour

RS005

MUSIC

Quiet Times

SASKIA

Saskia Mae

3 hours

RS006

NEWS

World News

DAAN

Daan White

1 hour

RS007

ROCK

Rock Classics

JOSEPH

Josephine Perisic

2 hours

Creating a list report

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

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

Highlight the first six fields in the Field Menu. Then click on next blank line in the Report Dataset Designer:

A confirmation box will appear, asking if we want to add the fields selected. Click Yes:

The fields will appear in the Report Dataset Designer without having to type them in manually:

There are two options for RDLC report layout development tools. They are the current version of Visual Studio 2015 Community Edition or the SQL Server Report Builder (which can be downloaded here: https://www.visualstudio.com/vs/community/). NAV defaults to using Visual Studio, which we will use in this book. If the free SQL Server Report Builder is installed, it can be activated for NAV 2017 by accessing the Options... screen from the Tools menu option:

On the Options screen, set Use Report Builder to Yes:

Click on View | Layout to proceed to the chosen report layout tool:

The RDLC report layout tool opens 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 a blank design surface:

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

A new Report Data pane will show on the left of the Visual Studio layout window:

To create our simple list, we will insert a simple table object (a data region with a fixed number of columns but a variable number of rows) in 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 the Table tool object, then use drag-and-drop to bring a control from the toolbox to the design surface:

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

Drag and drop each of the six elements in the DataSet_Result into columns in the table object. To add additional columns, right-click on the table object header and select Insert Column (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:

Let's do a little clean-up in the header row by making the captions look like they do in standard NAV reports by manually typing in the field names:

We will save our work by clicking on File | Save All (or Ctrl + Shift + S) then exit Visual Studio (File | Exit or Alt + F4). Back in NAV's Object Designer, we will exit the report or click File | Save; then, we'll need to respond to two confirmation boxes. The first asks if we want to save the report layout from Visual Studio. This allows us to load the RDLC report layout XML into the NAV database report object. Click Yes:

This is followed by the second confirmation screen. Enter 50000 for the ID, and Name the report Radio Show List. Click OK to save:

To view the report, make sure the new report object is selected, then click Run at the bottom of the Object Designer screen:

An RTC instance will open with the Report Request Page showing. This is where the user can set filters, choose a sort sequence, and choose print options:

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:

Much more to come. All we've done so far is scratch the surface. But you should have a pretty good overview of the development process for NAV 2017.

Note

You will be in especially good shape if you've been able to following along in your own system, doing a little experimenting along the way.

 

Other NAV object types


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

Codeunits

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, such 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 direct user interaction, and no pre-defined processing. Even if we are creating only one or two functions and they are closely related to the primary activity of a particular object, if these functions are needed from both inside and outside of the report, the best practice is still to locate those functions in a codeunit. For more guidance, see NAV Design Pattern of the Week - the Hooks Pattern at http://blogs.msdn.com/b/nav/archive/2014/03/16/nav-design-pattern-of-the-week-the-hooks-pattern.aspx.

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 some aspect of Manufacturing or some aspect of Warehouse management). Many of these can be found by filtering the Codeunit Names on the Management and Mgt strings (the same could be said for some of the tables with the string Buffer in their name). When we customize a system, we should create our own function library codeunits to consolidate our customizations and make software maintenance easier. Some developers create their own libraries of favorite special functions and include a function library codeunit in systems on which they work.

If a codeunit is structured very simply and can operate in a standalone 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

Queries are objects whose purpose is to create extracted sets of data from the NAV database and do so very efficiently. NAV 2017 Queries translate directly into T-SQL query statements and run on the SQL Server side rather than on the NAV 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 join (Inner Join, Outer Join, or Cross Join), can filter, can calculate FlowFields (special NAV calculations that 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. The results of a query can also be viewed by pages (as described in Chapter 5, Queries and Reports) and Cues (as described in the Walkthrough: Creating a Cue Based on a Normal Field and a Query documentation section (https://msdn.microsoft.com/en-us/dynamics-nav/walkthrough--creating-a-cue-based-on-a-normal-field-and-a-query)), but are especially powerful when output to charts. With a little creativity, a query can also be used to feed data to a page or report via use of a temporary table to hold the query results.

MenuSuites

MenuSuites are the objects that are displayed in the Navigation Menus. They differ considerably from the other object types we have discussed earlier because they have a completely different structure and they are 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 that are made up of a small set of properties.

In the RTC, the data in the MenuSuites object is presented in the Departments page.

XMLports

XMLports are a tool for importing and exporting data. XMLports handle both XML structured data and other external text data formats. XML (eXtensible Markup Language) is 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 defined XML format to our correspondents. There is a standard set of syntax rules to which XML formats must conform. A lot of 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 have to be commas. The other category is fixed format, in which the length and relative position 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.

 

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

NAV 2017 introduces Windows PowerShell Cmdlets that support backing up data to NAVData files. Complementary Cmdlets support getting information or selectively retrieving data from previously created NAVData files. Although these tools promise to be very handy for repetitive development testing, they are challenging (or worse) to use in an environment of changing table or field definitions.

When objects are exported to text files, we can use a standard text editor to read or even change them. If, for example, we wanted to change all the instances of the Customer field name to Patient, we might export all 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 possibility 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 (or set of changes) 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 in line 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 with forward slashes rather than with curly braces wherever the code is touched, so all the changes can be easily identified by the next developer Although the use of curly braces is permitted by the software, Microsoft warns of potential conflicts with Powershell upgrade processes.

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

 

Review questions


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

a) Manufacturing

b) Order processing

c) Planning

d) Computer Aided Design (CAD)

e) General accounting

  1. New functionality in NAV 2017 includes Choose three:

a) Tablet client

b) Multi-language

c) Document e-mailing

d) Spell checker

e) Mandatory fields

  1. NAV 2017 development is done in the C/SIDE IDE and Visual Studio. True or false?
  2. Match the following table types and descriptions for NAV:

a) Journals Audit trail

b) Ledgers Validation process

c) Register Invoice

d) Document Transaction entries

e) Posting History

  1. iPads can be used with NAV 2017 to display the RTC. True or false?
  2. Which of the following describe NAV 2017? Choose two:

a) Customizable

b) Includes a Storefront module

c) Object-based

d) C# IDE

e) Object-oriented

  1. What are the seven NAV 2017 object types?
  2. All NAV objects except XMLports can contain C/AL code. True or false?
  3. NAV 2017 includes support for publishing objects as web services. True or false?

 

  1. The home page for a NAV 2017 User is called what? Choose one:

a) Role Home

b) Home Center

c) Main Page

d) Role Center

  1. Page previews from the development environment can be used for data entry and maintenance. True or false?
  2. Visual Studio is used in NAV 2017 for what work? Choose one:

a) Report data definition

b) Report layout

c) Role Center design

d) Query processing

  1. Codeunits are the only NAV 2017 objects that can contain functions. True or false?
  2. Query output can be used as a data item for reports. True or false?
  3. C/AL and C/SIDE are required for NAV 2017 development. True or false?
  4. What object number range is available for assignment to customer-specific objects? Choose two:

a) 20 - 500

b) 50,000 - 60,000

c) 150,000 - 200,000

d) 50,000 - 99,999

e) 10,000 - 100,000

  1. XMLports can only process XML formatted data. True or false?
  2. The work date can only be changed by the system administrator. True or false?

 

  1. A design pattern is which of the following? Choose two:

a) Reusable code

b) Stripes and plaid together

c) A proven way to solve a common problem

d) UI guidelines

  1. NAV 2017 reports are often generated automatically through the use of a wizard. True or false?
 

Summary


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

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

About the Authors

  • Mark Brummel

    Mark Brummel started working with Navision in 1997 as an end user. He started working for a Navision solution center in 1999 and witnessed the evolution of the product. In 2006, he received the MVP award from Microsoft and started a journey of close involvement in the product. After the migration to Microsoft Dynamics NAV, the three-tier architecture and role-tailored user interface, he became a trusted consultant, frequently visiting the Microsoft Development Center in Copenhagen and speaking at events. Mark was very closely involved in the early ideas of implementing modern programming concepts that are now known as events and extensions. He is currently senior product specialist at ForNAV and a freelance software architect.

    Browse publications by this author
  • David Studebaker

    David Studebaker has been designing and developing software since 1962 as a developer, consultant, manager, and business owner. In 1967, David coauthored the first general-purpose SPOOL system, an AT&T / IBM joint project. He has been a founding partner in several firms, most recently Studebaker Technology and Liberty Grove Software. David's publications include a decade of technical reviews for ACM Computing Reviews and a number of articles on shop floor data collection. David originated the Packt series of books on programming Dynamics Business Central (aka Dynamics NAV). He 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.

    Browse publications by this author
  • Chris Studebaker

    Chris Studebaker was a certified environmental consultant working with manufacturing facilities to meet national and state regulations before he started working with Navision in 1999. After working on regulatory reporting, data analysis, project management, and subcontractor oversight, Chris has used those skills to sell, develop, and implement NAV for the past 20 years. He has specialized in retail, manufacturing, job shop, and distribution implementations, mostly in high-user-count, high-data-volume applications. Chris acts in a consulting and training role for customers and for peer NAV professionals. He has a Bachelor of Science degree from Northern Illinois University and has done graduate work at Denmark Technical University.

    Browse publications by this author

Latest Reviews

(10 reviews total)
Me gustan mucho los libros publicados.
non ho ancora ricevuto nulla
very good, an excelen book to learn and become in a Developer of MS Dynamics Nav

Recommended For You

Book Title
Access this book, plus 8,000 other titles for FREE
Access now