Search icon CANCEL
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Microsoft Dynamics NAV 2013 Application Design

You're reading from   Microsoft Dynamics NAV 2013 Application Design Customize and extend your vertical applications with Microsoft Dynamics NAV 2013

Arrow left icon
Product type Paperback
Published in Sep 2014
Publisher Packt
ISBN-13 9781782170365
Length 504 pages
Edition 2nd Edition
Languages
Arrow right icon
Authors (2):
Arrow left icon
Marije Brummel Marije Brummel
Author Profile Icon Marije Brummel
Marije Brummel
Mark Brummel Mark Brummel
Author Profile Icon Mark Brummel
Mark Brummel
Arrow right icon
View More author details
Toc

Table of Contents (12) Chapters Close

Preface 1. Chapter 1: Introduction to Microsoft Dynamics NAV 2. Chapter 2: A Sample Application FREE CHAPTER 3. Chapter 3: Financial Management 4. Chapter 4: Relationship Management 5. Chapter 5: Production 6. Chapter 6: Trade 7. Chapter 7: Storage and Logistics 8. Chapter 8: Consulting 9. Chapter 9: Interfacing 10. Chapter 10: Application Design 11. Installation Guide

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.

lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at €18.99/month. Cancel anytime