How to Receive Multiple Shipments Against a Purchase Order and Track Costs

By AJ Ansari, NAV Product Manager

Question: How can I handle multiple shipments from a vendor for a single Purchase Order in Dynamics NAV (or Dynamics 365 for Financials),  and how do I track the total dollar amount of each receipt?

Answer:  Start by adding the Qty. to Receive, Quantity Received, Qty. to Invoice, and Quantity Invoiced columns visible in the Lines FastTab/section of the Purchase Order. You can do this by right clicking one of the column headers under Lines, and clicking on Choose Columns.

When you are about to receive a partial shipment from a vendor, overwrite the value in the Qty. to Receive field. This field should be showing the same value as what you see in the Quantity field, assuming you have not yet received any goods (if you are using NAV, depending on your Purchase & Payables Setup, the Qty. to Receive field may also be be 0 by default). Also look at the vendor’s quote / shipping document / packing slip to ensure that you have the right $ amount per unit in the Direct Unit Cost Excl. Tax field.

Continue reading “How to Receive Multiple Shipments Against a Purchase Order and Track Costs”

Why NOT a Single Dynamics NAV Database for Multiple Countries?

This blog post is designed to outline and specify to customers why InterDyn BMI advises against a Microsoft Dynamics NAV solution strategy based on a single Microsoft Dynamics NAV database modified to contain all localized versions required.

Microsoft advises against a centralized single database solution containing multiple country functionality. There are basically two ways of deploying a solution in a multi-site and international deployment scenario:

Distributed deployment is when there is a separate database for each site. This means, that each site will connect to their individual database for performing their business. Each database will include the “core” plus add-ons and the local customizations – if any. The database can be located at the site or it can be hosted at the parent company (or at a third party). If hosted, the site would then typically connect via Web Client, Windows Client, or CITRIX. Each database will have their separate license that permit the site to run the licensed functionality and the number of users. Microsoft Dynamics NAV supports this scenario.

Customers would be international organizations with sites in multiple countries. Centralized deployment is when there is one, central database that all the sites connect to, e.g. via Web Client, Windows Client, or CITRIX. The sites will connect to their separate “Company” in the database to perform their business. The database will include the “core” plus add-ons and customizations. The database will have one license that permits the sites to run the licensed functionality and a total number of users. Microsoft Dynamics NAV supports this scenario – if the database is a standard country version (incl. localizations and local language) or standard W1 version (no localizations). Customers would be multi-site but domestic organizations where the sites are located in the same country.


If the multi-site and international organization requires multiple and complex local functionality to be available in one centralized database – Microsoft Dynamics NAV does not support this. For example, the organization wants a Danish license and then includes all Norwegian and Swedish localization for their sites. The TCO will not improve in this scenario compared to the distributed scenario for the following reasons:

The savings would be marginal. Organization would need one server instead of multiple servers, yet multiple connections. Organization would have one Microsoft Dynamics NAV license with the total number of (concurrent) users that can be shared among the sites. Potential user discounts on the individual licenses would make this saving marginal.

Continue reading “Why NOT a Single Dynamics NAV Database for Multiple Countries?”

What happens when I turn “Expected Cost Posting to G/L” on or off?

Last week, I received an e-mail from one of our clients asking about the repercussions of turning off “Expected Cost Posting to G/L” in the Inventory Setup.

Inventory Setup

By default, this option is turned off / disabled. In the case of this particular client, they had turned it on in the past and wanted to know the impact of turning it off now.

When we are working with Purchase Orders in NAV, we may receive goods into inventory first and subsequently receive an invoice from the vendor. Sometimes, this may transcend months (receive goods in late March, invoice sent in April), and to give us proper visibility, NAV gives us the option to record the expected costs.

As my colleague Nick Prevett put it, “CFOs do not like surprises, so getting a delayed purchase invoice that was not expected usually creates problems.” Enabling Expected Cost Posting to G/L “makes for more accurate and timely accounting, and you do not have to build the accrual for those purchase invoices that you have not received yet and the expected/interim accounts are a good indicator of what purchase invoices are still outstanding.

Essentially, nothing will break if this option is disabled. To better understand, here’s what happens in each case (enabled, and disabled):

With Expected Cost Posting to G/L ‘enabled’:

When we use the “Post > Receive” action on a Purchase Order, NAV posts entries to the expected/interim accounts in the General Ledger based on the $ amounts that we have entered on the Purchase Order lines.

Later, when the invoice arrives, we use the “Post > Invoice” action on the same Purchase Order, and NAV reverses the expected entries in the G/L, and books the final entries to the appropriate G/L accounts. If the amounts in the Purchase Line have been changed / updated because the vendor has charged more or less than originally anticipated, the final entries posted to the G/L use these amounts.

With Expected Cost Posting to G/L ‘disabled’:

No entries are posted to the expected/interim accounts in the General Ledger when goods are received. NAV only posts entries to the General Ledger when we get the invoice from the vendor and use the “Post > Invoice” action on the Purchase Order.

Note: If we use Expected Cost Posting, we must have the appropriate requisite G/L accounts selected in the Posting Setups in NAV.