Modifying the System using Microsoft Dynamics Nav 2009: Part 1

David Roys

August 2009

"The best investment is in the tools of one's own trade." Benjamin Franklin

Understanding the tools

Have you ever held a chainsaw in your hands? Go try it, hear it roar. Quite a beast, eh? Now, what can you do with it? Was felling timber the first image that popped up?

We had something else in mind. Have you ever seen any of those ice sculptures? Did you know that sculptors often use chainsaws to carve them out? Carving them slowly over days with fine tools is often not an option—the ice can start melting in a matter of minutes. To be able to finish in time before physics takes over, power tools must be used, and specially equipped chainsaws have been selected as a tool of choice of many ice carvers.

Modifying a big system, one like Microsoft Dynamics NAV 2009, requires a lot of skill, knowledge, and experience. While skill and experience can't be learned from a book, knowledge for the better part of it can. There are two kinds of knowledge: the knowledge of the tools, and the knowledge of the product.

If you only know the tools, and don't know the object you will work on with these tools, you can easily mess up. If you only know the product, but don't know the tools, you are missing many opportunities. When you know the tools, and what they can do, and how the product will behave when it has been touched, you are on the right path.

If you are an application consultant, and you know the product and how it works, but haven't ever dared to open it up in Object Designer and shape it to your liking, this chapter is for you. You already have the knowledge of the product, what it is and how it works; you only need the knowledge of the tools to become a true artist.

A chainsaw artist, if you wish. The tools you are about to master are quite powerful: they can craft beautifully architectured state-of-the-art solutions, or they can leave a complete mess.

Let's become artists.

Modifications for non-programmers

In Microsoft Dynamics NAV 2009, it is possible to create a fully functioning modification without really writing a single line of code. As a matter of fact, it happens quite often. Often, customers will demand changes that are simple in nature: adding a field to a report, or rearranging the screen elements. You don't need to be a programmer to be able to accomplish that mission.

Microsoft Dynamics NAV comes with a comprehensive set of tools aimed at modifying the solution and every aspect of it, from the data model, via business logic, all the way to the user interface. Many steps along this way can be done without any programming knowledge.

Let's take a look at what can be done without writing code:

  • Extending the data model: Application data is stored in tables, which are specifically designed to store exactly that information which is required by the application, no more, no less. When your customer presents you with new requirements, these will often spawn many changes to the underlying data model, to accommodate all those types of information that weren't originally supposed to be stored, because nobody knew they existed. You can do all of these data model modifications using special data design tools, without writing any code. True, some business logic is usually associated with data, so called business rules, but these should be written much later, after the model has been completed.
  • Modifying the user interface: To put a functional user interface together requires a good understanding of the underlying data model, and of various user interface controls that can be put on screen, what they can do, and what they can't. You can compose hundreds of fully functional data-enabled pages or forms, and establish complex navigation rules between them, without ever coming anywhere close to the C/AL code editor.
  • Reporting: Again, to compose reports mainly requires good knowledge of the underlying data, and the knowledge of tools. While some complex reports may require extensive coding, the vast majority of reports will be prepared by simply laying out fields in the report designer.
  • Data import and export: When data needs to go in and out of the system, you can reach for built-in development tools that can create data migration objects in a matter of minutes.

One of those times when knowing how to shape the system matters, while coding doesn't at all, is prototyping. Imagine how quickly you could get the requirements straight with a customer if you were able to quickly compose a usable user interface prototype!

Object Designer basics

All of the development in Microsoft Dynamics NAV is done through the Object Designer feature of the Classic client.

To invoke the Object Designer from anywhere within the application, simply press Shift+F12, or go to main menu, click Tools, then Object Designer. It looks like the following screenshot:

Microsoft Dynamics NAV 2009

To the left there is a series of buttons, which you can use to switch between the lists of objects of various types:





Microsoft Dynamics NAV 2009

Tables are used to store information in the system.


Microsoft Dynamics NAV 2009

Forms are used to provide access to information by displaying it on screen and allowing data entry and modification. Forms can only be used by Classic client.


Microsoft Dynamics NAV 2009

Reports are primarily used to display information in printable form, but can also be used to execute batch jobs.


Microsoft Dynamics NAV 2009

Dataports are used to export and import information to and from the system in fixed width or variable length text format.


Microsoft Dynamics NAV 2009

Dataports on steroids, XMLports are RoleTailored and can get information into or out of the system in XML and text format. XMLports can also be used to automate communication with external application in a way transparent to the users, such as with Business Notifications functionality.


Microsoft Dynamics NAV 2009

Codeunits contain blocks of application code: the part of the system popularly called business logic.


