Programming Microsoft Dynamics NAV 2013 - Third Edition

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:

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:

The Manufacturing section of the Departments menu is as follows:

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:

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:

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:

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.

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:

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:

Let's start with basic definitions of the NAV 2013 object types. They are as follows:

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.

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:

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

The language in which NAV is coded is C/AL (an acronym for Client Application Language). A sample of some C/AL code within the C/AL Editor is shown in the following screenshot:

C/AL syntax has considerable similarity to Pascal. As with any programming language, readability is enhanced by careful programmer attention to structure, logical variable naming, process flow consistent with that of the code in the base product, and good documentation both inside and outside of the code

For several decades, one of the highest goals of software development has been to focus on design before coding and, wherever possible, to accomplish design goals with a minimum amount of code. More than most application software products, Dynamics NAV facilitates that approach. When working on enhancements of NAV, we can spend a majority of our NAV development time determining what to do and what existing capabilities support the task at hand. Then, much of our NAV development work is done by making entries in tables, defining properties of objects ranging from controls to functions to programs, and assembling references to previously defined objects. This approach allows us to minimize the number of lines of code required because we are reusing objects that already exist. As NAV's tools continue to mature, our development work continues to be more heavily weighted in favor of design. Hopefully, the end result is that we are more productive and cost effective on behalf of our customers.

Following are some key terms as used in NAV:

For various application functions, NAV uses terminology that is more akin to accounting than to traditional data processing terminology. Some examples are as follows:

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:

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.

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.

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:

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.

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.

Tip

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.

Tip

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:

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.

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:

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.

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:

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:

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

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.