Why You Should Set Automatic Cost Adjustment to Never in Dynamics 365 Business Central

Overview

This was one of the topics that came up frequently while working with users at the last NAV/BC User Group Summit at Phoenix.

Many people have different opinion to setup their inventory so costing is done properly. Naturally, knowing a few things on how Dynamics 365 Business Central (aka Dynamics NAV) inventory and how inventory costing works, I participated as much of these inventory costing discussions as I could.

One of the features that I always get in an intense discussion on is how the Automatic Cost Adjustment on the Inventory Setup should be done.

Arguments for Setting Automatic Cost Adjustment to Always

I do understand the desire to want to set this property to Always. And why not? Instead of running the Adjust Cost – Item Entries manually, why not let the system run the process every time? And I do mean Every. Single. Time.

Setting the Automatic Cost Adjustment to Always allows for you to have updated and accurate cost at all times. This sounds great!

Arguments Against setting the Automatic Cost Adjustment

It’s great if we can just talk about all the benefits and call it a day. But that’s now we work. Setting this property will come at a cost.

  • Performance – During posting, your users will experience delays. How significant this is will depend on how large your database is.
  • Locking issues – Dynamics Business Central will lock the ledger entry tables during posting of orders. In addition, it will lock tables when it runs the adjust cost process. Because of the stress on the performance above, the users will experience more locking problems throughout the day as people are posting. If you’re experiencing this now, try setting the Automatic Cost Adjustment to Never.
  • Allow Posting From Error – There are some instances where the adjust cost will want to post adjustments into prior periods. Depending on what you setup for your Allow Posting From on the General Ledger Setup and/or on the User Setup, you’ll run into these errors.

If you’re running a micro business with few inventory transactions, setting it to Always will make sense.

However, for a manufacturer or a high transactional volume distributor, you will cause more harm to your environment than not.

This is exponentiated if you’re using reservation or serial/lot tracking.

The Alternative

Instead of running the Adjust Cost – Item Entries process during every single transaction posting. Why not have the process run during off hours?

One of the first things we do for our client after explaining the importance of Adjust Cost – Item Entries is to setup the adjust cost process as job queue to be ran at night when the load on the system is light.

This will prevent locking up users as well as give the system a faster response when they’re doing their daily task. Who doesn’t want a system that’s responsive and allow you to do as much as possible within a shorter amount of time?

Conclusion

In every instance, I will set the Adjust Cost process to be ran automatically on the job queue. I want to give the user the best possible experience working with the system. Every delay causes frustration and we can all use less frustration in our lives.

Dirty Trick to Keep Your Customers Hostage

Overview

Through whatever reasons, the customers will want to work with one partner over another. It may be the lack of knowledge, lack of support, slow response, or whatever. The customer can freely choose who they want to work with in regards to Dynamics 365 Business Central (aka Dynamics NAV).

Of course for the Microsoft NAV partner that the customer is leaving in question, they do not like that. They want to keep the customer on and collect money without doing the work.

It also leads to hurt feelings from the partner in question. I would equate that feeling as being dumped by your significant other.

Nonetheless, one of the best “features” that’s not emphasized enough in the Dynamics 365 Business Central (aka Dynamics NAV) channel is that if the customer does not want to work with a particular company, they can freely choose another one without much problems.

You’re not dealing with Microsoft, you’re dealing with partners that work with Microsoft.

Old Trick to Prevent You from Leaving

There are a couple of dirty tricks that the industry employs to hold the customer hostage.

One of the oldest trick is through licensing. They sell you add-ons that are in the 30 million ranges that only THEIR company have access to.

Often times, the customers will not know they’re in a restricted add-on ranges, because quite frankly, when you’re getting into a new marriage, nothing can go wrong!

I’ve personally met with a few customers that ended up switching to a different ERP software because the previous partner wouldn’t release their code to other NAV partners.

What can you do? Threaten a lawsuit? Or did you read the print when you bought NAV from that company? If you did, did you understand what you were signing?

I fully understand why Microsoft does not want to get involved in these situations. The original selling partner will claim that their add-on is their secret IP and don’t want other people to “steal” it.

On the other hand, if the NAV partner suck or just don’t have the resource available, only the customer will suffer.

