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.
Yesterday 3/12/2018, MSDynamicsWorld leaked that the name of what we used to know as Dynamics 365 'Tenerife', would be Microsoft Dynamics 365 Business Central. Initially this was not to have been released until Thursday 3/15 at Directions ASIA in Bangkok, but the news spread fast.
So fast that Microsoft's Alysa Taylor, the general manager for Business Apps and Strategy, officially announced the new name today.
It is everything what Dynamics 365 for Financials/for Finance and Operations, Business Edition was. That means a modern cloud based software-as-a-service solution, fully integrated to Office, PowerApps, Microsoft Flow and Power BI. But it is also a full Microsoft Dynamics NAV, where the previous version only had a subset of NAV.
Dynamics 365 Business Central will be generally available on April 2, 2018, in 14 countries – United States, Canada, United Kingdom, Denmark, Netherlands, Germany, Spain, Italy, France, Austria, Switzerland, Belgium, Sweden, and Finland, purchased through Microsoft Cloud Solution Provider (CSP) partners. Australia and New Zealand will be generally available beginning July 1, 2018.
Please notice that the announcement does not apply to Microsoft Dynamics NAV. At least not now. The Spring 2018 release, will still be called Dynamics NAV. But according to Microsoft's "roadmap to Tenerife" then after NAV 2018 R2, Business Central will be the name for both on-premise and cloud will the same. This may be in Q4, or it may be later. No announcement of this so far.
So right now, nothing is changed for customers with Microsoft Dynamics NAV. You may relax again!
You may have noticed that the future name of Dynamics NAV/Dynamics 365 “Tenerife” is going to be Dynamics 365 Business Central. But what does it really matter?
In “Navision’s” 34-year history, then Navision was only (a part of) the name for 12 years. From 1994 to 2006. In some countries (like Denmark, Germany and the US) only from 1998 to 2006. Just as long as it has been called Dynamics NAV. The name has changed many times since 1984. For those of you, who haven't been around since the start, then here is a list of all the different names.
The first "Navision" was released in 1984. PC-Plus was the name, symbolizing an accounting system (plus = calculating) for personal computers. PC-Plus was only a single user system for DOS, but the overall design would be clearly recognized even today, by both users and developers.
In 1987 when PC&C released a multi-user/LAN version of PC-Plus, it was named NAVIGATOR. It was distributed by IBM to Danish BusinessCenter Partners and was generally known as IBM-NAVIGATOR. The brand name Navigator was used in Denmark, but it was also used by many other software packages (i.e. Netscape Navigator) and a protected brand in many countries. So it would not be possible to used internationally.
In 1990, after the release of Navision version 3.0, local distributor's are started in Germany and Iceland. In Germany they use the name (Navigator) as in Denmark, but in Iceland it is branded as Fjördiner. Not long after offices opens in Spain and the United Kingdom. Here the name Navision was used for the first time.Avista
When expansion into the US begins in 1994, they didn’t name it Navision, but instead choose to brand it as AVISTA. According to their general manager in the US, Rene Stockner, they didn’t like Navision as it sounded negative (the NA sound). AVISTA on the other hand sounded happier and like a fiesta.
In 1994 the first version of Navision for Microsoft Windows was released. Here they added Financials to the name, to differentiate it from the DOS version, which continued to be sold and maintained for some years. Around the same time the company name PC&C, was changed to Navision Software. The different local brand names stayed around until the release of Navision Financials 2.0 in 1998.
When Navision releases their first manufacturing module in 2000 it is sold as a separate solution, build on top of Financials and is branded Navision Manufacturing. They do the same when they release Navision Advanced Distribution. So suddenly Navision was no longer one product, but different products. To reflect this, when version 3 was released, they introduced another new name Navision Solutions, to be the common name for different versions of Navision.
After the merger with Damgaard Data in 2000 Navision Software now becomes NavisionDamgaard. A name that doesn’t stay around for long. Already in 2001 they remove Damgaard from the name. Now the company is just called Navision. And it is decided that Damgaard’s other products are also to be called Navision. Axapta becomes Navision Axapta and Navision Solutions becomes Navision Attain. In fact this happened before Navision Solutions was released in most countries. 3.01 carried the new name.
Attain only stays around for 2 years. When Microsoft acquires Navision in 2002, it becomes part of the Business Solutions division. Navision Attain 3.60 was the first version to get the new name Microsoft Business Solutions-Navision, at least in documentation/marketing. 3.70 was the first version where the product was renamed.
Microsoft started talking about 'Project Green' in 2003. This was an initiative to merge the platforms of all their Business Solutions products: Navision, Axapta, Great Plains and Solomon into one single system.
'Project Green' is a multi-year Investment from Microsoft Business Solutions aimed at delivering the next generation business application on the next generation of the Windows operating system code-name 'Longhorn'. Project Green is crucial to the strategic goal of Microsoft Business Solutions (MBS) to become the industry leader in the global business application market by 2011. 'Project Green' is about delivering a breakthrough in business applications based on a ground-up redesign of the architecture and application functionality.
In 2005 Microsoft announced that ‘Project Green’ would be named Microsoft Dynamics and that Navision from 2006 would become Dynamics NAV.
Microsoft officially stopped talking about ‘Project Green’ as a concept in 2007, as it had damaged sales a lot. Customers were waiting for the new merged product to come into the market.
Looking at the different versions of Dynamics today, then it’s clear that the work continued internally. Without ‘Project Green’ then things would have looked a lot different today.
The first product name for the SAAS offering of Dynamics NAV 2017, was released in October 2016. It was a version with only a subset of the full NAV functionality.
Microsoft Dynamics 365 for Financials, Business Edition was its first name. Business Edition as opposed to the Enterprise Edition, where Dynamics AX now were called Dynamics 365 for Operations, Enterprise Edition. The names led to great confusing in the channel and among potential customers. Enterprise customers couldn't understand that there were no "Financials" application for them.
The name was changed again in 2017 to Dynamics 365 for Finance and Operations, Business Edition, just as AX got the same name, just Enterprise Edition.
In October last year Microsoft announced 'Tenerife' to be released in the Spring of 2018 for the SAAS segment. The spring version of Dynamics NAV 2018 (R2) would be the last version using the Dynamics NAV name.
This all leads us up till now. We now know that going forward ‘Tenerife’ (and implicit NAV) is going to be named Dynamics 365 Business Central. For now it’s only going to be the SAAS version, the on-premise version will remain Dynamics NAV 2018 until the next major version. Then the name will the same. If Microsoft will follow the same release patterns, then this could be expected to happen in Q4 2018.
I must admit that I initially didn’t like. But the previous Dynamics 365 name “Microsoft Dynamics 365 for Finance and Operations, Business Edition” simply didn’t work either. Dynamics 365 Business Central is way better when it comes to that.
And although I would have preferred that they just renamed it something like Dynamics 365 NAV, then I do understand why this name would not work for Microsoft. If we look at all the Microsoft brand names, Office, SharePoint, PowerPoint, Word, Dynamics etc., then neither Navision or NAV follows the same naming patterns. Business Central on the other hand does follow the same patterns.
One of the problems with the Business Edition vs. Enterprise Edition, was that it wasn’t really clear that it was very different systems. The names were too much alike and caused confusions to both customers and partners.
I believe that the new names will make Microsoft’s branding a little clearer to the customers. If you buy D365 Business Central, then what you get is really a Navision.
Here on DUG, then I expect that the current Dynamics NAV user group names will stay as-is for some time. Then gradually it will change to become a NAV/Business Central user group. The challenge is going be how to make it clear for both NAV and Business Central users and professionals that nothing really has changed. It’s going to be business as usual.
But right now, then we are still waiting for the official announcement of the name change and more details about the new road ahead. That’s going to happen March 21st 10AM CET on the virtual event Microsoft Business Forward.
Update (3.13.2018 5.05PM CET): It's official. Microsoft has just posted a blog post announcing Dynamics 365 Business Central.
---Read more/sources: History of Dynamics NAV/Navision: https://dynamicsuser.net/nav/w/navdev/6/the-history-of-dynamics-nav-navision Overview of the different versions: https://dynamicsuser.net/nav/w/navdev/130/dynamics-nav-names-and-versions
One of the goals of Microsoft is to turn all their many localized versions into Extensions. They are taking their own medicine so to say.
Just as many customers find that upgrades are a pain when they have a lot of customization's, so does Microsoft. Every time there is a new release, they also have to go through the same pains when upgrading their 17 localization's from W1. Something they do for all their cumulative updates for NAV 2015, 2016, 2017 and now NAV 2018, every month. Even with a lot of automation, both of the merging process and testing, then this is a time-consuming task. Even for Microsoft.
Coming from Denmark, I will be one of the first to meet this in live action. As the first county, most of the Danish localization's have been turned into extensions.
The only change not already an extension is our national OIOUBL e-Invoicing, which is required by anyone invoicing our government on any level. It counts most of the total changes in the DK version. But all our other smaller specialties are turned into extensions.
We have three Danish localization Extensions. A Payment and Reconciliation Formats (FIK), Tax File Formats and a Payroll Data Import Definitions extension. The first support our national FIK banking payment standards.
The interesting here is not really the functionality, but how did they do it? How did they turn their customization into an extension? We can know, because they have also shipped the source code for these extensions. A partner or customer could make their own extended versions of this functionality. Possible with some work arounds, as they still use functions not available for the rest of us.
If you like me have embraced the new Docker container images, then you will have to go to aka.ms/navgetready to download the DVD from there. In the DVD of the Danish file we have FIK, ImportDKPayroll, VATReportsDK, each with the compiled *.APP file ready to publish (already published in a demo database) and a source folder containing “the source code”.
FIK is more interesting. It has a little of each, fields, pages import/export formats. So let’s look at that one first.
I created a new project in VSCode, copied the content from the source folder in my new AL project folder. Then I copied in the launch.json for my server. I have tried some of the other “example” extensions on the DVD before, so I didn’t get disappointed too much when I found out that this is still the case. It does not compile. A lot of “The type of Method ‘x’ cannot be used for ‘Extension’ development” errors. So, for now it will just serve as an example.
The extension as one table 13624 FIKExtension, with a two fields. Code and IsUpgraded. No pages for this table, as it is only used by the setup codeunit. Same codeunit I was really interested in. How did they move the data from the old database fields into the extension?
I had expected a subtype install codeunit with the a OnInstallAppPerDatabase or OnInstallAppPerCompany. But neither are found.
I had also expected that they had been using the “Obsolete Fields” functions, which allows you too remove custom fields over several releases, by first marking them Obsolete and the reason, for then moving them later.
That’s not how its done here. What they did do was to remove the custom fields in the Upgrade toolkit fob. Here for example the fields are moved from the Vendor table to an UPG Vendor table.
The app in it’s codeunit 13655 “FIK Demodata”, has an event subscriber for Codeunit 1 OnInstallAppPerCompany. This subscriber call the DataMigration codeunit, where the function move country fields in the 13650 range of the upgrade tables, to the same 13650 range in the apps extension table.
local procedure MigrateVendorFields();
Obj: Record AllObj;
Vendor: Record Vendor;
if Obj.Get(obj."Object Type"::Table,104038) then begin
if UPGVendor.FindSet then repeat
if Vendor.Get(UPGVendor.field(1)) then begin
until UPGVendor.Next = 0;
A rather simple process. One could easily do it the same way with any other custom change, where you’ve added new fields to an existing table. The example above is changed a little, as it did use the Object table. But that’s not available for Extension development. Instead here we can just as well use the AllObj table. It is worse with some of the other codeunits, who uses a lot of functions not available for Extensions!
The FIK extension handles special Danish FIK payment reference codes. It’s a payment standard with roots in the Giro payment code. A short for common payment card, which was a standardized OCR readable payment slip, which was commonly “pre-printed” on invoices. Today the cards as such are mostly gone, only remaining requirement is the payment reference. It could for example be +71 <000007545022202 +12120108< - a combination of payment type, a reference with checksum and the vendor’s Giro number.
There are no reports in the extension, so the next question was how NAV prints the reference on the invoices? Using events of course. In the sales invoice header table, we have two event publishers: OnGetPaymentReference and OnGetPaymentReferenceLbl.
A major part of the extension are the Danish bank import and export formats. These were introduced together with the Data Exchange framework and NAV 2013 R2, as a feature focused on their Dynamics C5 customers. Here C5 2014 was Microsoft’s first (second if you count Navision Entrepreneur) attempt to create functionally downgraded and simplified version of Navision. And no integrated online banking would be a major point of failure for most customer in the look for a low end SMB product.
In the Extension, these XML format definition files are inserted from text labels.
These labels are inserted into TempBlob and imported as XML. An ok solution for a once off, but personally I wouldn’t like to debug format errors in the code.
This Extension does not contain any fields or tables. It does contain a number of page extensions which strangely removes the visibility some of the fields required for EU Intrastat reporting. I do know that the same fields have always been hidden in the DK version, just never knew why.
It setup a number of EC Sales List/Intrastat VAT report configurations.
Again, this Extension can also only server as an example, it cannot be build into your own app. It’s main functionality is to export the special versions of the EC Sales/Intrastat reports. Old fashioned fixed length flat files. Which of course are exported to FILES. Something we are prevented from doing from VSCode today. But my guess that Microsoft’s internal license does not come with the same limitations as my normal NAV developer license.
The last extension is again much simpler. No fields, no tables, two pages, a codeunit and an XMLport. Plus a test codeunit. Data exchange formats are not defined using locked labels, but by directly “hard-writing” the definitions into the stream, line by line. I’m very happy to see that problems with our Danish special characters ÆØÅ, no longer have any issues. Our Ø (oe) used to give codepage issues.
The Danish version of NAV, despite these three Extension, is still loaded with localization's. Still 187 localized objects, compared to 245 in NAV 2017.
Microsoft also have to turn the OIOUBL e-Invoicing functionality into an extension. Personally, my hope was that they would build something around the PEPPOL functionality. Both are OIOUBL based, but with the big difference that PEPPOL allows for both exporting AND importing documents. The Danish OIOUBL functionality only allows you to export documents. And with it’s currently over 180 changed objects, then it’s current functionality is very “invasive”. Even if it’s changed into an Extension, then it would still have fields and functionality all over the place.
I hope that reason this is not released as an extension by now, is that Microsoft are refactoring this functionality before releasing it.
Personally, I'm thrilled about these new extensions. Not so much because they are special or fantastic. But because they allow me easily to remove them again, or simply not install them.
Most of my Danish NAV clients would never use NAV's own banking functionality. Instead they use the add-on which more or less have been the Danish NAV standard since the DOS version, where it was called NaviBanking, now Payment Management from Continia. Only reason I have had not to recommend PM to anyone was that it was very invasive (touched a lot of standard objects). But soon (I have heard) they will also have PM as an extension. So really no need to have the FIK extension, PM does the job much better and more automated.
Same with the still to be released OIOUBL Extension. While this is truly a most have for companies doing business with the government, then a lot of companies do not. And it have plastered pages like sales orders and invoices etc. with fields.
But hhe future direction is clear. Some years down the road, then we will only have the World-Wide version. Localization's are "just" Extensions, either coming from Microsoft or ISV's.
From someone who have worked a lot with international NAV projects this is sweet music in my ears. Where dealing with global core databases, localization's and translation's used to be something which both required long country by country analysis and development, then going forward that's not really going to be that important. We would be able to have one global database based on W1. And with country based tenants we would be able to load the local extensions we needed.
Right now this is only the DK version, but by the time we get into the spring of 2018 and the next release, then a lot more country localization's will have been turned into Extension.
When looking at the three Danish extensions, then it’s obvious that Microsoft so far have not adopted any internal standards for neither object or file naming, nor have spent much time on the code.
It really looks like it has been three different companies or teams who have created each of them.
Most actual code is just copied from the previous country into the new app. No refactoring or code clean up. Not even spelling errors have been fixed. These becomes very visual in VSCode, if you have a code spell checker extension installed.
Back in 1987, 30 years ago, the programming language Pascal was the first programming language I learned in college. I had just started programming my own accounting system using Pascal, when I first saw PC-Plus, the mother of NAV. It was love on first sight. I instantly knew I didn't have to program it myself, it was already there.
Two years later, when collage was over and I had my first Navision job, there was no more programming Pascal for me. I felt I had enough of programming in college. Meeting Cobol in second year was a mixed experience. So my first NAV job was as a project manager/consultant/trainer (I had worked with accounting before college). IBM Navigator 3.0 had just been released a few month before and included an integrated AL language which was based on Pascal, so I couldn't keep my hands away for long. But except for web design html/css etc. for DUG's website and a few simple C# control add-ins, then I stayed within C/SIDE's and C/AL's safe walls.Until now It's like being back in the first years of college. Back then it was the new Turbo Pascal compiler, created by Danish Anders Hejlsberg, brother of Thomas, NAV software architect since 2003).
The last 2 months I had the time to really get started with Visual Studio Code and the new AL Extensions. I am almost as enthusiastic as I was back then. It's like I have gotten back the same joy in programming, that I had with programming Pascal in college. AL has finally become a real programming language.I see the beginning of a great future for our old Navision.
Have you ever considered using “off-shore resources” for your projects? If you work in “the west” or should we just say in countries with an hourly NAV developer rate of USD +100, then most likely you have. Especially if you work on large projects.
But have you ever been in a project using these so-called off-shore resources? And how did it go?
My friend Peik has done this many time and have written a blog post about how to outsource your development tasks, especially to off-shore resources. Peik gives some tips on how to make your outsourced projects a success. They primary focus on:
I completely agree with all of his comment’s and tips. If you decide to outsource your projects, then that’s a list you need to save and remember.
Now that we know a little about how to do it, then the big questions is, if you should outsource your projects?
If you read Peik’s post, then you also understand that there are a lot of things you need to focus on and give a lot more attention, compared to only using inhouse/sourced resources. You need a very experienced project manager/architect and often much more time on design, documentation and QA. Don’t expect that it comes easy. Face-to-face meetings between the inhouse and offshore teams are very valuable, not just via Skype with video.
My personal experience has primary been gained by working as the ERP solution architect on large international NAV projects. So that’s in a customer environment. Peik’s recommendations are based on his experience in the partner channel. But they are just as valid when used by a customer managed inhouse NAV project.
In the offshore projects I have worked in, we estimated about 15 minutes per outsourced hour for extra project management, communication and quality control. And that’s where you have “your own” team of more or less fully booked developers.
If it’s a one-time project of less than 200-300 development hours, then I would say forget it. And still it could easily take you at least 2-3 project of that size, before you would start seeing the results your expected.
If you are a customer, and your use a Dynamics partner who are using outsourced developers, then make sure to check out references first. If your project is the first they are outsourcing, then I would be scared.
The most successful tasks I have outsourced are within development. And here as already said, primary larger, pre-designed coding tasks. But the more you know your offshore team the smaller task you can assign them. If you have a large user base and a lot of user support, then that could also be an area, just watch time differences.
You have to make sure that your team stay's the same as much as possible. Each time a new developer is assigned to your team, then expect the same delay in productivity, as if you hired a new in-house developer. Here you need to follow the same advises as if you are managing your own employees. If they get bored working on your project, they are more likely to go work for a different company. And much easier if they just have to switch tables.
In the same way, don’t be afraid to tell the company hired them through, if some the developers you were assigned does not live up to your expectations after “a few tries”. Just as you would do if they were your own employees.
As Peik also points out, documentation is very important. It always is, but here even more so here, as it is often the primary source of knowledge transfer. You need to extra carefully document everything. It’s not enough to write a simple requirement specification in a few lines, like just forwarding an error message from a user. If you want things to be done in a special way, then you need to say how. If you have a Skype video meeting, always remember the minutes with any decisions or any follow-up points.
If you are in a company with large enough projects to consider outsourcing, then you probably already have always spend quite a lot of time documenting the processes and standards to be used. At least that’s been my experience as an ERP solution architect. But make sure that your outsourced team are aware of these standards. They should be as easy to use and as close to “Microsoft standards” as possible.
Left is then only to enforce the standards, verify that they are followed. Have a strict code review, before merging any changes with your core system. Give a clear feedback, Skype is often much better than just an email.
If you are not just doing a few projects, but to work with a good full-time team, over a longer period, then yes.
I cannot recommend it unless you give it 100%, as it will take more than one project to get and see the benefits.
To have success with outsourced resources you need to treat them exactly like you would treat any other in-house employees. Which is a lot harder, when they are not in your physical office, but 1000’s of miles away. If you take your time and extra efforts, then you may have great team of relatively low cost Microsoft Dynamics developers.