My journey in the world of consulting using Microsoft Dynamics 365

Monthly Archives: March 2018

Overview

If you’ve recently upgraded to Dynamics NAV 2017 or later versions, you will have undoubtedly noticed that the new version of Dynamics NAV (or Dynamics 365 Business Central) is incredibly slow… It’s so slow that it took one of our customers that’s using NAV 2017 3 minutes and 38 seconds to open a customer card.

Yes, the customer really measured this. And yes, before they upgraded, opening the customer card is instant.

Note that this blog will include Dynamics 365 Business Central as I didn’t see them improving the standard codebase in the release.

EDIT: Microsoft has released a fix in their monthly Cumulative updates to address the performance problem. Ask your NAV partner to implement these hotfixes for you if you’re still encountering issues with poor performance.

Eye Candy

The problem is all the eye candy that Microsoft tries to implement into Dynamics 365 Business Central that caters to the small/micro businesses, or at least make the demo of the product irresistible.

For some odd and strange reason, Microsoft strongly believes the same customers that currently using Dynamics NAV are the same ones that are going to be using Dynamics 365 Business Central.

I’m not sure how we can tell Microsoft that this is not the case. They firmly believe they know the customer better than the channel.

An Example

Let’s take a look customer card in our example and let’s see why it’s so slow. Note that this is one of many screens in the software that has performance problems. I’m just highlighting this page for the purpose of this article.

In order for Microsoft to make Dynamics 365 Business Central look appealing in demo environments and to encourage companies to sign up on first sight, they really have to include all the bells and whistles. And I do mean all the bells and whistles including, but not limited to:

Charts and Graphs to display data visually. Why? Because it’s pretty.

Factboxes that quickly brings information to you

Quick statistics to give you an overview of the data without having to have that extra click

Dynamic control on pages – Hiding fields and really dumbing down the user interface

Dynamics CRM and Office connection and integration

Let’s take a look a the customer page in the demo environment in Dynamics 365 Business Central:

Looks great right? You have a really quick statistics of how the customer info. And when you navigate around in the demo environment, it’s fast.

Single Codebase

This is the screen if you use the Dynamics NAV (Dynamics 365 Business Central) on any rendition other than from the signup in the Office 365 Admin Console.

If you looked closely, you’ll notice that the Statistics FastTab is missing.

Apparently, in order to keep Dynamics NAV and Dynamics 365 Business Central on the same codebase, Microsoft just hid whatever is not applicable.

Why It’s Slow

There’s a problem with that… When you just hide the control, it doesn’t really prevent the code from running.

If you look at the customer card in the Development Environment, you will see the Statistics FastTab has the Visibility function set to FoundationOnly.

The problem is the code is written in the worst way possible with no regards for optimization.

It’s doing calculation on massive amounts of data with every time you click on something on the customer card. Good for small datasets (<1000 records), problem if you actually use the software to manage your business.

This means any time a user does something on the page, it’ll run this calculation, over and over and over and over again. Think about your customers that has a 50 GB database, worst, you’ll notice a slowdown with customers running a 1GB database.

The Fix

One would think the simple fix is to just remove the controls from the page. Wrong… The cause of the slowdown is not on the display itself (although the Dynamic Control does slows down performance), it’s the code that’s running in the background.

The code you need to take out is in the triggers of the page.

And here

Removing code on the OnAfterGetRecord and OnAfterGetCurrRecord triggers dramatically improves the performance of the customer card.

Note there are a lot of other things we have to remove from the customer card to make the performance acceptable for the end user. But I will stop here for now.

The Extension Problem

So how do you do this when we’re going into the Extension world? Extensions will NOT allow you to remove base code, so you’re stuck with whatever crap Microsoft stuffs in there. Tested or not.

Looking at the amount of code in the customer page, I’m actually shocked on how all of this got past Quality Control at Microsoft.

Whoever thought it was a good idea to do a lot of rendering and processing at the page level?

You’re asking for performance problems when you’re rendering a large amount of data. This was one of the first thing they taught us at the Navision development class back in 1999; don’t put code on forms/pages.

Conclusion

This article is just focusing on a single page, the customer card. If you look at Sales Order page, another one of the pages that a lot of companies access frequently, it has the same types of problems: too much code on the pages.

Again, a lot of what they stuff in there is nice for demo environment with small datasets. You’ll notice performance problems real quick as your data set increases.

