The building blocks

To understand the development examples in this book, we will discuss some of the basic building blocks of Microsoft Dynamics NAV 2009.

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 non- technical people to understand the data model. We'll discuss the unique structure of the application in the next chapter.

Tables, however, not only contain data, 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.

For the user interface there are three object types: Forms, reports, and pages. The first and latter are intended for user input. 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.

Forms and pages are tightly linked to each other. Each form object has a page object with the same number and name. The form object is used in the 'Classic Client' only whilst the pages are used in the 'Role Tailored Client'.

The report object is used in both interfaces but has two layouts—a black and white layout for the Classic client and a RDLC layout for the Role Tailored client that supports colors and graphs.

As the tables are structured in the way the application works, the forms and 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, or when using the Classic Client which does not support Role Centers.

The last two object types are external interfacing objects. Data ports and XML ports make it possible to import and export data in and out of the system.

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.

Tables as user interface and business logic

The table object in Microsoft Dynamics NAV is very important. As 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 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 if 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 this table you will see see a lot of fields that are required for a Job like WIP Method, Currency Code, and so on. But when we click on the C/AL Code icon and focus on Currency Code we get this.

Currency Code - OnValidate()
IF "Currency Code" <> xRec."Currency Code" THEN
  IF NOT JobLedgEntryExist THEN
    CurrencyUpdatePlanningLines
  ELSE
    ERROR(Text000,FIELDCAPTION("Currency Code"),TABLECAPTION); 

It 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.

Dynamics NAV in throughout supply chain

The Dynamics NAV product is used almost everywhere in the business supply chain. This is mainly because it is a highly customizable ERP system. Dynamics NAV is used in the classical supply chain companies like manufacturing plants, wholesale companies, and in retail with or without many changes. But with an add-on, the product is also used in transportation companies or in the recycling industry.

In order to understand this better, it is important to know how companies work. A company is a person or a group of persons using materials and resources to deliver a product or a service to other companies or end consumers. A group of companies working together is called a supply chain. Dynamics NAV can be used in all these companies although it is traditionally used in companies with 5 to 250 concurrent users.

In order to serve this process, Dynamics NAV has a list of basic modules:

• Financial management: Traditionally, financial management was used in companies to comply with federal regulations of bookkeeping. For entrepreneurs starting their business, this is usually the part they least like. However, good bookkeeping can give a clear view on the company's well being and support strategic decisions with good financial information.
• Inventory: Every company that grows will reach a certain point where it is no longer possible to handle inventory without a system. Keeping too much inventory is expensive. A good inventory system can help you keep your stock management as efficient as possible.
• Relationship management: When it comes to people, a company is not only dealing with customers and vendors. RM will help you keep track of every company and person your company is dealing with.
• Sales: The sales process is usually the place where businesses make money. The system will help you keep track of orders that your customers place.
• Purchasing: The purchasing department is usually split in two pieces. One piece is the purchasing of goods the company needs for itself. This facility management can grow into a business of its own at large companies. The other purchasing part is buying the materials and resources you need for your sales process. For some trading companies, this can even be a drop shipment process where you never have the purchased goods in house.
• Warehouse management: Warehouses are getting bigger and bigger, making the need for a system that supports the picking and put-away process even greater. This is usually tightly connected to the sales and purchasing process.
• Manufacturing: When you make products yourself, you need a system that helps you create a new item from one or more purchased materials and resources.
• Jobs: In some companies the process of delivering a service is so complex that it requires its own administration process. Time and billing is usually a very important process for these companies.
• Service management: This supports the service process handling warranty and necessary periodical maintenance of your items.

Some basics

Microsoft Dynamics NAV has some basic structures that are reused throughout the application and are necessary to understand before you read the rest of this book.

Number series

Databases need unique records. The application has two ways of making this happen.

Some tables have automatic incremental numbering that cannot be influenced. These are often accounting tables that have auditable purposes. Examples of these tables are G/L entries, G/L registers, and VAT entries.

