An introduction to NAV development
As part of our study of NAV development tools and techniques, we are going to do some exercises here and there. There’s no better way to learn than to try out the tools in an environment where you can’t break anything important. We’re going to do development work for a simple system. As discussed earlier, we will access C/SIDE through the Tools Object Designer| menu option, as shown in the following screenshot:
Our scenario for development exercises
Our organization is a small, not-for-profit one. The name is ICAN, which stands for International Community And Neighbors. We collect materials, mostly food, from those who can afford to share and distribute it to those who have difficulty providing for themselves or their families. A large company has supplied us with a small computer network and a three-user Microsoft Dynamics NAV 2009 system.
We need to track the donations which come in. They may be items, money, or some type of in-kind services. If they are items, we will need to inventory them. We also need to track donors, volunteers, and the people on our “help list” (our clients). A variety of reports and inquiries will be needed. As with any application, new requirements are likely to arise as time goes by. And, in this case, since the purpose of our scenario is to act as a laboratory for experimenting with NAV development tasks, new requirements will arise so that we can do additional experiments.
Getting started with application design
Our design for the ICAN application will start with the initial design of a Donor table, a Donor Card Page, a Donor List Page, and a Donor List Report. Along the way, we will review the basics of each of these NAV object types.
Application tables
Table objects are the foundation of every NAV application. Every project should start by designing the tables. Tables contain the definitions of the data structures, the data relationships within and between the tables, as well as many of the data constraints and validations.
The coded logic in a table triggers not only provides the basic control for the insertion, modification, and deletion of records, but also embodies many of the business rules for an application. Such logic isn’t just at the record level but also at the field level. When we embed a large part of the application data handling logic within the tables, it makes the application easier to develop, debug, support, modify, and upgrade.
Designing a simple table
Let’s create a simple Donor table for our NAV Donor application. First, we will inspect existing definitions for tables containing name and address information. Basic inspection is done by clicking on the Tables button in the Object Designer, then highlighting the desired table and clicking the Design button. Good examples are the Customer table (table object 18) and the Vendor table (table object 23).
We see some field name and definition patterns that we will generally copy on the basis of “consistency is good”. One exception to the copying will be the Primary Key field. In the other tables, that field is No., but we will use Donor ID, just to make all our examples stand out from views of standard code.
The Donor table will contain the following data fields:
Field names
Definitions
Donor ID
20 character text (code)
Name
50 character text
Address
50 character text
Address 2
50 character text
City
30 character text
State/Provinc
10 character text
Post code
20 character text (code)
Country/Region code
10 character text (code)
In the preceding data field list, three of the fields are defined as Code fields, rather than Text fields. This is because these will be referenced by or will reference to other data tables. Using Code fields limits the contents to a subset of the ASCII character set, making it easier to constrain entries to a range of values.
The Donor ID will be a unique identifier for our Donor record as it will also be referenced by other subordinate tables. The Post Code and Country/Region Code will reference other existing tables for validation. We choose the name, size, and data definition of these last two fields based on inspecting the equivalent field definitions in the Customer and Vendor tables.
We will have to design and define any referenced validation tables before we can eventually complete the definition of the Donor table. But our goal at the moment is just to get started.
Creating a simple table
Open the Object Designer, click on Table (in the left column of buttons) and click on New (in the bottom row of buttons). Enter the first field name (Donor ID) in the Field Name column and then enter the data type in the Data Type column. For those data types where length is appropriate, enter the maximum length in the Length column (for example text fields require lengths, date or numeric fields do not). Enter Description data as desired; these are only for display here as internal documentation.
As you can see in the following screenshot (and will have noticed already if you are following along in your system), when you enter a Text data type, the field length will default to 30 characters. This is simply an ‘ease-of-use’ default, which you should override as appropriate for your design. The 30 character Text default and 10 character Code default are used because this matches many standard application data fields of those data types.
Field numbering
The question often arises as to what field numbering scheme to use. Various systems follow a variety of standard practices, but in NAV, when you are creating a new table from scratch, it is a good idea to increment the Field No. by 10, as you can see in the preceding screenshot. The default increment for Field No. is 1. For a group of fields (such as an address block) where you are certain you will never add any intervening fields, you could leave the increment at 1, but there is no cost for using the larger increment.
The numeric sequence of fields determines the default sequence in which data fields will display in a wide variety of situations, especially in the Classic Client. An example would be the order of the fields in any list presented to the user for setting up data filters in the Classic Client. This default sequence can only be changed by renumbering the fields. The compiler references each field by its Field No. not by its Field Name, so the renumbering of fields can be difficult once you have created other routines that reference back to these fields. At that point, it is generally better to simply add new fields where you can fit them without any renumbering.
General rule: Once a design has started to mature, don’t renumber data fields.
In fact, it can be irritatingly painful to renumber fields at any point after a table has been defined and saved. In addition to the field numbers controlling the sequence of presentation of fields, the field numbers control bulk data transfer (those transfers that operate at the record level rather than explicitly field to field transfer—for example the TRANSFERFIELD instruction). In a record-level transfer, data is transferred from each field in the source record to the field of the same number in the target record.
Obviously, it’s a good idea to define an overall standard for field numbering as you start. Doing so makes it easier to plan your field numbering scheme for each table. Your design will be clearer for you and your user, if you are methodical about your design planning before you begin writing code (try to avoid the Ready-Fire-Aim school of system development). The increment of Field No. by 10 allows you to insert new fields in their logical sequence as the design matures. While it is not required to have the data fields appear in any particular order, it is frequently convenient for testing and often clarifies some of the user interactions.
When you have completed this first table, your definition should look like the following screenshot:
At this point, you can exit and save your Donor Table. The easiest way to do this is to simply press Esc until you are asked to save your changes.
When you respond by clicking on Yes, you will be asked for the object number and name you wish to assign. In a normal development situation, you will plan ahead what Object Number and descriptive Object Name you want to use.
In this case, we will use table Object No. 50000 and name it Donor. We are using 50000 as our Table Number just because it is the first (lowest) number available to us for a custom table through our Table Designer granule license.
Note that NAV likes to compile any object as it is saved, so the Compiled option is automatically checked. A compiled object is one that can be executed. If the object we were working on was not ready to be compiled without error, we could unselect the Compiled option in the Save As window, as shown in the preceding screenshot.
Be careful, as uncompiled objects will not be considered by C/SIDE when changes are made to other objects. Until you 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 you have compiled an object, you have not confirmed that all is well. You may have made changes that affect other objects which reference the modified object. As a matter of good work habit, recompile all objects before you end work for the day.
Pages/Forms
Pages are for the Role Tailored Client. Forms are for the Classic Client. If you are in the challenging position of maintaining a dual personality system (that is, running both clients), you will be forced to maintain equivalent versions of both Pages and Forms. We aren’t going to address that situation in depth in this article as we are not going to cover the design and development of Forms in detail. In this article, we will focus on Pages and cover Forms just enough so that you can create a few to use as maintenance and debugging tools.
Pages fulfill several basic purposes. They provide views of data or processes designed for on-screen display only. They provide key points of user data entry into the system. They also act as containers for action items (menu options). The first page with which a user will come in contact is a Role Center Page. The Role Center Page provides the user with a view of work tasks to be done. 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.
There are several basic types of display/entry pages in NAV:
- List pages
- Card pages
- Document pages
- Journal/Worksheet pages
There are also page parts (they look and program like a page, but don’t 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 in the following screenshot shows a subset of the data for each customer displayed. The Master record list shows fields intended to make it easy to find a specific entry. 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.
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 (multiple pages with each tab focusing on a different set of related customer data). FastTabs can be expanded or collapsed dynamically, allowing the specific 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 the style of a Card page with several tabs showing Sales Order data fields that have a single occurrence on the page (in other words, do not occur in a repeating column). The lower portion of the Document page is in the style of a List page showing a list of all the line items on the Sales Order (all fields are in repeating columns).
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 that have been retrieved and formatted. On top of the page, the information is for the Ordering customer and the bottom right contains information for the item on the selected line.
Journal/Worksheet pages
Journal and Worksheet pages look very much like List pages. They display a list of records in the body of the page. Many 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. An example of a Worksheet page, the Requisition Worksheet in Purchasing, is shown in the following screenshot. This Worksheet assists the user in determining and defining what purchases should be made.
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 elements such as buttons, action items, and page parts. While there are a few instances where you must include C/AL code within page or page control triggers, in general it is good practice to minimize the amount of code embedded within pages. Most of the time, any data-related C/AL code can (and should) be located within the table object rather than the page object.
Creating a Card page
Let us try creating a Card page and a List page for the table we created earlier. The NAV IDE contains object generation tools (Wizards) to help you create relatively fully formed Classic Client forms and reports. Creating pages and reports for the Role Tailored Client is less about Wizards and more about actually using the Designer tools, but the Wizards are still very useful.
Open the Object Designer, click on Page and then click on New. The Page Wizard’s screen will appear. Enter the name (Donor) or number (50000) of the Table with which the page is to be associated (bound). Choose the option Create a page using a wizard:. Choose Card as shown in the following screenshot. Click on OK.
Next, you will encounter the following Card Page Wizard screen:
As this is our first Page creation effort, we will keep it simple. We will accept the single suggested FastTab of General and click on Next to proceed. That will take us to the following screen.
Now it’s time to add all the data fields for our Donor table to the page. Click on the button shown in the following image. That will move all of the Available Fields to the Field Order window.
Now click on the Finish button. The Page wizard will close and you will be looking at the Page Designer form showing the generated page code, as shown in the following screenshot.
Place your cursor on the first blank line at the bottom of the list of control definitions. Right-click and select Properties to open the Page-Properties screen as shown below (you could also press Shift + F4 or click on the Properties icon at the top of the screen). Type the page name to be displayed “Donor Card” into the Caption field, it will default into the MLCaption field too, as follows:
Escape from that screen, and Escape from the Page Designer screen.
A Save Changes form will be displayed, just like the one we saw when we finished defining our Donor table. We have the same task now as we did then, to assign an ID (object number) and Name. Let’s make this Page number 50000 and call it Donor Card. Leave the Compiled checkbox checked and click on OK so that the Page will be compiled (and error checked). Assuming you haven’t received any error messages, you have now created your first NAV 2009 page object. Congratulations!
If you are doing your work with the original release of NAV 2009, you have to test a new card page by running it from the system Run option. From the Start menu, select Run. In the command box, enter the following:
Dynamicsnav:////runpage?page=50000
If you are using NAV 2009 SP1 or later, you can test your page by simply highlighting it and clicking on the Run button at the bottom of the Object Designer screen (the Run button is programmed to automatically submit that long command to the system).
This will invoke the Role Tailored Client, open it up, and call up your new page 50000. You should see a screen that looks like this.
Experiment a little. Expand the card page to full screen. Enter some Donor data for two or three donors (hint: click on the Actions icon at the top of the page and choose the New option). You might want to open the page with the Page Designer using the Design button, add one of the data fields so it will appear a second time on the card. This time, change the Caption field for that data item. Save and compile. Run a test. Before you quit experimenting, go back and remove any extras that you had added, so that later your Donor Card will be what we created initially.
You could create a second copy of the page so that you could experiment, then discard it later. First, open Page 50000 in Design mode. Then click on File Save As| and save the page object as Page number 50090 with a different name such as Test Donor Card. Compile it, then make whatever changes you want, deleting the experimental page when you are done experimenting.
When you begin testing, you will find that a lot of features have been created automatically as part of the Card page, but you are still very limited in what you can do. For example, without a properly set up List Page, it’s harder to move around in your table and quickly find different Donors, especially if there are more than just a few records in the table. This difficulty would be even more significant for your users. That’s why List pages are the primary data navigation interface in the application system. So let’s create a List page for our Donor table.