This topic should probably warrant a separate blog article since the question of Extensions comes into play. Basically any extensions can be treated like the objects in the 30 million ranges.

Dirty Trick to Prevent You from Leaving

If the customer refuses to purchase the partner’s add-on. The other way is to lock down the database.

How do we know this?

Recently, we worked with a new client that came to us because they didn’t like their previous partner. When we got our first modification request, I was horrified to find that we couldn’t modify any objects in the database.

This is even when I have the sysadmin role on SQL Server!

The error is:

The following SQL Server error or errors occurred when accessing the Object table: 50000,"42000",[Microsoft][SQL Server Native Client 11.0][SQL Server]You do not have permission to modify objects.

SQL:
UPDATE [NAV2016].[dbo].[Object] SET [Compiled]=0,[BLOB Reference]= NULL,[BLOB Size]=924,[Date]={ts '2018-10-11 00:00:00.000'},[Time]={ts '1754-01-01 17:37:53.955'} WHERE ([Type]=1 AND [Company Name]='' AND [ID]=2000000071)

Asking Around

Coincidentally, I was at a Dynamics 365 Business Central conference (Directions) where all of the best NAV experts are in one place for me to pick brains from.

When I showed this error around, everyone was stump and had no idea what’s causing this error. I even approach some of the Dynamics NAV MVPs and they asked the usual questions:

1. Are you sysadmin?
2. Do you have administrator on that computer?

No one had seen this error.

The Solution

Finally, Floyd Chan from Qixas Group gave me a hint that if he was devious, he would put code directly in SQL Server tables. More specifically, in the triggers.

Sure enough, checking the Triggers on the Object table in the SQL table, sure enough, we found this:

After removing the table trigger from the Object table, we were freely able to modify the database objects again.

Conclusion

Over the years, I’ve seen a lot of weird and questionable things.

This, to me, left a really bad taste in my mouth. Partners will go as far as locking down the database to prevent other developers on working with them.

I just want to put this out there so people will not have to suffer through this as well. Once is enough.

If this wasn’t figured out, I wonder what it would cost to have the original partner “unlock” the object table

Is Inventory Periods Needed to Control Inventory Posting?

Overview

Over the years, I’ve written a lot of articles about inventory and inventory costing. I realize there are some tools that I do not mention that are in the inventory module. This is not because I don’t know about them, it’s because I don’t think companies need them.

Everyone is super busy these days, the last thing people want to do is administrative work. I’m an minimalist when I help our clients setup Dynamics 365 Business Central (Formerly Dynamics NAV).

I believe we should take the simplest route in setup and configuration to get the company up and running. Why? Because the simplest route is usually the easiest route to maintain for the customer ON THEIR OWN going forward.

It’s easy for us consultants, who does this for a living, to recommend all of these cool functions that controls this and that. But what happens when the customer is live and actually using the system in their day to day operation? In addition to their daily workload, now they have to click some buttons in order to properly close?

The new ERP system is supposed to save us steps, not increase them. We, as consultants and developers, often forgets this important goal.

Remembering details to close out the period in the system should be, in my opinion, be kept at a minimum (none if possible).

Making the system more complicated to maintain is not good for anyone.

Let me get into why I’m picking on Inventory Periods…

Why Inventory Periods?

The purpose of the inventory period is to enforce the rule that no item transaction can be posted before the date on the inventory period that is closed.

In this example, you if the check mark for the field Closed is checked, you will not be able to post any transactions prior to 9/30/18 in Dynamics 365 Business Central:

Sounds good right? I mean why would you want people to be able to back date inventory?

Why Not Inventory Periods?

The reason why I don’t advocate using this function is because, as a financial controller or accounting manager, you’re job is already to ensure people do not back date to the prior periods that have been closed.

There are 2 ways to control this in Dynamics 365 Business Central

1. Allow Posting From on the General Ledger Setup

2. Allow Posting From on the User Setup

Both will prevent people from posting into prior periods. IN ADDITION, these functions extends out to other parts of the system that the users should not be back dating into, not just specific to inventory.

You can control who can/cannot post into prior periods with the Allow Posting From on the User Setup screen.

Why do an additional step of closing inventory periods when you already have premade functions that controls when the user can/cannot post into?

But Why Are You Really Not Using Inventory Periods?

Simple, error messages.

Quite simply, error messages freaks people out. I hate them and I suspect you hate them too.

