I started working with Navision in 1990 and since then I've done almost everything in this industry.
In 1995 I started the Dynamics User Group, formerly Navision Online User Group and Microsoft Business Solutions User Group. Here on my blog I write mostly about the Dynamics Community, my experiences with Microsoft and especially the Dynamics NAV and Navision projects I'm working on, but also how it is to work as a self-employed Navision freelancer, Navision contractor or whatever you call it.
In my last post I wrote about how global NAV implementations used to be done. About the two different implementation models either a Template Core or One-Database Core. It took a bit longer to get this next “chapter” ready. Especially since a lot of the information has only been made available over the last week. Business Central was released this Monday, April 2nd.
The game changer was the release of NAV 2018 / Business Central. Extensions first came available in NAV 2017 and where are both very difficult to do and had a lot of limitation’s. With NAV 2018 and Extension version 2 they are much less time-consuming to do. Developing them using the “new” AL language in Visual Studio Code a very good and modern experience. And most of the previous limitations are gone.
More importantly Microsoft have started to ship their localization's as extensions, with Denmark being the first country.
I wrote in the post, that Microsoft has been “suffering” just as much as everybody else,by the way they previously have been handling localization's. Their (long term) goal is to have one version to maintain, their World-Wide (W1) version. Localization's will then be Extensions applied to a W1 version, including languages and everything.
The Danish localization for NAV 2018/Business Central still have a different base, but its C/AL source code is much closer to W1 than it was before. Translations of the C/AL objects are still made directly in the source code and there may also be more direct changes, which have not yet been converted to extensions. Just as many of the now obsolete local fields still are to be found in the database. Localized reports like invoice etc. are also still changed in the code and not in an Extension. Denmark did not have very complex changes to begin with. So that may be the reason that Microsoft started here. In Denmark the OIOUBL e-Invoicing was the change which had the most changes. In the December 2017 release of NAV 2018, it was still in the C/AL source code, but now from the April release this is also an Extension.
But most other countries have a lot more localization changes. The US-sales tax functionality for example. That’s going to be a very big Extension. Personally, then I would hope that Microsoft, would put it into W1 to replace the “sales tax” functionality here. The US sales tax module is great, a bit complex to setup, but flexible enough to have a lot of usage outside of the US. Italy, Spain, India, Russia etc. all have very complex local legal requirements, with a lot of changes to support this in NAV.
It is going to be a work in progress, such as it might be with many NAV implementations, that I think will take several releases.
Not only Microsoft are going this way now. The same message comes from partners, who have developed the localizations for so-called 3rd party countries. The countries where Microsoft does not have their own localizations. I.e. the localizations done by Pacific Business Consulting (www.pcb.co.jp) for Japan, Hong Kong, China, Vietnam and Thailand are either already shipped close to be released as Extension’s. And I’m sure the message is the same from the other localization partners.
Previously the W1 version was not a version you could actually buy from Microsoft. It was “just” the foundation for the localizations and not supposed to be used by customers. Many global NAV implementations are already based on this version. But it was always a trade-off, because using a local version also meant saying no to a lot of features available in the local versions.In the Summer of 2018, Microsoft has announced the release of a new W1 version. The difference is going to be that more of the features, which today is available in some localizations, will become global functionality. That could make perfect sense for a lot of features, which can be used by many countries.
I hope that Microsoft would consider moving the US sales tax, as I wrote above. Right now Microsoft has made no announcements in regards to what is going to be moved to the W1 version.
The short answer: Almost everything is getting much easier. Not just for global implementations, but for every NAV implementation.
When localizations are Extensions, then it really doesn’t matter, if we have individual installations/databases per country, or just a world-wide version with tenants with localization extensions per country.
In all countries with an official NAV localization (Microsoft or 3rd party), then localization issues become non-issues. You really only have to care about countries not supported. And here it’s very likely that their special requirement exists in one of the other countries. We will be able to focus on the implementation process and actual business requirements, rather than localization issues, which really adds no value to the companies.
Business Central is really all everybody talks about these days. And for large international companies that’s also good news. Microsoft’s previous Dynamics 365 ERP offerings did not only have ridicules long names but was also divided into in Business and Enterprise editions. Business edition had a user max of 250 users and was marketed towards small and mid-size companies and based on NAV (only a subset of features). Dynamics AX got re-branded to Dynamics 365 for Operations, Enterprise Edition (available both on-premise and in the cloud). Now the two editions are gone, instead we have Dynamics 365 for Finance and Operations and Dynamics 365 Business Central. With BC down being a “full NAV”, and no longer a user maximum, then NAV again becomes a valid choice for international companies.
Dynamics 365 Business Central is now a NAV platform hosted on Azure by Microsoft. A setup where the customer besides high-end hosting with a +99.9 up-time and build-in/ootb integration's to most of the Office 365/Dynamics 365 Ecosystem, also get a full NAV.
If a customer doesn’t want to go full-in on the cloud, then NAV on-premise licenses is still available until the fall. I have written a bit more about licensing further down in this post.
In Business Central the web client has also been improved. The differences to the Windows client becomes less and less.
Keyboard shortcuts and personalization has been added. Even if neither of these features are a near what they are in the Windows client, then it’s a start. I’m sure that most current NAV Windows client users will not find the web client good enough, if they use NAV more than 3-4 hours a day, depending on what they use it for of course. But that’s the topic for another blog post.
The fact that the Windows client is not available, will for sure mean that a lot of existing companies is not going to jump up on BC/SaaS for a couple or more releases. But let’s see how fast the product team works. I’m quite optimistic myself.
For new companies without previous versions of NAV, here I’m sure that most would opt for a cloud-based Dynamics 365 Business Central right away.
A further advantage of Business Central to an on-premise NAV, is that objects are free. Yes you heard right. In Navision and NAV we always have paid for the extra object we have used for customizations. A large international NAV project with a complex business model, count extra objects in the 1000’s. The extra cost just for objects is considerable, especially if you need to buy the same ranges to licenses in many countries. Definitely one of the old reasons for selecting the one-database core over the template core which is no longer there.
The first question you need to ask is if your core business functionality can be done using Extensions or if your requirements can only be solved change the standard NAV code with C/AL and C/Side?
If what you need can be done as Extensions, then all options are open. You may choose on-premise or cloud, one database or multiple installations.
If you need to change the C/AL, then you may have to choose the on-premise solution, NAV now and BC after the fall 2018. If your company is large enough eventually your base-core functionality could be done as an “Embedded App”, in which case the cloud is still an option.
If all your core functionality and business requirements can be done as Extensions, then the template core in the cloud is obvious. Low cost to get started, you just need to add your Core Extensions.
Each time you need a new country, then you start a new tenant. You install your Core Extensions, start setup, migrate data and train users. Microsoft takes care of infrastructure, hosting and monthly upgrades if in the cloud.
That is not possible if C/AL changes are needed. The best option is then that you create a hybrid, where you keep the absolute minimum changes in C/AL and move everything else to Extensions. That would typical mean required events/hooks, stuff with DotNet (may later be possible in Extensions on-premise) in C/AL.
Even if C/AL is still possible on-premise and no announcement in that direction has been made, then I would guess that Microsoft would drop it at one point after maximum 2-3 releases. By then I would also expect us to be able to do much more with VSCode and Extensions.
Each time you have a new country, then you will need a new license, a new database and a new server. And the localized version. Then you need to merge your (hopefully small) C/AL core into the country version. If there are no remaining code changes between the localized version and the W1, then no more will be required if based on same build. More or less the same as today, just a lot easier.
If your all core customization's cannot be done as Extensions, then the one-database core is obvious.
On-premise you should create a hybrid, for the same reasons as described above.
When all localizations are available as Extensions, then it will require a multi-tenant setup based on the W1 “no-localization” version and as a minimum one tenant per country. On these country tenants, you would the install the Extensions from the official or 3rd. party localization package.
Handling a One-Database Core is still not going to be trivial. Just as the One-Database Core model was never supported by Microsoft in Dynamics NAV, then I doubt that it’s going to be supported by Microsoft in Business Central. At least not for the first couple of years. That means there is no guarantee that the individual localization extensions may not be conflicting, even if they are not installed at the same time. Luckily the source code is also available for the Microsoft Extensions, so you may need to create your own versions of them.
As with the template core, if you have any C/AL changes, then the Cloud option is not possible. At least as the rule of thumb.
Microsoft also has Dynamics 365 branded vertical solutions or Embedded Aps. This is a way partners to have their own vertical solutions hosted by Microsoft. It made for the ISV’s who sells the same solution to potentially a lot of customers.
To be used for Embedded Core Apps, then it would require that the corporations either themselves sign-up to become a (non-selling) partner. Or that they work together with a partner to who manages it for them.
Notice: I have at time of writing this post, not been able to get this option confirmed by Microsoft. But if had a large enough number of users to interest Microsoft, then I’m sure that there is a way. Many of these companies may “only” have a couple of thousand full users in NAV/BC. But if implemented as D365, then it could easily bring in a lot of their new Team Users. Same as PowerBI and PowerApp, plus a connected D365 Sales suddenly becomes a lot more interesting. 1000 full BC users could easily bring in 1000+ team users in such a large organization. Don’t think it’s going to be possible for a small company with 4-5 countries and just a few 100 users.
When we talk on-premise/perpetual licensing, then nothing has changed yet. You still need a license for all the new objects you add to your solution. Even table and page extension objects need to be licensed.
When we talk Template-Core, then as before you need a license per database on-premise (minimum with starter pack, eventually with extended pack), plus a license per concurrent users. In the cloud you pay for named users, either essential, premium or team. You may therefor need more licenses in the cloud. But in the cloud there is no database license and no object fees. The One-Database Core may still be a license cost saver, when we talk very large on-premise installations. In the cloud the license cost of a one-database core would be about the same. You pay for number of named users.
Previously the two ways to get local functionality into a One-Database core was either to build yourself, or to try to implement the local objects and changes you needed. Whereas the copy-paste solution by copying the local objects sounded easy then was not that easy. Neither from a coding or licensing perspective. The only way i.e. to get a Danish localization to work in a US version, were to renumber all the objects and fields to the open number range (50000 to 99999) as all local features where in a locked country object number range, only available if you had a license with the same country code.
Where it technically is (hopefully) not going to be too challenging to get a Microsoft localization extension from one country, to work
in a different country (or W1) database. I guess that’s really Microsoft’s own goal here? Practically then it may not be as easy as it sounds. Unless Microsoft removes the current block from running the local objects from one country number range in a different country license. Right now, Microsoft also ships the source code to the localization extensions, to make it possible to change the local functionality. On less Microsoft comes up with a way to allow customers to add access to other country locations into their license, then it would still be required to the rename/renumber source and hope that the Extension again builds again. An alternative would be to have an individual license for each country tenant. So let’s hope that Microsoft will be looking into this.
Currently no announcements have been made towards changing the availability of on-premise/perpetual licenses for Dynamics NAV. I wouldn’t be surprised if big changes will happen here, when we come to the Fall 2018.
After the fall 2018 release NAV and Business Central will be the same system. Unless Microsoft makes a period with both, then all new licenses will be Dynamics 365 Business Central licenses, even on-premise (but that has not been Microsoft’s practice since NAV 2009). What that otherwise means in terms of pricing or licensing has still not announced. My own guess would be that it would mean a goodbye to Navision’s age old concurrent user principle. Even on-premise. They already have named users everywhere else, including the on-premise version of Dynamics 365 for Finance and Operations (the old Dynamics AX/Axapta). If they should have an incentive for customers to use more of the remaining Dynamics 365 ecosystem, then that would be included in the price.
I would also hope that they will have the same object licensing on-premise. No extra cost for extra objects. Migrating existing customizations to Extensions will very often require more objects, than they did in C/AL. Not only because what better option to get clean-code, than when migrating to Extensions, and clean code requires more objects, especially codeunits. And if you have added 20 fields to a table, then they may not going all be part of the same extension. Good practice is always to make your extensions as small as practical, and then eventually have dependent extensions.
But I have heard nothing about this so far, not even under NDA. That’s typically not the stuff they discuss with us MVP’s before releasing it, even if they are listen to our advises.
Before Microsoft came into the picture, before Navision Software and Damgaard merged, Navision and Axapta were two competitors, competing for basically the same markets. Since both became Microsoft products AX were positioned against the lower end of the SAP enterprise market. NAV were for companies up to a maximum of 250 users. Personally, I have been in projects where the companies were strongly under pressure to move from NAV to AX for years. And Microsoft did have a lot of good reasons for this. Not only did they need as many good references for AX as possible in the “enterprise segment”, but AX simply does have a lot more build-in “enterprise functionality” than NAV. That has not changed, except a lot of that functionality today is available for NAV from ISV’s, and more importantly Microsoft has (almost) solved their localization and upgrade issues.
With Dynamics 365 Business Central and Dynamics NAV 2018, then nobody should be afraid of implementing it globally in many different companies. It’s still the same perfect choice for the growing successful companies as Navision was 30 years ago.
Microsoft and BC are not quite there yet for all companies. That doesn’t mean you should wait, no matter if you are an existing global NAV customer, or you just consider using NAV in all your companies.
In my next post about global NAV implementations, I will come with some personal tips and tricks about how to get started or prepare your NAV project for going international. And about some of the many different questions you have to consider first. Plus a little about how to organize your project teams.
And which day other than the release of Dynamics 365 Business Central, would be better to announce which of the NAV blogs here on Dynamics User Group, who are the best or most popular? In the words of Microsoft, then the Business Central release is the third generation of Navision. So while we have never before made a “Top 10 Best NAV Blogs” award here on DUG, then it may also be the last time we do it. Next year it may have a different name.
There would be many ways to say which blog it is. I could go into Google Analytics see how many views each blog post has in here. Luc’s blog is number one. I could also get the number of views from Telligent Community, our web platform. That number is different, as it also includes view counts via RSS feeds and users who have seen it via their email. Luc’s blog is number one. But we also have to consider how many posts, so that we get views-per-post average. Still it is Luc’s blog.
A good blog is not only how many views a post or blog has. There are other ways to measure quality. Number of users who have manually subscribed to a blog, how many comments and how many likes must also be taken into consideration. It tells us something about how many of our members have interacted with the blog. Is it interesting enough to get users to interact.
But even with the score we now get: Luc’s blog is and stay number one. But I let the numbers do their talking.
Rank
Blog Name
Blogger
Post Count
Total Views
Score
1
Van Vugt's dynamiXs
Luc van Vugt
8
100606
28256
2
Mark Brummel
Marq
10
29068
5494
3
Waldo's Blog - Microsoft Dynamics NAV
waldo
35
69261
4885
4
Views on Dynamics 365 Business Central and NAV
Erik P. Ernst
27466
4181
5
Dynamics NAV Financials
Kerry Rosvold
8528
2172
6
Aphorisms about Microsoft Dynamics NAV
peikba
25
29482
2114
7
ara3n blog
Rashed Amini
9
15068
1856
Confessions of a Dynamics NAV / Navision Consultant
Alex Chow
11
14272
1785
Dynamics NAV urpok
Urpo Kotipalo
13535
1577
Kine's Info
Kine
1868
1374
As you can see on the score, the there is far down to blog number 2. This is the blog by Mark Brummel. When DUG first had the ability to host blogs, then Mark was among one of the first to sign up with one. Mark has a lot of subscribers going back to when DUG was his primary blog. Today his primary blog homepage is at https://markbrummel.blog, but his blog still exits here on DUG as a blog mirror. The same is the case with number 3. “Waldo’s Blog”. One of the first blogs here on DUG, today found http://www.waldo.be/. Number 4 is my own blog. Kerry Rosvold and her “Dynamics NAV Financials” blog takes the fifth place. Her blog is the only “mirror” which has never been hosted by DUG. My old friend Peik Bech-Andersen’s “Aphorisms about Microsoft Dynamics NAV” and Rashed Amini’s “Ara3n blog” take number 6 and 7. Number 8 is Alex Chow, also one of “the original blogs” now at http://www.dynamicsnavconsultant.com. Urpo Kotipalo and his Dynamics NAV urpok is number 9. The last on our list number 10 is Kine’s Info, Kamil Sacek, who also started blogging in 2006.
Congratulation to all the bloggers! I’m very happy to see your blogs here on DUG.
There are 40 different NAV blogs here on DUG. Half of them are hosted blogs posted by the blogger directly on DUG. This is a free service to all NAV community blogger we had since 2006, when we started using Telligent Community Server. At that time most of the NAV blogs where hosted by DUG, including Mark Brummel, Waldo, Alex Chow and Jörg Stryk etc. who all started their blogging career here. Later they have moved their blog to their own domain, but still have a mirror here on DUG, together with all their old posts.
For new NAV bloggers this is still the fastest way to get started blogging, without having to worry about website hosting, installation etc. They just have to start blog; the posts will be included in the aggregated blog roll and site maps and be visible in both site and Google search within minutes.
The other half of the blogs are “mirrored” blogs. Blogs where the bloggers host the original blog on a different site. What we see in the posts here on DUG is created via a RSS feed from the original blog. This functionality allows original blogs to be viewed here on DUG as well as other sites like Dynamics Community. Some blogs only publish an excerpt of the post in the feed. The result is that only a few lines is visible here on DUG. The user has to go to the blogs original URL, to read the post.
4 of the top 10 blogs are mirrored blogs, but all share the full content of their posts.
If you have a blog today you like to have shared here, or if you like to start to blog about Microsoft Dynamics (no matter which of the different products) and like DUG to host it for free, then contact me. Send me a message here on DUG. Or write it in the comments (of the original version of this blog post).
If was just taking a closer look at the different standard Extensions, coming with Dynamics 365 Business Central. They have become much more interesting, now that our Danish localization's are shipped as Extensions.
When taking a look from inside the client, then we get this view:
It's listing the Danish localization and other extensions.
I then used PowerShell and use Get-NavContainerAppInfo to see the actual list of Extensions in my container.
PS C:\Windows\system32> Get-NavContainerAppInfo -containerName N12-21229-findk | format-table -Property Name, Publisher, ExtensionType, Scope Name Publisher ExtensionType Scope ---- --------- ------------- ----- Payment and Reconciliation Formats (DK) Microsoft ModernDev Global _Exclude_Late Payment Predictor_ Microsoft ModernDev Global Microsoft Pay Microsoft ModernDev Global _Exclude_ClientAddIns_ Microsoft ModernDev Global Tax File Formats (DK) Microsoft ModernDev Global WorldPay Payments Standard Microsoft ModernDev Global PayPal Payments Standard Microsoft ModernDev Global Essential Business Headlines Microsoft ModernDev Global OIOUBL Microsoft ModernDev Global _Exclude_AnonymizedDataSharing_ Microsoft ModernDev Global Sales and Inventory Forecast Microsoft ModernDev Global Payroll Data Import Definitions (DK) Microsoft ModernDev Global C5 2012 Data Migration Microsoft ModernDev Global
I first noticed this a couple of months ago after NAV 2018 was released and didn’t really think about it until now. It's not in the "regular" NAV, only BC.
Besides all the Extensions we can see in the Danish BC version, then there are three Extensions all starting with _Excluded_.
I’m pretty sure that we all can think what an extension called something like _Excluded_AnonymizedDataSharing_ could be, most apps have some kind of data sharing. I’m sure it’s harmless, but I really would like to see the source code for this extension. I would like to tell my customers, exactly what is running on their data. I am sure all customers and partners agrees.
The actual Extension .app files are also included in the Docker container, so it’s not that they are trying to do a lot to hide anything. Have not tried to debug the system to see what it’s actually doing, unless that part is also excluded.
The NAV 2018 releases used to have the source code, at least for some of the extensions on the DVD. But I would really like to see the source code for all the Extensions I recommend to my clients. When it comes to some of the Danish localization's, access to the source code is very important, as Microsoft’s way to do it often is different from the way many customers use it.
Yes, you can use the same “trick” if you have Extensions your customers/users should not be able to see. Or remove. Because that is really the only reason I can see, why they would want hide some extensions from the list in the client.
And for that purpose, then I can think of a couple of usages of this, especially with global implementations. Extensions which even the local admin/managers should not be able to remove.
It’s very simple to do.
When you name your extension, just make it’s name start with _Excluded_YouExtensionName.
Easy to test if you use the build-in designer. You will notice that it will no longer be visible in the client. But if you list the actual extensions installed with PowerShell, then it will include your _Excluded_YouExtensionName extension
The remaining question is now, how can I download the source code for the extension I just have been hiding? Or can I somehow make it visible again?
May you have a nice Easter, go find some eggs with your Kids, if you have any! If that is not something you "observe", then please still have a nice weekend, when you come to it.