Microsoft Dynamics NAV 2009

MenuSuites define what the navigation pane in Classic client and the Departments page in the RoleTailored client look like.


Microsoft Dynamics NAV 2009

Pages are the forms of the RoleTailored client: they are used to present the information to users and provide means for data entry using RoleTailored or any other service-tier clients (such as SharePoint client).


On the right, there is a table displaying all the objects of the selected type. The following columns are on show:




This is actually displayed as an icon, which can represent any of the eight object types described in the previous table.


An integer number representing the unique identifier of an object. Every object in the system is uniquely distinguished from every other by its type and ID.


A textual identifier of the object, which has to be unique for each object type. You typically refer to objects by their names when you are declaring C/AL variables.


A localized version of the name, aware of the multi-language capabilities of Microsoft Dynamics NAV.


Tells if the object was modified. Upon saving, every object will automatically get a checkmark in this field.

Version List

A textual list of version tags, explaining which product releases, add-ons, or customizations have changed the object.


Date of the last save operation in Object Designer.


Time of the last save operation in Object Designer.


Size of BLOB representation of the object in the database. The definition, and for all compiled objects an executable version of it, are saved in the database. This makes for a very portable solution, where the database is, so are the application objects.


Flag that tells if the object was compiled, either during the last save operation, or manually by calling the Compile command. Only compiled objects can be executed.

On the bottom right, you have a few basic command buttons: New to create a new object of the selected type, Design to open an existing one, Run to execute the selected object, and Help to answer any questions that we might come across in the process of modifying the system.

Extending the data model

At the heart of every application functionality in Microsoft Dynamics NAV lies the data. Customer or vendor master records, open documents, posted documents, application setup or ledger entries, all these, and many more, exist as data stored in tables.

Every table represents a category of information, such as customers, or items. A row in a table represents a specific instance of such information, such as the customer Spotsmeyer's Furnishings, or the item TOKYO Guest Chair, blue. A row consists of a set of fields, which are attributes that describe every piece of data. Bits of information, such as customer number, or item unit cost, or invoice due date, are stored as fields.

Tables aren't isolated, and usually refer to each other using relationships. For example, the table Sales Header relates to the table Customer through fields Sell-to Customer No. and Bill-to Customer No.. Another table, Sales Line, relates back to table Sales Header through Document Type and Document No. fields. These relationships represent real-life properties: sales lines belong to a sales header, making a sales document, such as an invoice. An invoice is then issued to a customer.

Tables and their relationships make the data model, and the role of the data model is to encapsulate the real-life properties of entities, as well as their natural relationships.

Creating tables

To create a new table, click New in Object Designer, while the Table button is selected. This will bring up the Table Designer.

Creating new objects is almost uniform throughout the application. While the New button is specific to Object Designer, there are other ways you can use to create something new, like pressing F3, or calling New from the Edit menu.

Microsoft Dynamics NAV 2009

Whenever you create a new object, you'll soon want to save it. To save an object, click Ctrl+S or choose Save or Save As... from the File menu. This will bring up the Save As dialog window:

Microsoft Dynamics NAV 2009

Enter the ID and the Name—both are mandatory—and click OK. ID is the object number in Object Designer, and Name is its name—make sure that both values are unique.

Depending on your license, you might be allowed to assign object ID's only in the range 50000 to 99999. Other ranges are reserved.

The Compiled checkbox tells the application whether you want to compile the object during saving. During design time, especially when coding, you might not be able to compile the object because of compile-time errors that will go away by themselves when you finish what you have started. In these cases, the save operation will fail if the Compiled checkbox is switched on.

To avoid these problems, switch the Compile checkbox off until you have finished designing, when you can turn it back on for the final save.

Every object in Microsoft Dynamics NAV contains properties. Every property represents a specific behavior the object can exhibit, and by setting properties we can make objects behave exactly the way we need them to.

The properties of any object in the application can be accessed by pressing Shift+F4, choosing Properties from the View menu, or by clicking the properties icon in the toolbar. Before displaying table properties, you must first place the cursor on the first empty row, or call the Select Object function from the Edit menu.

Many properties are common among application objects, and this is the list of those you will have to set for every object you define:




The unique identifier of the object. This number has to be unique for any object type in the application. Think of this property as of the equivalent of the file name property for files on your disk.


Unique name of the object. This is how the object is referred to in C/AL code and various C/SIDE properties.


Defines the caption that the system will display in the application title bar when the object is run. To take maximum advantage of the multi-language feature of Microsoft Dynamics NAV, you should not define this property manually, but define the CaptionML instead and the system will take care of the Caption automatically.


