Six months with extensions – Goodbye to the last DotNet

Six months with extensions – Goodbye to the last DotNet

This year in March, I wrote about the upgrade process I went through with my own company’s Dynamics NAV 2018.

I ended up with one extension consisting of:

  • 9 Codeunits including the Install Codeunit
  • 7 Page Extensions
  • 16 Pages
  • 1 Query
  • 4 Reports
  • 5 Table Extensions
  • 10 Tables

And a number of changes directly in C/Side:

  • 1 Query because the query from extensions could not be used in Generic Charts
  • 1 Codeunit containing the functions using DotNet
  • 1 Change to a standard table (Table 36) because of an error in the standard NAV code, because it was not possible to post an invoice or and order with both an item line and a G/L line on the same document.

Experiences from 6 months of rolling upgrades

During the year, I have rolled up to several of the Dynamics NAV 2018 cumulative upgrades implementing new functionalities and unfortunately also fixed multiple errors in the standard application.

Upgrading to Dynamics NAV 2018 CU 5: the sales lines started to give the error: Another user has changed the sales line. Just entering the Line Type, The Item No. and the Unit of Measure code. Therefore, entering a line you needed to
leave the document window and reenter to continue.

Upgrading to Dynamics NAV 2018 CU 6: Now the sales line just disappeared after entering the Unit of Measure code. I found out the line reappeared if I pressed F5.

CU6 also introduced a really annoying feature: Entering a description on a G/L line on a sales order or a purchase order the G/L No. entered was changed with no warning. It turned out (after a little digging) that a new feature was introduced, identifying other accounts wit almost the same Name, and if it found one, the account was switched with no warning. E.g. I have an account with the name Software, but want to post software to another account = not possible .

This latest feature has been fixed since then so it will only switch if the G/L No. is blank. Thank you for that.

The last feature I found, is on the Transfer Order Lines. It you select an Item No. but another item with the same description exist, with an Item No. lower than the one you selected, you will get a warning that another Item exist with the same description. Honestly, that feature should at least be introduced as an option in the warehouse setup. The warehouse employee should not be bothered with that decision after entering an item number either manually or by scanner.

Where do I report errors like that?

During the year I tried to report these little hick-ups to Microsoft, but that was almost like a scenario from a Kafka novel: Every where I reported the issues, I got the same messages:

Reporting errors or issues in the standard application is not here. These resources are for specific uses:

https://aka.ms/bcideas

    This is only for NEW ideas for the Dynamics BC application (and only for the cloud solution)

http://github.com/Microsoft/ALAppExtensions    This is only for developers and only for requests for new events in the standard application.

http://github.com/Microsoft/AL    This is only for developers reporting errors in the new development environment.

Then there are these:

http://blogs.msdn.com/nav            The Dynamics NAV/D365BC Team Blog

https://community.dynamics.com/business/b    The Dynamics BC community

Both of these are only for information.

Therefore, the question remains: Where do I report errors in the standard application?

Some say that I should buy Service Requests and report through PartnerSource, but we all know that nobody does that because it takes to long tome and nobody wants to pay for reporting errors.

Expansions improvements

Other than these annoying little things the upgrades have performed smoothly. Over time I have expanded the solution so it now consists of:

  • 12 Codeunits
  • 16 Page Extensions
  • 18 Pages
  • 1 Query
  • 3 Reports
  • 6 Table Extensions
  • 11 Tables
  • 2 XML ports

In C/Side the only changes are:

  • Table 37 Sales Line
  • Table 39 Purchase Line
  • Report 50020 Account Schedule Landscape (It didn’t work as an extension)
  • Codeunit 1255 Match Bank Payments
  • Page 1251 Text-to-Account Mapping

Goodbye to DotNet

Notice that my one codeunit with the DotNet is no longer there.

Previously, I had to use a DotNet component to retrieve mails from a mail server. This month I called the support and asked if they had an API that I could use instead, and the answer was yes.

Now I could use the new functions in AL the retrieve my orders from the web-shop.

Therefore, I reprogrammed my GetWebOrders function to use these, and it worked like a charm. So now I can keep that in my extension as well.

I have compiled two objects to demonstrate how I did:

The objects download currency rates from a web service at the www.floatrate.com site and displays them in a page based on a temporary table. They can be downloaded here:

http://ba-consult.dk/downloads/ImportFromWebServices.zip

Conclusion

But there are some concerns for both developers and Microsoft:

Consultants and Developers:

  • No more changes to the base application
  • Think hook points (events) in everything
  • Watch out for dependencies
  • Use prefixes
  • Consider number series
  • Store source code externally (Escrow service)
Microsoft development:

  • No unpublished functionality changes (Why don’t you reintroduce the Review Boards)
  • All new functionality must be activated through setup
  • Quality must be improved (we cannot fix your errors anymore)
  • Implement a more accessible error reporting system a la GitHub for the AL developers

One thought on “Six months with extensions – Goodbye to the last DotNet

Leave a Reply

Your email address will not be published. Required fields are marked *