Perhaps this is an opportunity for developers like us to publish an Extension on AppSource. Basically redo NAV pages so people can actually use it.

Overview

Every once in a while, a company will want to change their costing method from whatever they have into something else for whatever reasons.

The official way of changing the costing method for any items in Dynamics 365 (Dynamics NAV) is to basically zero out the item and create a new set of item numbers with the new costing method.

However, doing this may not be feasible because you end up losing all item history, in addition, depending on how much history you have, renaming item numbers will take a long, long time.

The Unofficial Way

There’s an unofficial way that Microsoft does not promote for companies to change the costing method. This is understandable because if the user does not follow the instructions, there’s no way Microsoft can support all of the different scenarios that comes up.

The Preparation

Before the company can make such a change to the costing method, the following tasks has to be done:

All Receipts needs to be invoiced

All Shipments needs to be invoice

All Production consumptions needs to be output

All Transfer Shipments must be received

All Service shipped/consumed must be invoiced

Remove all reservation entries in the system

All Drop Shipment orders needs to be removed

Run Adjust Cost – Item Entries process

The biggest problem that companies run into is documents that are “stuck in the middle”, basically, shipped/received not invoiced. By not having a clean break, if you were to proceed with the costing method change, you will never be able to tie out your inventory valuation to the General Ledger.

The Method

Here’s what you will need to do in Dynamics 365 (Dynamics NAV) in order to convert to a different costing method:

Run Adjust Cost – Item Entries

Negative adjust all items to 0 as of a specific date (for example, 03/31/2018)

Run Adjust Cost – Item Entries

Force change the costing method using code without running validation (use RapidStart or get a developer should do this)

Positive adjust all items back in on the day after step #2 (for example, 04/01/2018)

Run Adjust Cost – Item entries

Then done, you’re done.

The Aftermath

After the costing method change is done, back dating of inventory transactions cannot be allowed.

This includes any item charges that may apply to receipts posting in the previous periods!

For example, if we change the items from FIFO to standard on 03/31/2018, no additional postings for these items on or prior to 03/31/2018 should be made. This will need to controlled through the Allow Posting From on the General Ledger Setup and the User Setup.

In addition, revaluation of inventory should not be done prior to 03/31/2018 as well for the items. Doing so may cause irreparable damage on the inventory value and will cause your inventory ledger to not match your G/L.

Conclusion

The method described above is not recommended by Microsoft. I think this is because there are many ways things can go wrong if not done properly.

Having said that, we’ve done this for many of our customers without problems. Strict controls on when the posting is allowed must be followed. If done properly, changing costing method is really not that big of a deal.

Overview

As more of our clients are going live with NAV2017, we’re finding some inconsistencies on the features that were working as we thought it should, verses the way it’s working now.

One of such feature is the Job Queue function. Note that this only applies to NAV 2017, they’ve since rewrote how this process works in NAV 2018.

The purpose of a job queue is to run processes automatically at a preset time. For the process to run continuously, you would need to set the job to run as Recurring.

If you do not set the job queue entry as recurring, it would delete the Job Queue Entry because the process is only a one time deal. This feature was added because the users are now allowed to schedule their reports using job queue. Some reports/processes only needed to be ran once for the user.

The Problem

After the clients went live, we started noticing the jobs that were set to recurring was being deleted as well. This confused the hell out of us because there were nothing on MSDN that talks about Job Queue Entries that are deleted when it’s set to Recurring.

Digging into this, the problem is on Codeunit 453 – Job Queue – Enqueue. More specifically, a function called RemoveFailedJobs.

Looking at this, the system will remove any Job Queue Entry records that it runs into an error. So this means that at any given point if your mission critical job fails, it’ll simply remove it from running ever again…

Yes, I could’ve setup notifications to warn you if something failed… I didn’t need to do this extra step before..

This is a steep contrast to how Dynamics NAV Job Queue ran before. In addition, this is not how NAV 2018 behaves now.

Conclusion

You can comment out the code completely or just add the following code:

JobQueueEntry2.SETRANGE(“Recurring Job”,FALSE);

Doing this, the process will leave the jobs that are set to Recurring alone.

I’m not sure if Microsoft has address this in the later CU releases for Dynamics NAV 2017, but if not, I would highly recommend you modify the code so your mission critical processes does not simply disappear!