To be able to close out an inventory period, you have to ensure the following:

  1. Run adjust cost, which what you should be doing already. (We typically set this up in the Job Queue so it runs automatically)
  2. Make sure there are no negative inventory. Technically, this shouldn’t happen, but it does.

Negative inventory is something the financial controller would’ve caught when they print their inventory reports for the management or auditors.

All of the restrictions that the Inventory Periods tries to manage is something the accounting manager is already doing in their standard operating procedure.

  • You have the Allow Posting From dates to control when people can back date to.
  • You should be running adjust cost already or it should be setup on the Job Queue to be ran automatically.

    Side Note:
    If users don’t remember to run Adjust Cost, I don’t see how they can remember to close the inventory period.
  • You should be printing inventory reports for management and would’ve caught and resolved any negative inventory problems. If your company does not care about negative inventory (some companies don’t), I doubt you’ll ever use the Inventory Period function anyway.

Conclusion

I do believe Inventory Periods have their uses in certain situations. I just haven’t been convinced yet.

More often than not, I walk into companies with elaborate setups, with Inventory Periods being one of them, that has not been used since the first 1 or 2 periods since the company went live.

Most companies using Dynamics 365 Business Central don’t even know they’re supposed to run the adjust cost process. Adding additional step of inventory periods will not help the situation.

Microsoft likes to add functions to keep track of functions. In my opinion, this makes the system and its maintenance more complicated, which nobody wants. Fortunately, this function is not mandatory.

Keep it simple! Don’t make your life hard!

Prevent Inventory Adjust Cost Entries from Back Dating

Overview

Hopefully, by now every company that uses the inventory module in Dynamics 365 Business Central (aka Dynamics NAV) knows that they MUST run the Adjust Cost – Item Entries process.

If not, please check out my other articles on the subject on how to properly care for the inventory module in Dynamics 365 Business Central (formerly Dynamics NAV)

Adjust Cost Back Dating Transactions

While asking companies to run the adjust cost process, some people will report that they experience unwanted entries made to the previous accounting periods.

Why? The reason is because the adjust cost process will always adjust to the date of the original sales transaction (unless specified otherwise).

For example, it’s 6/30/18 and you run the adjust cost process. If you haven’t run this process in a while, and there was a sales transaction that occurred in 3/15/18 that has not been adjusted yet, the resulting adjusting entry will be on 3/15/18.

This will cause problems if you’ve already closed the books for March.

General Ledger Setup – Allow Posting From

This is where the Allow Posting From field from the General Ledger Setup screen comes to the rescue.

If you set the Allow Posting From on the General Ledger Setup, any adjust entries that are BEFORE the Allow Posting From date will have same posting date as the Allow Posting From field.

In our example above, it’s 6/30/18 and you run the adjust cost process. In addition, you set the Allow Posting From to 6/1/18. If there was a sales transaction that occurred in 3/15/18 that has not been adjusted yet, the resulting adjusting entry will be posted on 6/1/18.

Conclusion

Setting the Allow Posting From should be done after you close the month out, NOT before.

I’ve seen situations where the user changed the Allow Posting From BEFORE the adjust cost was ran. So all of the adjusting entries were posted in the current period instead of the period that they should’ve been in.

Just little things to help make your life (hopefully) easier.

Why Your Inventory Valuation Does Not Match the Inventory Account on the General Ledger

Overview

At the end of every month, we will inevitably get some questions on why their inventory valuation figures does not match the G/L inventory account. We would investigate and find out why and provide solutions on how to fix them.

Some of the reasons are pretty common so I’d thought I compile a list of reasons why your inventory valuation does not match your general ledger, and how to fix them.

Note that this is not a comprehensive list, but it’s most common symptoms we’ve come across.

Did Not Run Adjust Cost – Item Entries Process

The windows version of Navision aka Dynamics NAV aka Dynamics 365 Business Central has been out since 1995, and I’m still amazed how many NAV partners do not emphasize how important this function is to the end users.

No, setting up the Automatic Cost Adjustment on the Inventory Setup is NOT enough.

I wrote an article covering this specific topic here. The article was written in 2012 and it’s still relevant today. When I went to the Navision training class back in 1999, this was one of things that they stressed on when using inventory function in NAV.

