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 localization's 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.
Disclaimer: This was written in April 2018, and this is not yet how it is done as of May 2021. The task of turning all localization's into extension's is a much bigger task than anticipated and will only happen when the new localization functionality is required, or when the functionality otherwise requires major updates/refactoring.
As I said the web client is not good enough for existing power users. Some of the most used shortcuts are missing. But as I wrote, I'm working about a blog post specifically about the web client.
The backup/restore issue when we talk cloud only, it's kind-of like when they removed the FBK option in NAV 2013 R2, when they introduced tenants. And I'm sure that they are working very hard to solve this issue.
As to the source code of Extensions, then all the source code for Microsoft's Extensions is on the DVD and on Docker. If you refer to source code for Extensions, that you buy from 3rd party ISV's, then that's more or less business as usual. I have always tried to go way around any add-ons which contained locked objects. And I will continue to do. It's important for the way we work with NAV.
As to overview over the objects (I guess you mean in the extensions), then I've already seen a post or two on that. Think that peikba has one on his blog.
I think we will have less need for NAV developers in the future. At least if customers are starting to use Extensions from AppSource. So I expect that there generally will be less customization's (both if we talk C/AL and AL). But as you and I know, then it does take a bit longer to add a field to a page and a table, using AL, than it takes in C/SIDE. And while I'm sure that we will also have the more "geeky" NAV developers, then we see more consultants, who can do "prototypes" with the Designer, tweak it up a bit on VSCode to get the customers acceptance, before handing it over to a hard-core developer to make all ends meet.
Knowledge about accounting and how businesses work is imperative for being a good all round NAV consultant and developer. And still it is not news that some partners hire developers who didn't know accounting or business. I have met lots of NAV developers who really don't know what debit and credit is. Some of them learn, most of them moves on to other more exiting jobs outside of the NAV world.
I'm not scared. Neither personally, nor on behalf of Navision. I'm rather optimistic in fact. Which is not the same as I find that everything in this release is great, nor that I would recommend anyone to upgrade/move to Business Central. But neither is Microsoft. Right now there is no upgrade option from NAV to BC. Don't think we will know it all until the fall release. /Erik
I do agree with you most of your saying but what about all of the drawbacks ?? Just to mention a few:1) Advanced filtering does not exist?2) No way of doing a backup/restore - (so having testdatabases etc is impossible)3) Missing the shortcut-keys in many of the places4) Total lack of object overview of the objects5) The missing source code of extensionsThe list is way longer than this. Don't be totally blind to all the negative sides. Yes there at loads of cool stuff application wise, development snippets, vscode as editor.. Becoming a Dyn/NAV developer is going to be complicated. All the gui-development-help with eg. shift F4 is gone. Finding properties, controls etc are going to be a total nightmare and the learning curve is not good.The future will end op in "core developers" not knowing anything about accounting, because of the complexity of devleopment - and that is scarying...Palle A