Book Image

Microsoft Dynamics NAV 2013 Application Design - Second Edition

By : Marije Brummel
Book Image

Microsoft Dynamics NAV 2013 Application Design - Second Edition

By: Marije Brummel

Overview of this book

This book is a focused tutorial on Microsoft Dynamics NAV application development to help you develop complete applications and not just application outlines. This hands-on guide starts off by introducing the supply chain that you will be using throughout the book. You will then implement the Microsoft Dynamics NAV ERP suite and learn to set it up and customize it for various industries. You will learn how to customize Dynamics NAV to suit the different aspects of a business such as financial management, relationship management, production, jobs, trade, storage, logistics, and so on. The book will take you through these Microsoft-designed application features and show you how to customize and extend them safely. Therefore, by the end of this book, you will be able to create a structure of your own in Microsoft Dynamics NAV.
Table of Contents (12 chapters)

Architectural design patterns

Microsoft Dynamics NAV has some specific architectural design patterns principles that are very important to understand before you can create your own structure. The building blocks are layered and reused and rely on each other in order to secure data integrity.

Master data

The data model starts with master data. There are three types or levels of master data. They are all used in transactions. We differentiate supplemental, normal, and subsidiary master data.

Examples of supplemental data are currencies, locations, and payment terms. They often do not use a number series but allow us to create our own unique codes.

Examples of master data are G/L Accounts, customers, vendors, items, resources, and fixed assets. They are numbered using number series and have their own journal structure.

An example of a supplemental table is the item vendor table.

Journals

Every transaction starts with a journal. Each journal can contain a number of sub-transactions that are treated by the system as one. This way the system is able to check, for example, whether the integrity of the system is maintained after the transaction is completed.

The following diagram shows how a journal is structured. PK means Primary Key, which is the unique identifier of the table:

Every journal can contain one or more templates with one or more batches, allowing multiple users to have multiple templates and batches. A journal line has a source number field that refers to, for example, the G/L Account number or the item number we are changing. When we post the journal, the changes are stored in the entry table and all the lines. For the journal, a register is maintained allowing auditors to check if the transactions are consistent.

The general ledger

To see how this works in the application, we can go to the Chart of Accounts and the General Journals, as shown in the following screenshot:

If we select G/L Account 1140 and drill down, we will see the details of this record.

These are created through journals, so let's open a journal:

This journal contains two documents on the same posting date and the balance is zero. When we post this journal, the system will create the ledger entries and a register.

This is the basic building block for Dynamics NAV. Everything in Dynamics NAV is built on top of a journal, registers, and entries.