Microsoft Dynamics NAV 2009 Development Tools

(For more resources on Microsoft Dynamics, see here.)

NAV process flow

Primary data such as sales orders, purchase orders, production orders, financial transactions, job transactions, and so on flow through the NAV system as follows:

  • Initial Setup: Entry of essential Master data, reference data, control and setup data. Much of this preparation is done when the system (or a new application) is first set up for production use.
  • Transaction Entry: Transactions are entered into a Journal table; data is preliminarily validated as it is entered, master and auxiliary data tables are referenced as appropriate. Entry can be manual keying, an automated transaction generation process, or an import function which brings transaction data in from another system.
  • Validate: Provide for additional test validations of data prior to submitting the batch to Posting.
  • Post: Post the Journal Batch, completing transaction data validation, adding entries as appropriate to one or more Ledgers, including perhaps a register and a document history.
  • Utilize: Access the data via Forms and/or Reports of various types as appropriate. At this point, total flexibility exists. Whatever tools are available and are appropriate for users' needs should be used. There are some very good tools built into NAV for data manipulation, extraction, and presentation. In the past, these capabilities were considered good enough to be widely accepted as full Online Analytical Processing (OLAP) tools.
  • Maintenance: Continue maintenance of Master data, reference data, and setup and control data, as appropriate. The loop returns to the beginning of this data flow sequence.

Microsoft Dynamics NAV 2009 Development Tools

The preceding image provides a simplified picture of the flow of application data through a NAV system. Many of the transactions types have additional reporting, more ledgers to update, or even auxiliary processing. However, this is the basic data flow followed whenever a Journal and Ledger table are involved.

Data preparation

Prepare all the Master data, reference data, and control and setup data. Much of this preparation is done initially, when an application is first set up for production usage.

Naturally, this data must be maintained as new Master data becomes available, as various system operating parameters change, and so on. The standard approach for NAV data entry allows records to be entered that have just enough information to define the primary key fields, but not necessarily enough to support processing. This allows a great deal of flexibility in the timing and responsibility for entry and completeness of new data.

This system design philosophy allows initial and incomplete data entry by one person, with validation and completion to be handled later by someone else. For example, a sales person might initialize a new customer entry with name, address, and phone number, saving the entry with just the data entered to which they have access. At this point, there is not enough information recorded to process orders for this new customer.

At a later time, someone in the accounting department can set up posting groups, payment terms, and other control data that should not be controlled by the sales department. This additional data may make the new customer record ready for production use. As in many instances data comes into an organization on a piecemeal basis, the NAV approach allows the system to be updated on an equally piecemeal basis providing a flexible user friendliness many accounting-oriented systems lack.

Transactions entry

Transactions are entered into a Journal table; data is preliminarily validated as it is entered, master and auxiliary data tables are referenced as appropriate.

NAV uses a relational database design approach that could be referred to as a "rational normalization". NAV resists being constrained by the concept of a normalized data structure, where any data element appears only once. The NAV data structure is normalized so long as that principle doesn't get in the way of processing speed. Where processing speed or ease of use for the user is improved by duplicating data across tables, NAV does so.

At the point where Journal transactions are entered, a considerable amount of data validation takes place. Most, if not all, of the validation that can be done is done when a Journal entry is made. These validations are based on the combination of the individual transaction data plus the related Master records and associated reference tables (for example lookups, application or system setup parameters, and so on). Here also you find the philosophy of allowing entries, which are incomplete and not totally ready for processing, to be made.

Testing and Posting the Journal batch

Any additional validations that need to be done to ensure the integrity and completeness of the transaction data prior to being Posted are done either in pre-Post routines or directly in the course of the Posting processes. The actual Posting of the Journal batch occurs when the transaction data has been completely validated. Depending on the specific application function, when Journal transactions don't pass muster during this final validation stage, either the individual transaction is bypassed while acceptable transactions are Posted, or the entire Journal Batch is rejected until the identified problem is resolved.

