After analyzing the standard functionality, if we finally find out that we will have to develop our own customized code to cover the project needs, it is important that we develop following the same structure that Dynamics NAV uses in its modules.
The users that are going to use our development are users that are also going to use standard parts of the application. To avoid confusing them, it is essential to use the same philosophy and the same structure everywhere. This way, once a user knows one part of the application, he/she can intuitively use other modules.
This is something that will also help us; we do not have to reinvent the wheel every time. There is no need for us to consider how to structure our data on each development. Take the existing structure as your basis, and just grow its functionality to meet your needs. With this, we are not only making the developer's life easier, but also the life of others who will participate in the project, such as the consultant, the implanter, the trainer, or the person who will support the customer once they start to run with Dynamics NAV. And to develop our own application, using the principles and structure of what already exists, it is important to know what already exists. This is what we will cover in the next section.
In Microsoft Dynamics NAV 2013, you can find seven basic object types; they are as follows:
Even if we are talking about objects, it is important to note that Dynamics NAV is not object-oriented, but object-based. You have seven object types that you can use, but you cannot create new object types. This may seem limiting, and it actually is, but it also makes development work much easier.
Each object is created using a specific designer. For example, tables are created using the Table Designer , pages are created with the Page Designer , and so on.
To open the development environment, you will have to install Dynamics NAV Development Environment. Open it and navigate to Tools | Object Designer (or press Shift + F12); the following window will open:
On the left-hand side you will find a number of icons representing the different objects available. On the right-hand side, you will see a list of all existing objects of the object type selected. In the previous screenshot, we can see a list of objects of the Table
type.
All application objects are identified by an ID number. There are, however, restrictions about which numbers can be used while creating application objects. As a general rule, when you are developing for a customer you will use ID numbers between 50000 and 99999 when creating new objects, although you will have to check the exact IDs that can be used for a specific customer license. You will be allowed to modify the standard objects, but you cannot create them.
To modify an existing object, you must select it and then click on the Design button. This will open the object in its corresponding designer. In the following screenshot, we can see the Table 18 Customer - Table Designer window:
Each object has its own fundamentals. A table contains properties, triggers, fields, and keys, which are related to each other, as we can see in the following image:
To access the table properties, from the table designer scroll down and put the cursor on an empty line at the bottom of the Table Designer. Then navigate to View | Properties, or click on the properties icon on the toolbar, or press Shift + F4. The Table - Properties window opens and shows the properties of the table. Here, developers can view and modify the properties for the Customer table.
To access the triggers from the Table Designer, go to See | C/AL Code (or press F9). The following window will open, showing all the triggers of the table, including the field triggers:
Field properties can be accessed from the Table Designer. Put the cursor on the field you want to check and then navigate to View | Properties, or click on the properties icon on the toolbar, or press Shift + F4. The properties window from the selected field opens as shown in the following screenshot:
Keys can be accessed from the Table Designer, by navigating to View | Keys as shown in the following structure:
The properties of the keys can be accessed the same way you accessed the table properties or the field properties. Select the key you want to check, and navigate to View | Properties. Not all objects have the same elements as the ones shown for the tables, but they have similar elements that can be accessed in a similar way.
Tables are the most fundamental objects among Microsoft Dynamics NAV objects. They store records that are collected through pages, for example, customers, sales, and inventories. These records are then presented to users through pages and reports.
The table's structure is the base of the structure of the whole application. We have already covered the table structure in Chapter 3, Dynamics NAV General Considerations, but we go a bit deeper in this section. In the standard application, we find different kinds of tables that are used for different purposes.
Customer
table; in the purchase area, it is the Vendor
table; and in the warehouse management module, the Item
table is the most important table; therefore they are called master tables.Customer Price Group
table. This table contains the distinct price groups that are set up in the Company
table. A value from this table can be selected and assigned to a customer from the Customer
table.Header
table and a Lines
table. Orders, shipments, or invoices are all examples of documents. The documents can also be divided between live documents and posted documents. The posted documents are stored in different tables that have the property of being protected tables.Customer ledger Entry
table, for instance, we can find an entry for each invoice, credit memo, or payments for a single customer.G/L Register
table as they all belong to the same posting process, the posting of a specific sales invoice.The best way to understand a concept is to see it in practice. This is why we are going to analyze the structure of the tables on a particular area, the warehouse management area.
The master table of the warehouse management area is the Item
table. It holds the main data in this area and everything else relates to it. Usually, the primary key of a master table is a field named No.
. Typically, a series number is used to assign a new No.
value each time a new item is created. Field No.
gets replicated on different tables to refer to a specific item.
In the item card, you will find fields that can be filled by selecting data from a secondary table, such as the Base Unit of Measure
field that can be filled by selecting data from the Item Unit of Measure
table. For each item, you can indicate its sales price on the Sales Price
table, which is also a secondary table.
Any table (it doesn't matter if it's a master table, a secondary table, a setup table, or any other kind of table) can be used in other application areas. The Sales Price
table, which we've seen, is also a secondary table of the sales area.
In the example we've only seen a couple of secondary tables related to the Item
master table. We'll find many other secondary tables, such as the Item Category
table, the Product Group
table, the Tariff Number
table, the Item Tracking Code
table, and the Item Variant
table, just to give a few examples.
The setup table of the warehouse management area is called the Inventory Setup
table. The series number used to code the items can be set up on this table; also, other information, such as whether we want the item cost to get automatically posted to the general ledger or not, is available. Other setup tables also affect how the warehouse management area works. For instance, in the General Ledger Setup
table you can indicate the rounding precision of the unit prices of the items in the Unit-Amount Rounding Precision
field.
The master table, the setup tables, or the secondary tables are meant to create and define an item.
Now it's time to start using the item on documents, to purchase or sell them. The item can now be used on the lines of a document. In the following example, we've used a sales document, the sales order. There are other sales documents where an item can be used, like the sales quote, the sales invoice, the sales return order, or the sales credit memo. In fact, all these sales documents are stored on a single document structure composed of the Sales Header
table and Sales Line
table. Each one is identified by the Document Type
field that is part of the primary key of the tables.
When an item is used in a document, not only is the item number stored on the Sales Line
table, but many other fields from the Item
table are also copied. Fields like the Inventory Posting Group
field, the Description
and Description 2
fields, the Gen. Prod. Posting Group
field, or the VAT Prod. Posting Group
field—just to name a few—are copied from the Item
table to the Sales Line
table.
It may seem redundant; why are all those fields copied if the information is already stored in the item card? Well, this information is copied for two reasons. Firstly, this information is considered default data; and secondly, it gets copied to allow users to change a field value on a specific order. As an example, you can change the item description, the sales unit of measure, or the item VAT group on a specific order. Other fields, such as Inventory Posting Group
, are also replicated on the Sales Line
table, but users cannot modify their value. It may take some time between creating the order and finally posting it. In the meantime, the item configuration may have changed. However, it is not acceptable for a specific order to post something different to when it was created, which is probably when the user checked it.
The same is true for the item price. When we create a sales order for the item, the system calculates and proposes a price for the item. This is the price we have configured, either on the item card or in the Sales Price
table. We have told our customer the selling price so that he can approve the order before we ship the item. Imagine that in the meantime, the item price changes. We all agree that the new price is for new orders. It would be unacceptable for the system to change the existing price without warning.
Copying data from the master table to a document table is part of Dynamics NAV philosophy. It is something that we can find in all application areas and in all documents. It has a clear pro: it makes the system flexible. It also gives us a lot of traceability. It also has a con: any change on a master table is not reflected immediately. Existing document lines keep the old configuration. The user has to refresh the line if the new configuration is needed. From our experience, some users have difficulty understanding this. They don't know when to refresh a line. During training, we will have to invest time to tell them and make sure they understand when to refresh a line. When the order is ready and the item has been shipped to the customer, the order can be posted. The posting routines, which are explained later on, are in charge of verifying that all data is correct and to create all the required entries to reflect the transaction.
Concerning documents, a shipment is created by inserting records on the Sales Shipment Header
and Sales Shipment Lines
tables. In the next step, the invoice will be created by inserting records on the Sales Invoice Header
and Sales Invoice Lines
tables. We can see this in the following diagram:
Records representing the shipment and the invoice are almost exact copies of the original order. Take a look at the fields found on the Sales Line
table, which has been shown in the following screenshot:
And now take a look at the fields found on the Sales Shipment Line
table, which has been shown in the following screenshot:
As you can see, we can find almost the same fields, with the same name and the same type. The most important part is that fields have the same value on the Field No.
property. This is important because to copy values from one table to another, the TRANSFERFIELDS
instruction is used. This instruction copies fields based on the Field No.
property. For each field in the Record
(the destination) table, the contents of the field with the same Field No.
property in the FromRecord
(the source) table will be copied, if such a field exists.
So, if you create a new field on the Sales Line
table and you need to propagate the value of the field along the different documents, you just have to create the same field with the same Field No.
property on the tables where the documents are stored. There is no need for extra coding.
We have not seen them in this example, but there are other document tables related to the warehouse management area. For instance, the Transfer Header
and Transfer Line
tables, with its corresponding historical documents Transfer Shipment Header
, Transfer Shipment Line
, Transfer Receipt Header
, and Transfer Receipt Line
. Historical documents are part of the Dynamics NAV protected tables. Data on protected tables cannot be changed and nor can you directly insert new records on those tables; the posting routines are the ones in charge of inserting data in those tables.
To refresh our memory, so far we have covered the types of tables that are shown in the following diagram:
Only Entry
and Journal
tables are left and we will cover them in the following section.
As we have mentioned, the purpose of entry tables is to keep track of all transactions done with a master table. Each time we purchase an item, we have to register the stock increase. Every time we sell an item, we have to register the stock decrease. It gives us valuable information about the item, such as the stock we have at any time. One might think that we don't need an entry table to determinate the stock. As we've seen before, when we purchase or sell, we create a document. We could just add all purchases and sales document lines and get the same data. Again, we seem to be duplicating information. It is true that for one transaction the same information is to be copied to a lot of tables. However, in each case we want to see the information in a different way. Also, the tables that are used for sales and purchases documents are different; to get the stock, we would have to search between multiple tables. This will make the whole system slower.
Another element to consider is that on some occasions we need to register an item transaction but have no documents. What if we break a box? We need to decrease the item stock but there is no document to reflect this. In this case, we will want to create a new record in the table entry and that's it.
Some master tables will need more than one entry table. This is the case of the warehouse management area, where we find the Item Ledger Entry
and Value Entry
tables. The Value Entry
table is used to store more details related to each item ledger entry.
The primary key for all entry tables is a field called Entry No.
, which is an auto-incremental integer. All entry tables also have a field named Posting Date
.
Additionally, when new records are inserted on entry tables, the system also creates new records on tables called Register
. In the warehouse management area, we find the Item Register
table. The Item Register
table is used to keep track of when entries are created (regardless of the posting date), which user created them, and also how many entries have been created for each transaction. The Item Register
table can be considered a secondary table.
Last but not the least, we find the journal tables. Journal tables are very important since they contain most of the business logic of the application. All the posting processes found on the application are based on journal tables. In the warehouse management area, we find the Item Journal Line
table.
If the posting is made from a document, the posting process converts the document lines to journal lines by creating temporary registers on the Item Journal Line
table. The user can also manually create lines on the Item Journal Line
table and then post them, without using a document at all.
And at last we can see the final picture of how tables are structured in Dynamics NAV, as shown in the following diagram:
In reality, you will find many other secondary tables, setup tables, document tables, and entry tables that are not shown in the diagram, but the structure remains the same.
Remember that all existing areas in the applications follow this structure; therefore users are used to it. Keep this structure in mind while building your own applications.
In the previous section we've seen the table's structure and how important it is to keep the same structure in all the areas to help users understand how the area works. Pages are also important; they are the objects through which users interact with Dynamics NAV. Users do not see tables, but pages. Thus, maintaining consistency in the page structure is vital for the user to perceive the consistent application structure. In the standard application, we find different kinds of pages that are used for different purposes, such as:
As in the previous section, we will analyze the structure of pages on a particular area, the warehouse management area.
The following screenshot shows the default role center page for a user that has the shipping and receiving profiles assigned:
The Role Center page has a central area called Activities. This area contains a few cues that provide a visual indicator of the work that a user has to do each day. Cues are different for each role. The Activities area also contains actions so that the user can start new transactions right from the Role Center.
Card pages show data from a single table and also from a single record. In the following screenshot, you can see the Item Card page. It contains all fields that can be stored in the Item
table, except for a few fields that are used for internal purposes.
Data is shown in different tabs, grouping fields that are used for similar purposes. In the Item Card page, we can find all those tabs: General, Invoicing, Replenishment, Planning, Foreign Trade, Item Tracking, and Warehouse.
If you need to create your own card page, keep a similar structure. Keep in mind that all cards start with a tab called General. Card pages are always editable, which means that the user can insert, modify, or delete data on this page. Only a few fields are not editable, such as the Last Date Modified
field. But you don't have to define this as an editable page because it is a property of the field in the table where you define whether a field is editable or not.
There is one exception to that. If one field has to be editable only in certain circumstances, you cannot define it on the table. You will need to do that on the page.
Find the Planning tab from the item card. Note that fields like Safety Stock Quantity can only be editable with certain values from the Reordering Policy field.
When the Reordering Policy field has no value entered into it, the Safety Stock Quantity field is not editable. This is recognizable because the field has a grey background. When you change the value to Lot-for-Lot
, the Safety Stock Quantity field becomes editable. You can identify it because the fields have a white background.
As we mentioned before, this behavior has to be coded from the card page. Follow these steps to see how it is achieved in the item card page:
Find Page 30 Item Card and click on the Design button.
Navigate to View | C/AL Code. The following screenshot shows what you will see:
Only a few lines of code are present for the non-editable fields, but no code for inserting or deleting a record or when validating a field.
List pages show multiple records from a single table. For each card page, you will find a list page that shows data from the same table. In fact, the users access the card page from the list page. These pages are not editable and are only used to show data, not to modify or delete it.
The following screenshot shows the item list page:
The list pages show fewer fields than the card pages. Only the most important fields of each master table are shown in the list.
By clicking on the related information icon, you will find a link to all kinds of tables that contain information related to the item. The options that are used most often have a shortcut key so that users can access it without using the mouse.
In the previous screenshot we can see that the Ledger Entries option can be accessed with Ctrl + F7. Remember to enable shortcut keys while creating your own list pages, and always use the same shortcut keys for the same actions in all the pages in the application, no matter what kind of page it is! This applies to all kind of pages, not only the list pages.
All options that can be found on the Actions pane can also be found on the item card page. Therefore, while creating a new option, remember to make it accessible from the list page and also from its corresponding card page.
Most secondary tables don't have a card page, but all of them have a list page. When no card page can be found for a table, the list page is editable. We are allowed to insert, modify, or delete records from the list page.
This is the case of the Item Units of Measure page, which can be accessed from the Actions pane, the Navigate tab, the Item entry, and the Units of Measure icon. You will find the option both from the item card and the items list.
Those list pages need to show all fields (except internal use fields) to the user, so that he/she can fill them with the required data. By default, the Item Units of Measure page shows only two fields, but many others are also available to the user.
Put the cursor anywhere on the header of the table, where it says the name of the fields. Right-click on the mouse and select the Choose columns option as shown in the following screenshot:
A new window opens and allows the user to customize the page. On the Available columns grid, you will find all the fields that are available for the page but are not shown at the moment, as shown in the following screenshot:
Select one of them and click on the Add >> button. Do the same with all the remaining fields, and then click on the OK button. You will end up with the Item Units of Measure page as shown in the following screenshot:
So remember that if you want a field from a secondary table to be filled by the users, you will have to make the field available from the list page. With master tables, you will have to make the field available from the card page and then decide if the new field is important enough to make it available on the list page.
These kinds of pages are used to show the two tables related to a document: the header and the lines. Document pages are used to show data related to the header, and they include a link to a ListPart page where lines are shown.
The following screenshot shows the Sales Order page:
As card pages, users access document pages from a list page. The actions and related information found on the document page and its corresponding list page must remain the same while adding new options.
The document pages are organized in tabs, like the card page. The only difference is that the Lines tab shows another page, a ListPart page that is embedded into the document part.
On the right-hand side of the previous screenshot, you can find a few tabs showing data related to the document, the customer, or the item on the order. Those tabs are a particular type of page, called CardParts . These pages are associated to the FactBox pane of the document page.
ListPart pages are pages with the same characteristics of a list page, but the difference is that ListPart pages are always used inside other pages. Actions can also be defined for ListPart pages.
The following screenshot shows the sales order Subform page, which shows the lines associated to the order:
Worksheet pages are based on a template, batch, or name structure and have a control for selecting a template, batch, or name. Journals are a good example of worksheet pages, but there are other worksheet examples such as the account schedule or the requisition worksheet functionality. The following screenshot shows the Item Journal page:
The Item Journal page is based on a batch and has a control for selecting the batch, as you can see in the previous screenshot.
Only the lines associated with the selected batch are shown in the page. It's similar to the header-lines structure. In this case, the header is the batch and has only one field, its name.
Users can create as many batches as needed on each journal. If you click on the Batch Name: field, the window shown in the following screenshot opens, showing all the available batches:
The reason for creating different batches on a journal is that batches can be set up to act in a different manner. In the Item Journal Batches page, the No. Series
field, the Posting No. Series
field, or the Reason Code
field can be filled for each batch. You will find other options on other journals. Another reason for creating different batches on the same journal is that different persons can work at the same time on the same journal without disturbing each other's work.
ConfirmationDialog pages are pages that pose a question to the user, have no input fields, and require that the user select the Yes or the No button.
The Check Availability page shown in the following screenshot is a good example of a ConfirmationDialog page:
This page will pop up when the quantity filled in a line, either a document line or a journal line, is bigger than the current availability of the item.
These pages are used for wizards, which consist of a number of user input screens or steps linked together, enabling users to carry out infrequently performed tasks.
Dynamics NAV also has a functionality called Navigate, and the page that shows this functionality is a NavigatePage type of page.
The navigate functionality shows all documents and entries posted using the same document number on the same posting date. This is a very useful way to see all the entries a particular transaction has created. If you create your own entry or posted document tables, don't forget to add them to the Navigate functionality.
Well, there is no final picture for this section. Since we were talking about structure and the importance of maintaining the same structure on customized area, we wanted to maintain the same structure of the last section! Just kidding. We hope that after those two sections, you have a clear idea of the basic structure of an area of Dynamics NAV. We encourage you to follow the same structure on any new area you develop.