The other way is using a flexible alphanumeric code. In some setup tables, users are free to create their own numbers, like in the location table, but most of the time, number series functionality is used. These can be influenced by the end user depending on their access rights. Let's have a closer look at those:

Users can define their own numbering, usually starting with an alphanumeric character. Numbering can be done automatically, manually, or in a combination. Numbers can have a starting date and incremental number. This way you can number your Sales Invoices SI11-0001. SI means Sales Invoice. 11 means 2011 and 0001 is the incremental number.

Number series can be linked to each other making it possible to have a different number series for national and international customers.

Extended text

Most master data tables in Microsoft Dynamics NAV have two description fields but it is possible to add extra text.

The text can be defined for all languages in the system and valid for a specific period.

We can enable or disable using the text for most documents available in the system, so we can have a long text for the Sales Quote and a shorter text for the Sales Invoice.

Navigate

The main reason Microsoft Dynamics NAV consultants like you to use numbers as SI11-0001 is the Navigate functionality. This functionality makes it possible to find all information in the database linked to this document. If you were to call your Sales Invoice 110001 and your Purchase Invoice the same, the system would not be able to find the correct information.

When Navigating on Posted Sales Invoice 103006 in the CRONUS Demo database, we get all the information that is linked to this number.

Navigation shows both documents and entries. Using the Show option, we can drill down into the records and go even deeper into the information.

Setup tables

An ERP application can be used in many different ways and to make it work in the way we want, we need to set it up correctly. We already discussed that Dynamics NAV has far less setup work required than other ERP packages and is more likely to be changed but nonetheless, there is setup work to do.

Every part of the application has its own setup table. There are also some application-wide or cross application setup tables. During the implementation, we need to make sure to touch all of these tables. Changing these setups after the implementation should be done with great care.

This list shows all Microsoft Dynamics NAV setup tables grouped by type.

When we open a setup from the application, we see several options, including the numbering we discussed earlier.

Posting groups

Microsoft Dynamics NAV is very flexible in its posting to the General Ledger. This is set up in posting groups. These form a matrix which is filtered out by the application.

Most application areas have one or more posting group tables:

• Customer posting group
• Vendor posting group
• Inventory posting group
• Job posting group
• Gen. Business posting group
• Gen. Product posting group
• Bank account posting group
• VAT business posting group
• VAT product posting group
• FA posting group

We'll discuss posting groups in more detail in Chapter 3, Financial Management.

Pricing

When it comes to pricing and discounts, Microsoft Dynamics NAV has a very simple, yet effective way of calculating prices.

All sales and purchase prices are stored in four simple tables.

• 7002—Sales Price
• 7004—Sales Line Discount
• 7012—Purchase Price
• 7014—Purchase Line Discount

The system finds the appropriate price by filtering down in these tables. The narrower the filter, the more likely the price is applied.

For example: The normal price of item 1972-W on the item card is 974,80 but from 1-1-2011 it is 843,345.

The filtering is done in Codeunits Sales Price Calc. Mgt. (7000) and Purch. Price Calc. Mgt. (7010). We'll discuss this structure in Chapter 2, An Example Application where we will also create such a structure for our own application.

Dimensions

Throughout the application, an unlimited number of dimensions can be used to analyze the data. These dimensions are inherited from master data tables.

The application has two global dimensions that are directly posted into each transaction. Six other dimensions can be defined as shortcut dimensions to be directly used in journals and documents. An unlimited number of additional dimensions can be added but need to be accessed with additional effort.

This screenshot shows how Global and Shortcut Dimensions can be used in a Sales Document.

As discussed earlier, Microsoft Dynamics NAV has built-in OLAP possibilities. It allows us to create cubes to be analyzed within the application or in SQL Server analysis services. .

Although the cubes can be updated real time during posting, it is highly recommended to update them periodically in a batch. Also, the number of dimensions has an impact on the performance of the system.