Run Adjust Cost people! Do it before you run any inventory, costing, or financial statements!

Solution

What we do for our clients is to set it up on the Job Queue so it’s ran automatically DAILY. Don’t wait too long until this is ran or else it may take a long, long time to finish, which may lead to other problems if you’re running 24 hour shifts.

If you’re not setup to run this process automatically, run it manually! Just. Do. It.

You can read more about why this process is important on this link:

Why Your Inventory Cost is Wrong

Allow Direct Posting to Inventory Account on the G/L

This is a common one as well. This case usually happens when there’s a change in the accounting personnel, rules and procedures that was in place gets broken because of reasons.

This problem occurs when people posts directly into the inventory accounts. Here’s an example of what we found when we were analyzing why the inventory valuation didn’t match G/L entries (the amounts, document, etc has been changed to protect the innocent). The customer did not know why there was a huge variation between the inventory valuation report and what’s on the General Ledger.

Digging deeper into the ledgers, we found the entries that are causing the problem:

At some point, some within the company had allowed Direct Posting to the Inventory G/L accounts. Based on the Change Log, it was changed by their previous accounting manager for unknown reasons.

Solution

Set the Direct Posting on the G/L account for Inventory to OFF!

To look at and fix the entries that’s causing the problem, you’ll need to do the following:

  1. Go to the Chart of Accounts and bring up the G/L Entries for the Invenventory G/L Account
  2. Filter on the Source Code field with ‘<>INVTPCOST‘. You’ll probably need to show the column first.

The resulting entries you’ll need to determine what account you should reclass these entries to.

The INVTPCOST is basically the special source code that is used to mark the transactions that originated from the inventory sub ledger. If you have transactions that does not go through the inventory sub ledger, you’re inventory figure will be off.

Running the Wrong Reports

People will try to run the Inventory Valuation report and try to match it to the G/L.

The problem is, the standard Inventory Valuation report will include transactions not have hit your G/L yet (for example, items received/shipped not invoiced).

The better report to run is the Inventory to G/L Reconcile. This gives you a breakdown of what items are received/shipped not invoiced and include it with your on hand valuation.

In addition, you will need to run the Inventory Valuation – WIP report so it can match what’s in WIP to G/L.

Why is this important? Because your WIP account, and if you’ve turned on the Expected Cost Posting, will most likely be different G/L accounts. Make sure you’re matching all those up.

Solution

Turning on the Expected Cost Posting on the Inventory Setup will mitigate the problems stated above. So you can run the Inventory Valuation and match it up against your regular inventory and the inventory Interim account.

In the past, I’ve argued against turning on the Expected Cost Posting, however, I realize not everyone will become experts in NAV (nor should they need to be) and know what reports to run to close the month and go home. I’m still against turning this on, but I’m softening my stance on this.

I still believe people should truly understand the software so they know what reports to run and how to reconcile properly…

Relying on consultants is okay… Being self-reliant is better.

Inventory Posting Setup is Incorrect

Take a look at the following screenshot for the Inventory Posting Setup.

The inventory account is set to expense account. This means whenever you purchase or sell an inventory item with this inventory posting group for that location, it will go to account 70500.

This may be done in accident or on purpose, but when people reconcile inventory they’re typically going to only look at your inventory G/L accounts. When you go to your typical inventory accounts, you’ll be missing transactions entries for FINISHED Inventory Posting Group for the location GREEN.

Again, there may have been a reason this was setup in the first place. But I’m willing to guarantee that 5-6 years later or if there’s a personnel change, this will have been forgotten.

Solution

With NAV 2018 and Dynamics 365 Business Central, they’ve taken steps to reduce this problem from occuring by introducing the Account Category and Account Subcategory field on the G/L Account table. This means when you drill down to select an account, you can’t select a “wrong” account.

I would recommend hiring someone who knows what they’re doing to do the initial company setup for you. Why? Because most companies will only need to do this (hopefully) once in a lifetime. Learning and ins-and-outs of posting setup, especially when you only really need to set this up once, is not a good use of your time.

General Posting Setup is Incorrect

This scenario is similar to the above. Instead of setting the Inventory Posting Group (the balance sheet side) incorrectly, they set the General Posting Setup incorrectly.

This means everytime something is sold, it will hit the inventory G/L account instead of the sales account.

