Microsoft Dynamics NAV 2016 Financial Management: Master the world of financial management with Microsoft Dynamics NAV 2016, Second Edition

In order to use Dynamics NAV, all organizations have to use the Financial Management area. It is the epicenter of the whole application. Any other area is optional and their usage depends on the organization's needs. The sales and the purchase areas are also used in almost any Dynamics NAV implementation.

Actually, accountancy is the epicenter, and the general ledger is included inside the Financial Management area. In Dynamics NAV, everything leads to accounting. It makes sense as accountancy is the act of recording, classifying, and summarizing, in terms of money, the transactions and events that take place in the company.

Every time the warehouse guy ships an item, or the payment department orders a transfer, these actions can be written in terms of money using accounts, credit, and debit amounts.

An accountant could collect all the company transactions and translate them one by one to the accounting language. But this means manual duplicate work, a lot of chances of getting errors and inconsistencies, and no real-time data.

On the other hand, Dynamics NAV is capable of interpreting such transactions and translating them to accountancy on the fly. In Dynamics NAV, everything leads to accountancy, so all the company's employees are helping the financial department with their job. The financers can now focus on analyzing the data and taking decisions, and they don't have to bother on entering the data anymore.

One of the first things you will face when working with Dynamics NAV is the inability to modify what has been posted, whether it's a sales invoice, a shipment document, a general ledger entry, or any other data. Any posted document or entry is unchangeable.

This might cause frustration, especially if you are used to working with other systems that allow you to modify data. However, this feature is a great advantage since it ensures data integrity. You will never find an unbalanced transaction.

If you need to correct any data, the Dynamics NAV approach is to post new entries to null the incorrect ones, and then post the good entries again. For instance, if you have posted an invoice, and the prices were wrong, you will have to post a credit memo to null the original invoice and then issue a new invoice with the correct prices:

As you can see, this method that is used for correcting mistakes always leaves a track of what was wrong and how we solved it. Users get the feeling that they have to perform too many steps to correct the data with the addition that everyone can see that there was a mistake at some point. Our experience tells us that users tend to pay more attention before they post anything in Dynamics NAV, which leads to making fewer mistakes in the first place.

So another great advantage of using Dynamics NAV as your ERP system is that the whole organization tends to improve their internal procedures, so no mistakes.

Dynamics NAV does not have any kind of Save button anywhere in the application. Data is saved into the database while it is being introduced. When you enter data in one field, right after you leave the field, the data is already saved. There is no undo feature.

The major advantage is that you can create any card (for instance, customer card), any document (for instance, sales order), or any other kind of data without knowing all the information that is needed.

Imagine you need to create a new customer. You have all their fiscal data except their VAT number. You could create the card, fill in all the information except the VAT Registration No. field, and leave the card without losing the rest of the information. When you have figured out the VAT number of your customer, you can come back and fill it in. The not-losing-the-rest-of-the-information part is important.

Imagine that there actually was a Save button; you spend a few minutes filling in all the information and, at the end, click on Save. At that moment, the system carries out some checks and finds out that one field is missing. It throws you a message saying that the customer card cannot be saved. So you basically have two options:

We will open a customer card to see what kind of information is stored in Dynamics NAV about customers. To open a customer card, follow these steps:

The following screenshot shows the customer card for The Cannon Group PLC:

Customers are always referred to by their No., which is a code that identifies them. We can also provide the following information:

Besides the information you see on the card, there is much other information we can introduce about customers. Take a look at the Navigate tab found on the ribbon:

The other information that can be entered is as follows:

But customers, just as any other master data record, do not only have information that users inform manually. They have a bunch of other information that is filled in automatically by the system as actions are performed:

Not all the information we have seen on the customer card is mandatory. Actually, the only information that is required if you want to create a transaction is to give it a No. (its identification) and to fill in the posting group's fields (Gen. Bus. Posting Group and Customer Posting Group). All other information can be understood as default information and setup that will be used in transactions so that you don't have to write it down every single time. You don't want to write the customer's address in every single order or invoice, do you?

Now, let's take a look at an item card to see what kind of information is stored in Dynamics NAV about items. To open an item card, follow these steps:

The following screenshot shows the item card for item 1000 Bicycle:

As you can see in the screenshot, items first have a No., which is a code that identifies them. For an item, we can enter the following information:

Besides the information you see on the item card, there is much other information we can introduce about items through the Navigate tab found on the ribbon:

As you can see, the other information that can be entered is as follows:

As with customers, not all the information in the item card is mandatory.

We will start with third-parties-customers and vendors. They work exactly the same way. We will just look at customers, but everything we will explain about them can be applied to vendors as well. Then, we will look at items, and finally, we will take a brief look at locations and resources.

The concepts learned can be used in resources and locations, and also to other master data such as G/L accounts, fixed assets, employees, service items, and so on.

Sales prices can be defined in different levels to target different pricing policies.

The easiest scenario is when we have a single price per item or resource. That is, the One single price for everyone policy. In that case, the sales price can be specified on the item card or on the resource card, in a field called Unit Price.

In a more complex scenario, where prices depend on different conditions, we will have to define the possible combinations and the resulting price.

We will explain how prices can be configured for items. Prices for resources can be defined in a similar way, although they offer fewer possibilities.

To define sales prices for an item, follow these steps:

As you can see in the screenshot, multiple prices have been defined for the same item. A specific price will only be used when all the conditions are met. For example, a Unit Price will be used for any customer that buys item 1936-S after 20/01/2017 but only if they buy a minimum of 11 units.

Different fields can be used to address each of the pricing policies:

They can all be used at the same time to enable mixed policies.

Sales discounts can be defined in different levels to target different pricing policies.

We can also define item discounts based on conditions. This addresses the Discounts based on items policy and also the Discounts per volume, period or currency policy, depending on which fields are used to establish the conditions.

In the following screenshot, we can see some examples of item discounts based on conditions, which are called Line Discounts because they will be applied to individual document lines:

Besides the line discounts, invoice discounts can be defined to use the General discounts per customer policy. Invoice discounts apply to the whole document and they depend only on the customer.

Follow these steps to see and define invoice discounts for a specific customer:

The following screenshot shows that customer 10000 has an invoice discount of 5 percent:

There is a third kind of discount, payment discount, which can be defined to use the Financial discounts per early payments policy. This kind of discount applies to the whole document and depends on when the payment is done. Payment discounts are bound to a Payment Term and are to be applied if the payment is received within a specific number of days.

The following screenshot shows the payment terms that can be found by navigating to Departments/Sales & Marketing/Administration/Payment Terms:

As you can see, a 2% payment discount has been established when the 1M(8D) Payment Term is used and the payment is received within the first eight days.

Purchase prices and discounts can also be defined in Dynamics NAV. The way they are defined is exactly the same as you can define sales prices and discounts. There are some slight differences:

Dynamics NAV has a document approval functionality that can be applied over open documents to prevent users from posting them (and thus reaching the next document, a posted document) while they have not been approved.

Document approval can be set up in different ways so that not all documents have to go through an approval process. Only the documents that met certain conditions will actually require someone to approve them. We can decide the following:

The following is the setup required for the workflow configuration in NAV 2016:

General journals are used to post to general ledger accounts and other accounts such as bank, customer, vendor, and fixed asset accounts. Posting with a general journal always creates entries on general ledger accounts.

The following are the types of journal entries:

Follow these steps to enter and post in the General Journal:

Navigate to Departments/Financial Management/General Ledger/ History/G/L Register.