The Posting process adds entries as appropriate to one or more Ledgers and sometimes a document history. When a Journal Entry is Posted to a Ledger, it becomes a part of the permanent accounting record. Most data cannot be changed or deleted once it is resident in a Ledger except by a subsequent Posting process.

During the Posting process, Register tables are also updated showing what transaction entries (by ID number) were posted when and in what batches. This adds to the transparency of the NAV application system for audits and analysis.

In general, NAV follows the standard accounting practice of requiring Ledger corrections to be made by Posting reversing entries, rather than deletion of problem entries. The overall result is that NAV is a very auditable system, a key requirement for a variety of government, legal, and certification requirements for information systems.

Accessing the data

The data in a NAV system can be accessed via Pages and/or Reports of various types as appropriate, providing total flexibility. Whatever tools are available to the developer or the user, and are appropriate, should be used. There are some very good tools in NAV for data manipulation, extraction, and presentation. Among other things, these include the SIFT/Flowfield functionality, the pervasive filtering capability (including the ability to apply filters to subordinate data structures), and the Navigate function. NAV 2009 added the ability to create page parts for graphing,with a wide variety of predefined graph page parts included as part of the standard distribution. You can create your own chart parts as well, but that discussion is outside the scope of this book. There is an extended discussion and some tools available in the NAV Blog community.

There are a number of methods by which data can be pushed or pulled from an NAV database for processing and presentation outside NAV. These allow use of more sophisticated graphical displays, or the use of other specialized data analysis tools such as Microsoft Excel or various Business Intelligence (BI) tools.

Ongoing maintenance

As with any database-oriented application software, ongoing maintenance of Master data, reference data, and setup and control data is required, as appropriate. Of course at this point, the cycle of processing returns to the first step of the data flow sequence, Data Preparation.

Read more about this book

(For more resources on Microsoft Dynamics, see here.)

Role Center pages

One of the key additions to Dynamics NAV in the NAV 2009 version is the concept of a Role Tailored user experience centered around user function defined Role Centers. The intent of the Role Tailored approach is to provide a single point of access into the system for each user. That point of access (the Role Center) focuses on the tasks that define users' jobs throughout the day, while providing easy access to other permitted functions only a click or two away.

Included in the NAV system as distributed by Microsoft are 21 different Role Center pages, identified for user roles such as Bookkeeper, Sales Manager, Shop Supervisor, Purchasing Agent, and so on. One of the critical tasks of implementing a new system will be to analyze the work flow and responsibilities of the system's intended users and configure Role Centers to fit the users.

In many cases, the supplied Role Centers can be used out of the box or with minimal configuration. On occasion, it will be necessary for you to create new Role Centers. Even then, most of the time, you will be able to begin your job with a copy of an existing Role Center Page, which you will then modify as required. In any of these cases, it is important to understand the structure of the Role Center Page and how it is built.

Role Center structure

The following screenshot shows the Small Business Owner RC (aka President – Small Business) Role Center Page (Page 9020) with labels identifying the various pieces we deal with as developers.

(Move the mouse over the image to enlarge.)

A general representation of the structure of a Role Center Page is shown in the following outline:

Microsoft Dynamics NAV 2009 Development Tools

In order to understand the construction of a Role Center Page, we will dissect Page 9020, Small Business Owner RC. Our goal will be to understand what the component parts are and how they fit together. We want to be prepared to either modify an existing Role Center or create a new one by through either "clone and modify" or building from scratch. Our first step is to find Page 9020 in the Page section of the Object Designer and design the page to see the following screenshot:

There is a Container control of SubType RoleCenterArea. This is required for a Role Center page. There are two Group Controls which represent the two columns (left and right) of the Role Center page display. Each group contains several parts, each of which shows up individually in the Role Center display.

Let's take a look at the properties for the Role Center page. We access the page Properties by highlighting the first blank line on the Page Designer form (that is the line below all of the defined controls), then click on the Properties icon, or right-click and choose the Properties option, or, click on View | Properties or press Shift + F4. The Properties for the Role Center page, in this case the Small Business Owner Role Center, will be displayed as shown in the following screenshot. The only things different at this level from a Card page is that the PageType is RoleCenter, and there is no Source Table.