Same as the previous point, there may be a special (and probably good) reason for doing this, but over time, this knowledge will be lost.

Make anything complicated or weird and you’re almost guaranteed problems down the road. This concept applies to Dynamics 365 Business Central aka Dynamics NAV as well

Solution

Same as above. Just pay someone who knows what they’re doing to do this setup for you. The chances are, you’ll only need to do this once.

“But Alex, how do we know who says they really knows and who really knows?”

I’m not sure. I have problems identifying those who talk a big game and those who can actually deliver as well. I’m sure that’s a separate article at some point in the future.

Abnormal Posting Date

Basically, when you post a receipt on a date later than when you post the invoice. For example, you posted the receipt on 5/6/2018, but you post the purchase invoice with the posting date of 4/30/2018. The primary reason companies do this is because they want certain purchase transactions to occur in certain periods.

When you do this, the inventory valuation will not pick up this particular transaction if you run the inventory valuation as of 4/30/2018. Why? Because the inventory transaction occurred on 5/6/2018. However, the G/L transactions occurred on 4/30/2018.

Solution

The subject of Abnormal Posting Dates has been covered in an article I posted. You can read the article here.

Basically, you will need to run a supplemental report to balance out the inventory.

Conclusion

There are probably other common reasons, but these are just from the top of my head.

Note that these symptoms usually comes with follow up questions on why the inventory costing is weird. But that’s a topic for another article.

The bottom line is as long as you can reasonably explain what happened to the auditors, you will be OK. The key is understanding and setting up the system so it can’t fail you.

Game Changing Concept for Cloud ERP with Dynamics 365 Business Central

Overview

One of my personal complaints about any cloud based ERP software the inability to make customizations that your business needs to maintain a competitive edge.

The assumption of a cloud ERP software is that every business should be able to fully utilize the software as the software developers intended. But as we all know in the real world, this is NEVER the case.

The Cloud ERP Problem

As much as software developers tries to develop functions that covers all basis for the users of their software, there will be nuance for each individual businesses and how they operate. This is exponentiated by the fact that their customers will throw out weird curveballs that the user will have to comply, no matter what.

What do you do in these instances? You have make changes to the system or keep track of the changes manually.

In this day and age where products are expected to be ordered in the morning and shipped in the afternoon, there’s no way in hell you can expect the user to keep track of data manually. Worst, the company may have to buy or develop a whole different software just to supplement what the original ERP can’t handle.

Either way, it’s a recipe for disaster.

So now you have a problem, you have a software that is not robust enough to meet your customer’s demands without major workarounds and you have data and processes you have to comply with.

Yeah… It’s not a very good situation…

What Makes Dynamics 365 Business Central Different

One of the main selling points for the old Dynamics NAV (aka Navision) was the ability the user can customize anything they want. Because of this, some very beautiful industry specific and horizontal solutions have been developed without additional integration software. Why? Because it’s built INTO the software.

The ability to modify anything you want is both good and bad and is subject to debate, but at least it’s available should you need it.

When Microsoft announced they’re moving Dynamics NAV to the full cloud and renaming it to Dynamics 365 Business Central, a lot of people kind of assumed we’d be taking away the core essences of what makes NAV great, it’s flexibility.

Then when the product launched, I see this little surprise in the Extension Management screen. The Extension Management screen basically allows you to add/remove any features you want that’s available:

What?! I almost wet my pants when I saw this!

This allows you and/or your NAV partner to make custom extension modifications to your specific Dynamics 365 Business Central deployment!

Not only can you enjoy the great infrastructure of Microsoft cloud, but you’re also able to make customizations to your specific needs?! Microsoft, specifically the Dynamics NAV product team, really hit this thing out of the park.

Still Work to Do

Being able to upload extensions to modify your deployment still has it’s limits.

You will only be able to “extend” on the base application, but you will not be able to actually modify the base code. For example, you will not be able to change how Reservation system works in base NAV, you can only modify around it.

But still, it’s a GREAT first step!

Conclusion

Welp… I’m excited. Cautious, but excited.  Naaa.. I’m just excited…

The Curious Case of Dynamics Business Central Users

Overview

Microsoft has officially launched the Dynamics 365 Business Central. This is basically the next version of Dynamics NAV but can be deployed on as a subscription as part of your Office/Dynamics 365 portal.