There are many properties ending in ML. This stands for multi-language, and an ML property always represents the multi-language version of an ML-less one. Therefore, CaptionML represents a multi-language version of Caption.

When editing properties, you'll notice that some of them have < and > around the value, such as <Normal>, <Yes>, or <Undefined>. These indicate the default states of these properties. When you set a property value explicitly, it loses the < and > signs to indicate that the property value has been explicitly assigned. To return back to the default state, select the property value and press Del.

Adding fields

Tables consist of fields, and you need at least one of these. To add fields to a table, while in Table Designer, position the cursor on the first empty line, and type in the name.

For each field you need to define these properties:



Field No.

The field's unique identifier within the table, by which the field is known to the system. Every field must have a Field No. assigned.


The field's unique name within the table, by which the field is known to developers. The Name is how the field is referred to by C/AL code or C/SIDE properties.

Data Type

Determines the type of data stored in this field. When data is entered, the system automatically validates it against the data type, preventing any incompatible data entry (such as typing Twenty into an Integer field).


Specifies the length of text that can be entered in this field. The application will automatically prevent the entry of any information longer than the specified length, both for manual and programmatic entry. This property is available for Text and Code data types.

Get familiar with the field data types and the various properties you can set on them by calling C/SIDE Reference Guide from Help menu.

Table relationships

Tables can relate to each other to represent natural, logical, or real-life relationships. You can express relationships in a technical way, using entity-relationship terms: invoice is of customer; item is of inventory posting group; sales line is of sales header. Or you can do it naturally, using human terms: invoice is issued to customer; item uses inventory posting group, sales line belongs to sales header.

A table is always related to another table through a field. In these examples, invoice is related to customer through the Sell-to Customer No. and Bill-to Customer No. fields; item is related to inventory posting group through the Inventory Posting Group field; sales line is related to sales header through the Document Type and Document No. fields.

In Microsoft Dynamics NAV, relationships are established through the TableRelation field property. To define a relationship, select the TableRelation property and click the Assist button to open the Table Relation editor. This is what it looks like for the Sell-to Customer No. field of table 36 Sales Header:

Microsoft Dynamics NAV 2009

This is a simple relationship between the Sell-to Customer No. field and the primary key field of the Customer table. Relationships can be more complex: you can define conditional relationships, or explicitly declare fields you want to relate to, and you can even specify table filters to be applied during lookups.

We don't define relationships just for the heck of it—they have three important purposes:

  • They enable lookup functionality: When TableRelation is set for a field, whenever you are editing a value for that field, the system will let you pick up one of the possible values by bringing up the lookup form. You can define which form is used as a lookup form for a table by setting its LookupFormID property.
  • They establish data integrity: If you define a TableRelation, then you won't be able to just type any value in that field, because the relationship terms would be broken. You can only enter a value that exists in the related field in the related-to table. The system always takes care that only valid values are written in fields belonging to a relation. You may, however, switch off this mechanism by setting the ValidateTableRelation property to No.
  • They maintain data integrity: If you change a value of a key field in a table, the change will be propagated to all the related tables. For example, if you change the No. for a customer, it will be automatically changed in all tables that are related to the Customer table.

Table keys

As the time goes by, handling increasing amounts of data would be difficult if there were no keys. Keys tell the system where to look for specific information. Tables, fields, and relations typically represent real-life entities, their properties and relationships; keys, on the other hand, stand for a very abstract concept.

There are two kinds of keys: primary and secondary.

Primary keys are used to uniquely identify data rows stored in tables. A record can be uniquely identified by a single field, or a set of fields. (This is called a compound key.) Examples of simple keys are No. in the Customer table, or Code in the Unit of Measure table; an example of compound key is Document Type, Document No. for the Sales Header table.

Secondary keys are used as indexes. An index in a table has the same purpose as an index in a book. Take this book as an example: if you want to see where the word table is used, you'd go to the Index section and see all the pages where word table is mentioned. A handy feature!

Let's now see how keys are defined. Design Table 18 Customer, and call Keys from the View menu. The key editor opens:

Microsoft Dynamics NAV 2009

The first line always contains the primary key. Other lines are secondary keys, which are typically used as indexes that help the database find information faster. To add keys, simply add a new line and type in the fields separated by a comma.

Field groups

Microsoft Dynamics NAV 2009 introduces a new concept: field groups. They have only one purpose: to enable lookup functionality in the RoleTailored client. In the Classic client, to enable lookup functionality, you must configure the LookupFormID property on the table. Every time users want to look up fields from other tables, they must show the whole lookup form, which takes the user's focus away and may even be cluttered with far more information than the user needs to effectively look up a value.