Microsoft Dynamics NAV 2009 Development Tools

Role Center activities page

As the Group Control has no underlying code or settings to consider, the first Control to examine is the first Part Control. Examining the Properties for that Control, we see the information shown in the following screenshot. The PagePartId refers to the Page object Small Business Owner Act.

Microsoft Dynamics NAV 2009 Development Tools

Cue Groups and Cues

If we shift our focus to the referenced page: Page 9073 – Small Business Owner Act, and design the page, we see the layout shown in the following screenshot. Comparing the controls we see in that layout to those of the Role Center screenshot, we can clearly see this Page Part is the source of the material in the Role Activities section of the Role Center Page. There are four CueGroup Controls—Sales, Purchase, Receivables and Payables. Within each CueGroup, there are the Field Controls for the individual Cues.

An individual Cue is displayed as an iconic shortcut to a filtered list. The size of the stack of papers in the Cue icon represents the number of records in that list. The actual number of entries is also displayed as part of the icon (see the Released Purchase Orders example in following screenshot). The purpose of a Cue is to provide a focus on and easy access to a specific user task. The set of Cues is intended to represent the full set of primary activities for a user, their Role.

Microsoft Dynamics NAV 2009 Development Tools

Cue source table

When we take a look at the Properties of the Small Business Owner Act. Page (see the following screenshot), we see this is a PageType of CardPart tied to SourceTable SB Owner Cue:

Microsoft Dynamics NAV 2009 Development Tools

Following the designated path, we Design the referenced table, SB Owner Cue. What we see there (see the following screenshot) is a simply structured table, with an integer field for each of the Cues that were displayed in the Role Center we are analyzing. There is also a key field and two fields identified as Date Filters:

Microsoft Dynamics NAV 2009 Development Tools

When we display the properties of one of these integer fields, the field named Released Sales Quotes, we find it is a FlowField providing a Count of the Sales Quotes with a Status equal to Released. In fact, if we inspect each of the other integer fields in this table, we will find a similar FlowField setup. Each is defined to fit the specific Cue to which it's tied. It is obvious, thinking about what the Cues show and how FlowFields work, that this is a fairly simple, direct method of providing the information necessary to support Cue displays.

As a confirmation of our analysis, we can Run the SB Owner Cue table to view the data there. There is one record with the Integer FlowFields we saw in Design mode. The Counts that are displayed match those that are shown in the Role Center display. As this table is designed to contain only a single record, the key field is blank. And, in addition to the FlowFields, there are also a couple of FlowFilter fields used in the definition of the date based FlowFields.

There is very little C/AL code underlying all of these Role Center components. One exception is a small amount of code—the first time the Role Center is displayed, the supporting data record will be initialized. That simple code is shown in the following screenshot. There is also occasional filter setting code in some page parts, most of it associated with the WORKDATE or the USERID.

Microsoft Dynamics NAV 2009 Development Tools

At this point, we step back to look at the bigger picture of Role Center support objects. The following screenshot shows the list of tables that serve the same purpose as Table 9060 - SB Owner Cue. Each of these Cue tables contains a series of FlowFields that support the Cues in the associated Role Center. As there are 21 Role Centers defined in the standard product distribution and fewer than 21 Cue tables, obviously, some of the Role Centers rely on the same Cue tables (in other words, some Cue sets appear on more than one Role Center page).

Microsoft Dynamics NAV 2009 Development Tools

Cue Group Actions

Another set of Role Center page components that we need to analyze are the Cue Group Actions. While the Cues are the primary tasks that are presented to the user, the Cue Group Actions are a related secondary set of tasks. Cue Group Actions are defined in the Role Center in essentially the same way as Actions are defined in other page types.

As the name implies, Cue Group Actions are associated with a Control with the SubType CueGroup. If you right click on the CueGroup Control, one of the options available is Actions (as shown in the following screenshot):

