Knowing the Dynamics NAV philosophy of how things are done is an important aspect of successfully implementing Dynamics NAV for any organization.
This is also important for users and people working in a company that use or will use Dynamics NAV as their ERP. They have to know how to do their job in Dynamics NAV and be especially aware of the consequences of what they do.
Everyone involved in the implementation needs to fully understand the way NAV works; not only because they are the people responsible for transferring that knowledge to users, but also because they will most likely be designing and developing new functionalities and modifying existing ones. For this, it is important to use the same philosophy Dynamics NAV uses in all its standard functionalities. Breaking away from the core philosophies of Dynamics NAV will confuse your end users.
In this chapter, we will cover the following topics:
If you have never worked with Microsoft Dynamics NAV and have started playing around with it, there are a few words you will see over and over again including setup, journal, posting group, post, document, entry, dimension, and so on. You may not have a clue about what all these mean or what they are used for. But don't worry, we will explain it all!
Dynamics NAV is structured into different functional areas, namely Financial Management, Sales & Marketing, Purchase, Warehouse, Manufacturing, Jobs, Resource Planning, Service, and Human Resources.
Each of the functional areas has its own setup, where the behavior of each of the areas is defined. A general setup also exists on the Administration menu.
Each of the functional areas has a master data table. The Customer table is the master data table for the Sales & Marketing area. The G/L Account
table is the master data table for the Financial Management area. There are also other master tables and secondary master tables, which relate to the main master table in a functional area. For instance, the Customer
table has quite a few secondary master data tables such as Contacts, Bank Accounts, Ship-to Addresses, or Cross-References. They are defined in this way because a single customer may have multiple contacts, bank accounts, ship-to addresses, or cross-references.
The secondary master data of a main master data register can be found in the Navigate tab (although not all items in the Navigate tab are secondary master data):
So far we've seen what we could call core master data tables, which hold the basic information in a functional area, and we've seen that these tables may have some secondary master data tables associated with them.
A different kind of master data also exists in Dynamics NAV. We could call it information helper master data tables. A few examples of this kind of information are locations, currencies, payment terms, payment methods, units of measure, item-tracking codes, and so on.
Some helper master data may have its own secondary master data. Locations have zones and bins, and currencies have exchange rates.
Several documents exist in Dynamics NAV, such as sales documents (quotes, orders, invoices, return orders, and credit memos), purchase documents (quotes, orders, invoices, return orders, and credit memos), warehouse documents (transfer orders, receipts, put-aways, shipments, and picks), and manufacturing documents (production orders).
A document combines information from different master data tables and is one of the entry points to a transaction.
For example, a Sales Order document combines information from the Customer
table (the customer that buys), the Item
table (the items that are being sold), the Resources
table (the resources that will provide the services the company offers), and other information related to a sales order.
When the sales order is processed, it will lead to one or more transactions such as Item
transactions (the stock of the item will be reduced with the quantity being sold) and General Ledger transactions (accounting entries will be created when the sales invoice is posted).
A document always has a header-lines structure presented in a single screen. In the header section, we will find general information that applies to the entire document, such as Sell-to Customer No. In a Sales Order
document, we will find the status of the document, or the shipment date. In the lines section, we will find detailed information about the document, such as the list of all the items being sold in a sales order:
Under the Actions tab, you will always find one or more printing options to print the currently selected document. A printed document in Dynamics NAV looks somewhat like the following screenshot:
Printed documents in Dynamics NAV have all the common information that is needed. Most companies that implement Dynamics NAV ask their partners to modify the layout of the printed documents, at least those that are sent (either as a PDF file or as a printed paper copy) to their customers or vendors.
Besides the Print option, you will also find the Post action in a document, both in the Home tab (where the most common posting actions are found) and in the Actions tab (where all posting actions can be found):
Posting is the most important action in Dynamics NAV.
Before a document has been posted, it is a document for which the action that is supposed to be done, is still undone. That is, a non-posted Sales Order
is an order for which the items that were ordered have not yet been shipped or the services that had been requested by the customer have not been provided. You can see non-posted documents as a work area in which the user can enter the required information and post it when it is ready.
When you post a document, you are telling Dynamics NAV that the actions for the document has been completed (a sales order has been shipped, the items of a production order have been produced, a purchase order has been received, a sales invoice has been accounted for, and so on).
The posting action modifies the original document (to state that it has been posted) and creates new documents, that is, posted documents. For example, when a sales order is posted with the Ship option selected, Posted Sales Shipment
is created, and when a sales invoice is posted, Posted Sales Invoice
is created.
You will find posted documents from a Dynamics NAV functional area under the Archive category of the corresponding area:
In Dynamics NAV, you will see journals all over the place, in every single functional area. Just to name a few, if you move around the Departments menu, you will find a lot of different types of journals such as General Journal, Payment Journal, Item Journal, and so on:
Journals are where all kinds of transactions in Dynamics NAV, such as accounting transactions, sales transactions, item transactions, and so on, take place. When you post a document, such as a sales order, NAV will use the journals internally to post to the appropriate ledger tables.
You can actually write down all the company transactions in journals and post them there (journals also have a posting action) without using any kind of document. In fact, some companies follow this method, although we would not recommend it.
Imagine you want to post a sales invoice in which you have sold an item, a resource, and a fixed asset. Using the appropriate G/L accounts, you have to do the following:
That's quite a lot of work to just make a sale and would surely make your accounting department angrier and grumpier.
This is one of the benefits of having documents in Dynamics NAV. It goes to the appropriate journals depending on the document and concepts used in the document. This creates necessary journal lines and posts these various journals.
So why are journals important to users if all the important transactions are done using documents? The reason is there are always transactions that do not have a document, so a journal will have to be used.
Among the journals, the one that is the most used in Dynamics NAV is probably General Journal. It is mainly used to post accounting transactions. There are many accounting transactions, such as salary payment to employees and many others, that a company has to make, and the company does not have a document to make them (not in Dynamics NAV at least).
Another journal that is commonly used is Item Journal, where stock increases and decreases not associated with a document can be registered. What happens if an item is broken and thrown away? There is no document in Dynamics NAV to enter such a transaction. Well, the place to actually do this is Item Journal, where the user can post a stock decrease for the item that is broke.
Many journals that we've seen on the Dynamics NAV menu are actually the same journals, but they show and let the user enter different information and have preselected options and built-in functionalities depending on what the journal is meant for. For example, Item Journal, Phys. Inventory journal, and Output Journal actually rely on the same real journal, that is, Item Journal.
Phys. Inventory Journal is meant to register the system inventory differences when a physical count is completed. It is an item transaction; that's why it's built on top of Item Journal but has some differences.
In a physical inventory, we count how many units we have in the warehouse. We know how many units we've counted, but we do not know how many units are registered in Dynamics NAV. That's why in Phys. Inventory Journal, we inform the real quantity we've counted (in the Qty. (Phys. Inventory) field), and the functionality of the journal decides whether to positively or negatively adjust the inventory in the warehouse.
Output Journal is meant to register the stock increase of a manufactured item in the system when a production order is finished. It is again an item transaction and that's why it is built on top of Item Journal. However, the user will have to provide some extra information that is not usually entered in other kinds of item transactions, such as Production Order that is being posted, Operation in Production Order, or Scrap Quantity. The Output Journal line shows the user the fields that they have to fill in to post this transaction. These fields are not shown in other item journals.
Once a journal is filled in with all the needed transactions, it has to be posted. Once it is posted, entries will be created and the journal lines will disappear (except for those that belong to Recurring Journal).
Entries are the result of a posted transaction and they are always related to a master record.
In the following table, you will find the most important entries in Dynamics NAV. You will also see the master tables they are related to:
Entry table |
Related master table |
---|---|
G/L Entry |
G/L Account |
Cust. Ledger Entry |
Customer |
Vendor Ledger Entry |
Vendor |
Item Ledger Entry |
Item |
Res. Ledger Entry |
Resource |
Bank Account Ledger Entry |
Bank Account |
VAT Entry |
Customer or Vendor |
Job Ledger Entry |
Job |
Entries are created by a journal. G/L Entries are created by General Journal, which can also create Cust. Ledger Entries, Vendor Ledger Entries, Bank Account Ledger Entries, or VAT Entries. Item Ledger Entries are created by Item Journal.
In the following diagram, you can see which journal is responsible for creating which entry:
The image also shows that some journals, if needed, may call some other journals. So, the final result of the transaction will not only be the corresponding ledger entries for the journal that is being posted, but also ledger entries corresponding to a different journal.
For example, when posting an Item Journal transaction, Dynamics NAV will automatically post costs (depending on Entry Type) to the Inventory account, the Inventory Adjustment account, or the Cost of Goods Sold (COGS) account. The General Journal lines will be created and their posting route will be called from Item Journal.
Ledger entries in Dynamics NAV are the result of a transaction. They are the final stage of the transaction. In general, once a ledger entry has been created, it cannot be modified or deleted.
However, there is some information that must be updated on the posted ledger entries. For example, after you post a sales invoice, at some point the invoice will be paid if you want to stay in business. Therefore, Cust. Ledger Entry will have to be updated to reflect the new remaining amount for the invoice.
This is managed in Dynamics NAV using detailed ledger entries. Most entry tables in Dynamics NAV have a related detailed entry. Some information in the entry table is actually a calculation of the related detailed entries. So, there is no need to modify the original entry or even the related detailed entry. Changes are resolved adding new detailed ledger entries. This will allow the accounting department to have full traceability on the number of times the invoice is paid and/or any credits that has been applied to the invoice.
You will find only two exceptions to the norm:
Let's see how this actually works step by step:
1
PCS. You will find this in the following path:Departments/Sales & Marketing/Order Processing/Sales Invoices
10000
, The Cannon Group PLC
.4,200
is the same as the actual Remaining Amount. Yes, CRONUS sells expensive bicycles.Departments/Financial Management/Cash Management/Cash Receipt Journals
2000
that was made February 16, 2016, using the following steps:In this example, it is invoice 103035.
Note that since the amount of the original invoice is 5.000, the system has automatically set up the Amount field of the payment to -5.000. Change it to -2.000 to partially pay the invoice. The Amount value in the Cash Receipt Journal field is negative because the payment of a sales invoice is, in accounting language, a credit amount and is translated in Dynamics NAV as a negative amount.
The Cannon Group PLC
.Locate the Cust. Ledger Entry value that corresponds to the invoice that has been posted in the previous steps. You will also see Cust. Ledger Entry that corresponds to Payment we have just posted.
Note that Remaining Amount for Invoice has been updated after we posted the partial payment. Remaining Amount now shows 2.200,00.
There are two detailed entries for our Invoice entry:
Remaining Amount for the invoice entry is the sum of these two detailed entries: 4.400 + (-2.000) = 2.200.
Not all Ledger Entries tables have a Detailed Ledger Entry table.
In the following image, you can see which Ledger Entry tables have a Detailed Ledger Entry table and the name of that Detailed Ledger Entry table:
So far, we've covered master data, documents, journals, and entries. As we talked about each of these concepts, we explained a little bit of how they were connected to each other. Now we will see the general model that combines all four concepts.
The general data model looks somewhat like the following diagram:
Master data and Helper master data are combined in Document. When Document is posted, its corresponding Posted Document is created. Also, Journal lines are created and posted. The Journal lines will end up in different Entries.
Master data and Helper master data can also be combined directly on Journal without using any document. These Journal lines will also end up in different Entries.