Personalized Community is here!
Quickly customize your community to find the content you seek.
Choose your path Increase your proficiency with the Dynamics 365 applications that you already use and learn more about the apps that interest you. Up your game with a learning path tailored to today's Dynamics 365 masterminds and designed to prepare you for industry-recognized Microsoft certifications.
Visit Microsoft Learn
2020 Release Wave 2Discover the latest updates and new features to Dynamics 365 planned through March 2021.
Release overview guides and videos Release Plan | Preview 2020 Release Wave 2 TimelineWatch the 2020 Release Wave 1 virtual launch event
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Upcoming TechTalks
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.
Business Applications communities