When you choose Actions, the Action Designer form is displayed. In this case, it shows the two CueGroup actions that are defined and which display for the Sales CueGroup in the Role Center page that we are analyzing. The Action Designer form is where we define the actions that we want available for a particular CueGroup in the Role Center.

System Part

Now that we have thoroughly covered the components of the Role Activities portion of the Role Center page, let's take a look at the other components.

Returning to Page 9020 in the Page Designer, we examine the Properties of the next Part Control. Looking at this control's properties, we can see that this has a PartType of System and a SystemPartID of Outlook. That makes it easy to see that this Page Part is the one that incorporates a formatted display of the users' Outlook data into the Role Center.

Microsoft Dynamics NAV 2009 Development Tools

Page Part

Look at the Properties of the first Control in the second group, as shown in the following screenshot. In this case, the PartType is Page and the PagePartID is MyCustomers, which is Page 9150. This is obviously tied to the My Customers part of the Role Center page.

Microsoft Dynamics NAV 2009 Development Tools

Looking at Page 9150 in the Page Designer, and specifically at the Page Properties of that page, we see what is shown in the following screenshot. The page has a PageType of ListPart and a SourceTable of My Customer.

The My Customer source table is about as simple as a table can be (see the following Table Designer screenshot). It contains only the ID of the User who "owns" the customer along with the Customer No. As the key to this table is the combination of the two fields, any customer can be associated with any number of users, in other words several users could be watching over a particularly important customer.

There is a small amount of C/AL code in Page 9150 to support the filtering and reading of the data. In the OnOpenPage trigger, there is a SETRANGE function call to filter the customer records to be displayed. There is also a small amount of code to load data.

Microsoft Dynamics NAV 2009 Development Tools

Inspecting the next two controls in Page 9020 (the Role Center page), we see two more very similar constructs—one for My Vendors and one for My Items. Continuing on to the last Control in Page 9020, we see another PartType of System, in this case one for the SystemPartID of MyNotes.

Microsoft Dynamics NAV 2009 Development Tools

Read more about this book

(For more resources on Microsoft Dynamics, see here.)

Navigation Pane and Action Menus

The last major component of the Role Center Page is the Navigation Pane plus the Action Menus. While on-screen there are four identifiable sections of the Role Center Page that provide lists of actions, that is menus, all the four are defined in the same area of the Page Designer—the Action Designer.

We will examine the four sections for Actions from right to left, top down, across the Role Center Page. The first two, Reports and Actions, are in the Command bar area.

The following two screenshots are the visible Reports action menu and the underlying controls for that menu, displayed in the Action Designer.

Microsoft Dynamics NAV 2009 Development Tools

It is easy to compare the menu items in the page screenshot to the Captions in the Action Designer screenshot and see that these are different looks at the same material (outside look versus inside look). The Action Designer screenshot also shows the options that are available in the Action Designer lines. In this example, we're looking at instances of Reports, ActionItems, HomeItems, and ActivityButtons.

The Action Designer is accessed from the Page Designer form by focusing on the first blank line below the controls, then clicking on View, and selecting Actions.

The specific action for each line is defined in the properties for that line (see the following screenshot for the properties of the first Action line in the Reports action menu):

Microsoft Dynamics NAV 2009 Development Tools

There is also a trigger for each action line, but this is misleading, because no code is allowed in action triggers in Role Center pages.

The following screenshot is of the external view of the active Role Center Actions menu:

Microsoft Dynamics NAV 2009 Development Tools

The following screenshot shows the Action Designer contents for the same Role Center Actions menu. It is easy to compare the menu item descriptions in the page screenshot of the Actions menu to the Captions you see in the Action Designer.

Turning our attention to the Navigation Pane, it has two main areas. The first area, at the top, is the Home button where the HomeItems are displayed. The comparative screenshots for the Home area action items follow.

The next screenshot is the user view:

Microsoft Dynamics NAV 2009 Development Tools

Following is the developer view:

