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:

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:

Creating ledger entries

Let's see how this actually works step by step:

1. Using the CRONUS demonstration company, create a new sales invoice for customer number 10000, The Cannon Group PLC. Create a line on the invoice for the item, 1000, and Bicycle. The quantity of the line will be 1 PCS. You will find this in the following path:

   Departments/Sales & Marketing/Order Processing/Sales Invoices

   
2. Post Sales Invoice.
3. Open Customer Card for customer number 10000, The Cannon Group PLC.
4. Click on the Navigate tab and then on Ledger Entries (or press Ctrl + F7).
   
5. Locate the Cust. Ledger Entry value that corresponds to the invoice that has been posted. In this example, it is Entry No. 2135. The Original Amount for this entry is 4.000,00 with 200.00 sales tax. The total of 4,200 is the same as the actual Remaining Amount. Yes, CRONUS sells expensive bicycles.
   
6. Open Cash Receipt Journal. You will find it in the following path:

   Departments/Financial Management/Cash Management/Cash Receipt Journals

7. Create a line in the invoice to indicate the partial payment of 2000 that was made February 16, 2016, using the following steps:
   • Select Payment as the Document Type
   • Select Customer as the Account Type
   • Select customer number 10000 as the Account No
   • Select Invoice as the Applies-to Doc. Type
   • Select the invoice that has been posted on the Applies-to Doc. No field.

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.

1. Post Cash Receipt Journal.
2. Open Customer Card for customer number 10000, The Cannon Group PLC.
3. Click on the Navigate tab and then on Ledger Entries (or press Ctrl + F7).

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.

1. Click on the Remaining Amount field for the invoice.
2. The View – Detailed Cust. Ledger Entries page is opened.

There are two detailed entries for our Invoice entry:

• The first one is the initial entry that corresponds to the Invoice entry with Document No. 103035
• The second one is the entry that corresponds to the Payment entry that has Document No. G02004, which has been applied to the invoice

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.