2016 NAVUG All Star Award

InterDyn BMI is extremely honored to announce that AJ Ansari, our NAV Product Manager, was awarded NAVUG All Star at this year’s User Group Summit, along with Anthony Darden from Protective Industries & Steve Chinsky from Columbus IT.

The recipients of the awards were presented at the 2016 NAVUG Summit in Tampa, FL.

“NAVUG is so fortunate to have Members in our community like Anthony, AJ, and Steve. This past year they have shared their Dynamics NAV knowledge with the community through webinars and Chapter meetings, they have served on various committees & boards, and they regularly help other users through the Open Forum. We are incredibly thankful that they have given their time and energy to this community – we have all benefitted greatly,” said Mark Rhodes, NAVUG Program Director.

“Congratulations to each of these very-deserving recipients.” Read more

Don’t Miss This Free Dynamics NAV Virtual Summit!


Attention all Microsoft Dynamics NAV users:
virtual-summit-image Sign up now for this free NAV Virtual Summit on October 25! See what’s coming in NAV 2017, hear from Microsoft guest speakers, and learn the latest tips from our team of NAV Product Specialists.

This is a free, virtual event offered to all of our Microsoft Dynamics NAV customers. There will be several technical sessions, Q & A opportunities and various scheduled breaks throughout the day.

Can’t make it for the full day? Feel free to sign up and join in as you please!


Why NOT a Single Dynamics NAV Database for Multiple Countries?

By Nick Prevett, Sr. NAV Project Manager

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

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.