To understand the development examples in this book, we will discuss some of the basic building blocks of Microsoft Dynamics NAV 2013.
Like all database applications, it starts with tables. They contain all the information displayed in a structured way. It is important to understand that the tables of Microsoft Dynamics NAV are not completely normalized. The tables are structured in the way the user interface works. This makes it easy for nontechnical people to understand the data model. We'll discuss the unique structure of the application in Chapter 2, A Sample Application.
Tables, however, not only contain data, but they contain business logic as well. As they are structured like the functionality in the database, tables contain simple functions like address validation and more complex functions for VAT and discount calculation.
Whenever functionality gets more complex or can be shared across the application, it is better to move them to the codeunit object. These are containers of business logic for a special purpose. Tables can also be used as a class without storing data. This allows more structured programming.
For the user interface, there are two object types: reports and pages. Reports are originally intended to be printed on paper but with the current status of technology, they are more and more used as information dashboards, combining management information with drill-through possibilities.
As the tables are structured in the way the application works, the pages are bound to one table. For people new to this concept, it sometimes takes a while to get used to this.
The Menu Suite defines the way the navigation is structured when people leave their Role Centers and go to the department pages. The Menu Suite is used for the Search window.
The last object type is an external interface object. XML ports make it possible to import and export data in and out of the system.
Query objects are introduced in Microsoft Dynamics NAV 2013 and allow developers to define SQL Server SELECT statements on the metadata level that can be used in C/AL code. It is possible to join multiple tables into one query. Query objects can also be exposed as OData web services.
For this book, the table and page objects are the most important to understand. Most of this book, however, can also be applied to older versions but then forms should be applied wherever this book addresses pages.
The table object in Microsoft Dynamics NAV is very important. Since it is not normalized, it contains a lot of information about how the database works.
For example, the Job Card (88) is built on one table, the Job (167). This table contains all the fields required for this screen.
In a traditional development environment, this screen would have a transaction GetJobData and UpdateJobData. These transactions would read the information from the database, map them to the screen, and save the information in the database if the user is finished. However, in Microsoft Dynamics NAV, all fields that are displayed in the interface are stored in one table. This makes it possible for the screen to have built-in triggers to get the data and update the database.
The table object then contains the business logic required for this document. Let's have a look at some of the fields in this table:
In the preceding screenshot, we can see a lot of fields such as WIP Method, Currency Code, and so on, which are required for a job.
When we click on the C/AL Code icon and we focus on currency code, we get the following result:
Currency Code - OnValidate()
IF "Currency Code" <> xRec."Currency Code" THEN
IF NOT JobLedgEntryExist THEN
CurrencyUpdatePlanningLines
ELSE
ERROR(Text000,FIELDCAPTION("Currency Code"),TABLECAPTION);This contains business logic that gets executed every time something happens with this field. In this case, the currency factor is recalculated and updated in the sales lines.
So the tables in Microsoft Dynamics NAV are not just data containers, they are the foundation for both the business logic and the application workflow.