In the RoleTailored client, you don't need to invoke an extra page to look up values from another table: there is drop-down functionality, which shows only those values from another table that are necessary for an effective lookup, while keeping the user's focus on the original table. Something like the following:

Microsoft Dynamics NAV 2009

To define which fields will be shown in the RoleTailored client drop-down menus, call the Field Groups function from the View menu in Table Designer. There is only one field group that has a meaning, and it has to be called DropDown. The fields list, separated by commas, defines which fields will be shown to users in drop-down menus. Any other field groups have absolutely no meaning in this release of Microsoft Dynamics NAV, and while you might add as many field groups as you like, they won't have any effect on the system at all.

Customizing forms

No matter what our data model looks like deep down, and what we have done to it, our users are mostly unaware of any of it. Users never interact with the application directly through tables—for that they use the user interface elements of a client application.

Microsoft Dynamics NAV 2009 comes with two clients: the new one called RoleTailored, which you have already had chance to meet and play with, and the old one called Classic.

When defining the user interface, you must address both of them. Unfortunately, defining user interfaces is a double work: you must define them separately. Forms, the building blocks of the Classic client can't be used in the RoleTailored one, while pages, the building blocks of the RoleTailored interface can't be used in the Classic one.

Creating forms

Lucky for you, creating forms is mostly a trouble-free task: the New Form wizard, a fairly straightforward gadget, which requires very little technical skills, is there to help you kick start. To create a form, click the Forms button in Object Designer, then click the New button, or simply press F3. The wizard is there:

Microsoft Dynamics NAV 2009

The majority of forms are data bound, which means they display information from a table. A form can only be bound to a single table, and you can choose which one by filling out the Table field in the New Form dialog. You can choose to continue with a blank form, or to use one of the two wizards: the Card-Type Form Wizard or the List-Type Form Wizard.

The New Form wizard helps you create forms of the two most common types: cards and lists. The wizard will help you choose which fields to display on the form, and choose their arrangement and layout.

After the wizard completes its job, your newly designed form is displayed in the Form Designer, where most of the design work for forms is done. A typical result of a Card-Type Form wizard is as follows:

Microsoft Dynamics NAV 2009

Form properties

It's a good time to inspect and get to know the most useful form properties. Most of them have been set by the wizard, but sometimes you'll just get to set them manually:



Width and Height

Define how wide and tall the form will be when displayed in non-maximized state.


Specifies whether controls in the form can be edited. When set to No, none of the controls in the form can be edited.

InsertAllowed, ModifyAllowed, and DeleteAllowed

By default, all data-bound forms allow all types of operations. If you want to prevent users from inserting, modifying, or deleting records in this form, set these properties to their desired state. Set these properties only when absolutely necessary, such as for setup forms that must allow modifications but not insertions or deletions.


A form in lookup mode displays OK and Cancel buttons, and closes when users press either of these; while in non-lookup mode these buttons are automatically hidden. Lookup mode is normally controlled by the application, and a form automatically enters the lookup mode whenever users open the form by looking up a field from another table by pressing F6 or clicking the lookup button.

By setting this property to Yes you can put a form explicitly into the lookup mode.


Specifies the underlying table upon which field controls in the form will be based.


Specifies the default sorting and filter state of the form. Here you can explicitly declare a filter that can't be overridden by users, for example if you only want to see active customers, or documents of a certain type.

There are many more properties, but they aren't so frequently used and you'll learn them gradually as you continue to work with the application.

Adding controls

A jolly bunch of controls was added to the form when you completed the wizard, but you can add many more as you go. To add more controls to the form, you have two choices: adding fields or adding controls.

When you add a field, it is automatically converted to either a Text Box or a Check Box, depending on the field's data type, and it is automatically bound to the field. On the other hand, controls may, or may not be bound, and there is a broader choice of controls to choose from.

To add fields, select Field Menu from the View menu. The Field Menu is opened, and you can select the fields you want added to the form. When you are ready to add those fields, simply move your mouse pointer above the desired position in the form, and when the mouse pointer changes to a rectangle with a small cross at the upper left, double-click on the form. This will add the fields and their captions, and set their properties, all in one go. This is how it works:

Microsoft Dynamics NAV 2009

If you want to do this manually, or you want to add other controls such as buttons, progress bars, or subforms, display the Toolbox window by choosing Toolbox from the View menu. A small floating window will open with different icons representing different types of controls you can add.

Adding controls is as simple as adding fields; you simply select the desired control, position your mouse pointer above the desired target position, and click. These are the types of controls you can add:





Microsoft Dynamics NAV 2009

Label-displays a static, multi-language enabled text defined by its Caption and CaptionML properties.


Microsoft Dynamics NAV 2009

Text box-this must be bound to a source using the SourceExpr property. It can be bound to any of the following sources: a field in a table, a variable, a constant value, a Text Constant, or a valid C/AL expression. If the source is a variable or an editable field in a table, the control is editable; in any other case it is read-only.


Microsoft Dynamics NAV 2009

Check box-a small square box, which can be in two states: checked or unchecked. Similar to a text box, it must be bound to a source using the SourceExpr property, with one condition: the source must be of or evaluate to Boolean data type.


Microsoft Dynamics NAV 2009

Option button-a small round button, which can be in two states: checked or unchecked. It must be bound to a source using the SourceExpr property. The source of the Option button must be of or evaluate to Boolean or Option data type. You will typically have more than one Option button linked to the same source, and set their OptionValue properties to different values, representing different options users can select from.


Microsoft Dynamics NAV 2009

Command button-a plain button, which displays a static, multi-language enabled text defined by its Caption and CaptionML properties.


Microsoft Dynamics NAV 2009

Menu button-a button that displays a static, multi-language enabled text defined by its Caption and CaptionML properties and opens a menu when clicked.


Microsoft Dynamics NAV 2009

Frame-a control which is used as a container of other controls: and any controls placed inside a frame are moved together with the frame. A frame can display a caption in its top-left corner


Microsoft Dynamics NAV 2009

Image-displays a static image, defined by its Bitmap property. This property can be set to a numeric value (a variety of documented and undocumented numeric values can display any of the built-in application icons), or to a file path. If you specify a path, it must point to a BMP file, and the image is embedded into the form at compile time.


Let's take a look at some commonly used non-basic controls.


Imagine a form within a form. What is it good for? Well, hardly anything if you imagined a card form within another card form. But if you imagined a list form within a card form, uses are plenty: sales invoices or production orders with their lines, bills of materials with their components, sales statistics with breakdown per territory; you name it. This is achieved using the Subform control. Run form 42 Sales Order to get a gist of what a card form with a Subform looks like.

To configure a subform control to display another form, you need to set some properties:




Specifies the ID of the form that will be displayed as subform.


Specifies how the subform is linked to the main form. Subforms are used to represent parent-child or master-detail relationships between data in two tables, with a header displaying master information, and lines displaying details. This property is used to specify the master-detail relationship.

Menus and buttons

Other types of controls that you will usually want to include on your forms are menus and buttons. They are used to invoke other features, such as posting procedures, reports, or other forms.

Two controls are particularly useful for this: Button and MenuButton. A button can execute a single action, something like the Make Order button on the Sales Quote form. A menu button isn't linked to an action directly, but when clicked, it displays a menu of actions that we can then execute by clicking on them. For a feel of a typical menu button, take a look at Functions, also on the Sales Quote form.

Now that we've mastered the rocket science behind, let's see which properties we need to set to define actions:




Type of action that can happen when users push the button. <0> indicates that no action will be taken; OK, Cancel, LookupOK, LookupCancel, Yes, No, Close, and Stop will all close the form with proper status returned to the caller; FormHelp will launch the online help for the form; RunObject will execute an object; RunSystem will execute an external application; and LookupTable will launch the default lookup form for the underlying source table.


Specifies the type and ID of the object that will be executed when the button is pushed. PushAction must be RunObject.


Specifies any sort order or filters applied to the executed form. PushAction must be RunObject and RunObject must specify a form.


Specifies the link established between the caller form and the executed form. When two forms are linked using this property, the called form can update its contents when record selection is changed in the caller from. You can think of this as showing a subform in an external window.


Specifies whether the link specified in RunFormLink is an active one, or a one-time link. An active link, specified by the OnUpdate value, will cause the called form to update its content based on the link every time the record is changed in the caller form. A one-time link, specified by OnOpen, will simply display the called form, with the link in place, but will not update the called form when the record in the caller form changes.

For menu buttons, you must first define menu items. To do so, right-click the menu button and choose Menu Items, or choose the same command from the View menu. For each menu item you must at least define its Caption, and you can use other properties to define specific actions that will execute when a menu item is selected from the menu.

Menu items share the majority of their properties with command buttons, and all of the properties discussed in the table above apply to menu items of menu buttons as much as they do to command buttons.

>> Continue Reading Modifying the System using Microsoft Dynamics Nav 2009: Part 2


[ 1 | 2 | 3 ]

You've been reading an excerpt of:

Implementing Microsoft Dynamics NAV 2009

Explore Title