Microsoft has tentatively stated that the on-premise will be released the summer of 2018. When that rolls around, you’ll have multiple options on where to deploy your solution. On this subject on deployment, it will be in another blog article.

I personally believe the implementation of the Dynamics 365 Business Central infrastructure is pure genius from Microsoft.

The infrastructure, on it’s own, is perfect. You can access your ERP data from anywhere in the world without having to worry about hardware and security setup. You don’t have to setup Azure and it’s practically plug-and-play. Furthermore, you get free upgrades and cumulative updates applied as they’re released by the Microsoft product team.

You basically require zero IT infrastructure spending to run your business.

What set this infrastructure apart is the ability for developers to create customizations that can be implemented through extensions. The extensions are like of like widgets or little apps that you can install for your instance of Dynamics 365. It’s like having an Apple phone with apps that you can download from the app store to enhance your experience with the phone.

The ease of deployment and the free updates from their subscription, in addition for you to download and install extensions from the Appsource store is the next best thing since sliced bread in the ERP world.

The Paradox of the Users for Dynamics 365 Business Central

While the infrastructure is perfect, there are some questions on who Microsoft believes are the profiles of the users that will be using the product.

Is Dynamics 365 Business Central catered towards micro-businesses (1-5 user companies) or is it catered more for small-mid sized companies (10-500+ users) as it traditionally is?

I’ve wondered about this since they introduced the concept to what was known as Dynamics 365 Finance and Operations Business Edition (RIP). There are some features that makes no sense for micro companies and there are some features that absolutely wrecks havoc on small-mid sized companies.

The Questionable

One of the promise from Microsoft is that they will make the software extremely easy to use. To some extent, they’ve really done quite a bit on the user interface. They’ve added very nice charts and statistics, in addition, the screens are extremely beautiful.

But let’s make a distinction on ease of use and dumbing down the software. Let’s take a look at the Item Card as an example to see what I’m talking about.

Note that this is only available if you set the User Experience on the Company Information to Basic or Essential.

If you look at the inventory item card, you’ll notice an icon next to the quantity on hand field.

If you click on it, a screen will pop up to allow users to just change any quantity for each location.

This means that anyone with access to the items can change the quantity without proper procedures and counts. Imagine running a mid-sized companies and allowing your users to be able to edit inventory quantities to any amount they wish.

I think this feature is probably more suited for the suited for mom and pop shop. Where you can just look at your shelf and adjust quantity on the fly.

However, on the same item card, you’ll notice something on the ribbons that’s promoted (meaning a large icon).

It’s the approvals/workflow management icons.

Now I run a small consulting shop. We have less than 10 employees. Here’s a typical approval/workflow request scenario between me and my wife boss:

Me: “Hey honey, can I xxxxxxx?”
Boss: “No.”

And that’s my approval/workflow request.

Do I really need to automate or systemize this? It’s a colossal waste of time to even opening an e-mail about it. I think bugging her with an e-mail will annoy my boss more and maybe that’s the point? But I digress.

The point is that in this one simple screen, you seem to have 2 features that cater to a very different clientele that will balk at each other. I think in this case, you really can’t please either sides.

Conclusion

Given the choice, I’d rather Microsoft focus the application to small-mid companies, like what the marketing message states. We’ve implemented micro-businesses using the old Dynamics NAV product with great success. I don’t see why it has to be different with Dynamics 365 Business Central.

To be fair to Microsoft, the product team has been pretty efficient on addressing issues within the application. I’m just not sure exactly if these “features” are counted as issues and what the logic behind implementing these in the base application is…

Addressing Performance Problem in Dynamics NAV and Dynamics 365 Business Central

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 toggle for setting this is nowhere to be found if you’re not using Dynamics 365 Business Central accessed from Office 365 Admin console.

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.

Changing Costing Method in Dynamics NAV (Dynamics 365 Business Central)

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:

  1. Run Adjust Cost – Item Entries
  2. Negative adjust all items to 0 as of a specific date (for example, 03/31/2018)
  3. Run Adjust Cost – Item Entries
  4. Force change the costing method using code without running validation (use RapidStart or get a developer should do this)
  5. Positive adjust all items back in on the day after step #2 (for example, 04/01/2018)
  6. 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.