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.

Another (quicker) way to add new users to Project “Madeira” Preview, and some thoughts…

01-SignupOn April 18th, I posted instructions for O365 admins to add team members to their Project “Madeira” Preview tenant.

Marko Perisic (@mpnav, Project “Madeira” GM at Microsoft), came across that post / tweet and was kind enough to share a quicker way to do this, with no help needed from admins:

Simply have your team members navigate to the Project “Madeira” Preview website (www.projectmadeira.com), click on “Try the Preview” and use their work Office 365 credentials, and follow the prompts. Within minutes, they will be added to Project “Madeira” as a user, with the SUPER permission set assigned to them.

I tried it, it works as advertised, but….

It’s quick, yes, but I really hope this is a Preview-Only “feature” that will be gone when Project “Madeira” goes live.

Why? The fact that any user in your organization with an O365 account can not only add themselves to your ERP system but also have unrestricted (SUPER) access to all your sensitive data has to be cause for concern.

The admin can disable access for a user afterwards, or replace the SUPER permission set with more restrictive permission set(s), but that’s still a little unnerving…

If this “feature” were to make the final cut, there would another area of concern: The cost of Project “Madeira”, being a SaaS offering, will be a function of the number of users per billing period, and unneeded users adding themselves to Project “Madeira” would also impact subscription costs for an organization.

Reminder to Self: Calm down and repeat, “This is a Preview. This is a Preview. This is a Pr….”

It’s entirely possible that this feature was put in place to help people get easy access to the Preview, and not burden administrators.

One way of improving upon this for the final release:

Ideally, when Project “Madeira” is finished and officially released (with its yet-to-be-known formal name), we would have a way to add users that is both quick and secure.

One thought that comes to mind is a hybrid of what we have now:

  • Allow an O365 user to get the process started by going to the Project “Madeira” site and entering their credentials. This would create the user in Madeira, but in a Disabled state and/or with no permission sets assigned.
  • Have that kick off an Approval Workflow in Project “Madeira” where the administrator is notified, so that the request can be reviewed and a determination can be made as to whether the user should have access to Madeira at all, and if so, to which companies and permission sets.
  • Upon Approval or Rejection, notify the O365 user of the outcome.

Update (response from Marko):

Issues connecting new Project “Madeira” Users to Power BI?

Homepage_metal_large_2If you’ve just added a new O365 user to Project Madeira and the new user is having trouble getting PowerBI.com working with the content pack, just try again the next day or so. It looks like the NAV User name and/or Web Service Access Key need some time to propagate.

I’ve had this happen with a couple users now, and at first I thought I was doing something wrong, only to find it working when I tried again with the same user credentials a day or two later.

You can find detailed instructions on connecting Project Madeira to Power BI on our blog post here.