If you are doing development work on a Role Center, you can run the Role Center as a page from the C/SIDE Object Designer in the same way as other pages. However, the Role Center page will launch as a task page on top of whatever Role Center is configured for the active user. The Navigation Pane of the Role Center being modified will not be active and can't be tested with this approach. In order to test all of the aspects of the Role Center page, you must launch it as the assigned Role Center for the active user.

When you click on the small triangle to the left of the Home actions, the sub-home action items are displayed (see the following screenshot). These may come from items that were defined in the Action Designer form, or from an automatic merge of the items in the Cue Groups of the associated Role Center Page. In this screenshot, the child action items displayed are all automatically merged Cues, thus providing access to the associated lists either from the Cues or from the Home section of the Role Center Navigation Pane.

Microsoft Dynamics NAV 2009 Development Tools


In the Navigation Pane, there are always at least two Activity buttons—Home and Departments. The links and pages available via the Departments Activity button are dependent on the MenuSuite. MenuSuites automatically adapt to show only the functions currently enabled by the active license and the user's permissions. Let's take a look at how the MenuSuite is constructed and how MenuSuite maintenance is accomplished.

MenuSuite levels

There are 15 levels of menu objects. They go from level 1 to 15, 1 being a "lower" level than level 2, and so on. The set of menus that is displayed is built up by first using the lowest level, then amending that by applying the next higher level, and so forth until all of the defined levels have been applied. Wherever a higher level redefines a lower level, the higher level definition is king.

The available menu levels are MBS, Region, Country, Add-on 1 through Add-on 10, Partner, and Company. The lowest level that can be modified in Design mode without a special license is the Partner Level (you can open lower levels, but you cannot save changes). The lower levels are reserved to the NAV corporate developers and the ISVs who create add-ons. The following screenshot shows a menu suite with the original Microsoft master MenuSuite object (the MBS level), a regional localization object (Region), and then the entries created from those two entries for the Departments button by MenuSuite transformation:

Microsoft Dynamics NAV 2009 Development Tools

MenuSuite structure

The menu that you see when you enter NAV is a roll-up of the contents of all of the menu objects, filtered based on your license and your assigned permissions. Each level has the ability to override the lower levels for any entry with the same GUID number.

Globally Unique Identifier (GUID) numbers are unique numbers which can be used for the identification of database objects, data records, and so on. The value of each GUID is generated by a Microsoft developed algorithm. The standard GUID representation is {12345678-1234-1234-1234-1234567890AB}.

A changed menu entry description is a second, higher level entry overriding the lower level entry. The lower level entry isn't really changed. A deleted lower level entry is not really deleted. Its display is blocked by the existence of a higher level entry indicating the effective deletion.

Changes that are made to one MenuSuite object level are stored as the differences between the effective result and the entries in the lower level objects. On the whole, this doesn't really make any difference in how you maintain entries, but if you export menu objects to text and study them, it may help explain some of what you see there and what happens when changes are made to MenuSuite entries.

MenuSuite development

Developer access to the MenuSuite for modification is through Tools | Object Designer | MenuSuite in a fashion essentially similar to accessing other NAV objects for development purposes.

Microsoft Dynamics NAV 2009 Development Tools

Exiting the MenuSuite Designer is done by executing a right-click on the open MenuSuite object heading. You will see the Close Navigation Pane Designer option as shown in the following screenshot (Navigation Pane Designer is an alternate name for the MenuSuite Designer). Click on that option to close the Designer. You will have the usual opportunity to respond to Do you want to save the changes…

Microsoft Dynamics NAV 2009 Development Tools

Once you have opened the MenuSuite Designer at the desired level (typically Partner or Company), your next step is to create menu modifications. As mentioned earlier in this book, the development tools for MenuSuites are quite different from those of other NAV objects. In order to access the development options for a MenuSuite, highlight an item (for example, a menu or menu entry) while in the MenuSuite Designer, and right-click. If you highlight a menu, you will see the display shown in the following screenshot:

Microsoft Dynamics NAV 2009 Development Tools

If you select the Create Menu option, you will see the form in the following screenshot. This allows you to create a new Menu (for example, a set of Actions). For example, you might want to create a new menu which allows access only to a limited set of inquiry pages:

Microsoft Dynamics NAV 2009 Development Tools

In this form, you can enter whatever you want the new menu's caption to be, as well as choose a bitmap to be displayed as the icon at the left of the caption string, when the MenuSuite is displayed in the Classic client.

If you highlight a menu entry and right-click, you will see the option list shown in the following screenshot:

Microsoft Dynamics NAV 2009 Development Tools

The options shown on this menu are the total set of options available for a MenuSuite item. The first set of options allow you to create, delete, or rename items. The Move Up and Down are the principal positioning tools. If you click on Properties for a MenuSuite entry, you will see a display like that in the following screenshot:

Microsoft Dynamics NAV 2009 Development Tools

The only object types allowed are Table, Form (which the RTC interprets as Page), Report, Dataport (which the RTC interprets as XMLport), and Codeunit. Once you have chosen an object type, you can specify the particular object of that type to be executed and what the captions are to be. And that's all that you can do in a MenuSuite as a developer.

If you are creating a new menu which will contain items that exist in other menus, you can populate it very quickly and easily. First, you create the new menu, and then just copy and paste desired menu items from other menus.

There is no allowance for any type of embedded C/AL code in a MenuSuite item to handle control, filtering, special validation, or other logic. You cannot invoke a specific function within an object. If you want to include any such customized capability, you must put that logic in an object such as a processing only report dedicated to handle the control task. Your MenuSuite item can then execute that control object which will apply your enhanced control logic, and will then invoke another object.

MenuSuite transformation

After you have made modifications to the MenuSuite, you must massage it through a process called transformation in order to convert the MenuSuite to Departments button Actions. The Transformation process is described in detail in the C/SIDE Reference Guide Help in "Transforming MenuSuite Objects" and "How to: Transform MenuSuite Objects". You may also want to refer to "How to: Create and Modify a MenuSuite Object".

It would be a good idea to experiment with adding new MenuSuite entries, changing or deleting existing entries, and reorganizing MenuSuite entries. View the results in the Classic Client, then transform the MenuSuite and view the results in the Role Tailored Client. Only through this process of hands-on experimentation will you gain a good understanding of how various changes will affect the Navigation Pane Departments Actions appearance.

Configuration and personalization

At this point, we have covered most of the development based aspects of creating or maintaining a Role Center. In NAV 2009, once a Role Center has been defined, the implementer or a super user can configure the Role Center. Configuring the Role Center means defining which of the components that the Developer included will actually be presented and, in many cases, how they will be laid out on the screen. A Configured Role Center applies to all users assigned to that Role Center.

The configuration can only be changed by someone identified as the Owner of the Role Center and only when the Role Center in opened in Configuration mode. One Role Center is identified as the Default. The default Role Center will be used whenever a user logs into the system that has not been specifically assigned to another Role Center. The C/SIDE Help provides good information on configuring a Role Center. The Dynamics NAV Help accessible from the Role Tailored Client for Customizing Pages provides good information for a user to tailor their pages (terminology check: tailor=personalize=customize, the term may vary).

The Developer creates the overall boundaries of the Role Center toolset, but ultimately each user decides what parts of that toolset fits their needs best. Once the Developer has defined a full set of tools for a Role, the Implementer or System Administrator chooses a subset and arrangement for a site-specific Configuration. Then each user can further subset and arrange the Role Center page layout to suit their personal needs, re-choosing and rearranging at will.

The following screenshot of the Profile List (accessible via Departments | Administration | Application Setup | Role Tailored Client | Lists) shows a Role Center with the Owner identified and another Role Center set as the default Role Center:


In this article we reviewed some of most important elements of the Role Tailored User Experience, in particular Role Center Page construction.


In the next article, Code Analysis and Debugging Tools in Microsoft Dynamics NAV 2009, we will take a look at the code analysis and debugging techniques.

Further resources on this subject:

You've been reading an excerpt of:

Programming Microsoft Dynamics NAV 2009

Explore Title