Ways You Are Sabotaging Your ERP Implementation. Going Parallel.

Overview

A continuation of an article published last time.

This is another one of the biggest causes of the owners/management causing the demise of their own ERP projects.

Going Parallel

Most proponents will state that going parallel is the safest way to ensure that if the new system doesn’t work, you can safely go back to the old system and not have any loss of data.

This sounds really good on paper, it’s actually abominable in practice!

Here are a couple of reasons why:

  1. Not enough time in the work day for the user to do twice the work. Imagine your work day, now do it twice with the same amount of time. Notwithstanding the time restriction, you’ll also be bored as out of your mind. Twice.
  2. The process is different from the new system vs the old system. When you implement a new system, processes will change. Keeping 2 separate processes using 2 different software systems will confuse the crap out of anyone.
  3. If anything is missed, which there always will be, reconciliation is a nightmare. Oh your number is off by $89.42? Good luck finding that.
  4. People will always work in an environment where they feel safe. Not because the old system is better, but because it’s familiar.

From my experience, when companies go parallel, they fail.

BURN THE SHIPS

In 1519, Captain Cortes told him men to “Burn the Ships” after he landed in North America. He knew that if his men (and himself probably) had a means to go back, they would not be committed on giving their all to survive in the new land.

The same thought can be applied to your ERP implementation. Telling your people that implementing a new ERP is important, but give them an option to do things the way they did before, they will always go back and do things they feel more comfortable.

Now you may be asking “but Alex, what if the new system doesn’t work?” The answer is simple, don’t go live until you’re ready. If your preparation is crap, you will fail anyway.

The next question you may be asking is “but Alex, what if we encounter problems with the new system?” There’s no instance where there are not problems when you go live. As long as you make proper preparation, the problems that arise should not be major. Any competent Dynamics 365 Business Central (AKA Dynamics NAV) partner or developer should be able to knock them out quickly.

Preparation

Before you burn the ship, it’s your job to ensure every business process can be, at the very least, replicated in the new system. This is part of your preparation before going live.

Having a smooth transition to a new ERP software can’t be completed with just thoughts and prayers, it needs meticulous testing, simulations, and feedbacks.

Be aware that it’s not going to be 100% smooth when you cut over to the new system. There will always be problems after go live. The important things are the major known kinks are resolved.

There shouldn’t be an instance where major problems that comes up when you turn on the switch, then someone seriously messed up.

Conclusion

Take the page out of Cortes’ playbook. Burn the Ships. Have your people focus all of their attention and resource into making the new software work in your organization.

Ways You Are Sabotaging Your ERP Implementation. Part 1

Setting Unrealistic Live Dates

Overview

Typically in an implementation, there will be a lot of moving parts. A lot of things has to go right for a successful implementation. If any of the key tasks don’t go right, no matter how small the task is, will cause havoc or delays for a company trying to go live.

I can assure you that every Dynamics 365 Business Central (aka Dynamics NAV) consultant/company will tell you that they’re an expert at Dynamics 365 Business Central / Dynamics NAV. Whether that’s true or not and how to detect if they’re full of hot air is probably a subject for another article.

Even if you have the most qualified and reliable NAV partner, projects may still go wrong because of the decisions made by the company that’s implementing the software.

I Want It Now

It’s unfortunate (or fortunate) that we live in a society where instant gratification is the norm. You want something? Order it on Amazon in the morning and get it delivered in the afternoon. These type of service puts a lot of burden on the supplier on making sure everything goes right.

When the owners of a company is often under pressure to make the necessary changes so they can meet the demands (realistic or not) of their customers, they often want to see the same turnaround time (realistic or not) from the projects they initiate.

Setting Unrealistic Live Dates

For some managers, the idea seem to be to set a high expectation for the project. Even if the project doesn’t get to the expectation, at least we’ll be better than the original expectations should be.

One of these types of decision is deciding on a live date. In an effort to make people place a sense of urgency on the implementation, management will set an unrealistic (or optimistic) go live date. The employees or consultants will often be too polite, shy, scared, etc to call out this decision.

As I mentioned earlier on this article, going live requires a lot of precise tasks to be completed, we can hurry those tasks or skip them. But shortcuts will often come back and haunt you. This is especially true in an ERP software implementation.

What always ends up happening is one of the following:

  1. The company goes live without being ready
  2. The live date gets postponed

Of the 2 scenarios that can happen, if #1 happens, the implementation will always lead to failure. From my personal experience, rescuing customers that went live before they’re ready never really recovers. We end up having to re-implement them to get the company back on track.

Hopefully, the management has the courage to decide on option #2 and call a stop and re-evaluate.

In either of those 2 cases, the damage would’ve already been done.

Culture of Expecting Failure

Usually, when a company misses their first go live date, they will miss their subsequent go-live dates as well.

Why? Because the people are already used to failure. Their consultants or the management has promised them that they’re going to go-live, you can almost hear the employees say “Yeah… Right…”.

When I walk into companies that has missed their go-live date a couple of time, it’s almost like walking into a vacuum of demotivation. When you even talk about going live again, you’re just met with an overload of cynicism and doubt.

Prevention

Set realistic live dates and stick to it. It’s your responsibility to call out BS if someone tries to talk crazy about a live date.

How we typically plan out a customer go-live is to pick a date the customer would like to go live, then work backwards to see if that’s feasible; considering holidays, vacations, buffer time, etc. If it’s not feasible, we tell them right away, even if we get scolded at.

Of you’re in charge of the implementation, be ready to say no to unrealistic requests to go live or hitting certain milestones; even in front of a team of management. Yes, they will question your expertise, your resources, your abilities, even your character.

Just remember hurting one person’s feeling is better than having the whole company suffer.

Why the Idle Client Timeout Won’t Work

Overview

Just a friendly reminder (or reminder for myself) that in order to get the Idle Client Time to work properly.

Make sure you change the Keep Alive Interval to something greater than Idle Client Timeout.

If you set the Idle Client Timeout to something LESS THAN Keep Alive Interval, the client will not disconnect automatically if they’re idle.

The Default

When you install Dynamics 365 Business Central (aka Dynamics NAV), this setting will be defaulted to 2 minutes. So if you want to kick people off if they’re idle for 5 minutes, make sure you remember to change this default setting.

Conclusion

Another one of those GOTCHA things when setting up the software…

Using Gmail Account with SMTP Setup with Dynamics Business Central / Dynamics NAV

Overview

Not all customers uses Office 365 as their e-mail. The other popular option companies use is G Suite from Google.

When you’re trying to setup the SMTP Mail using Gmail accounts in G Suite, you may encounter this error:

The mail system returned the following error: “Failure sending mail.
Unable to read data from the transport connection: net_io_connectionclosed.”.

Resolution

The problem is with how Google detects which application it deems as less secure. If you’re using an application it deems less secure, Google will refuse the connection.

What you’ll need to do is change your settings on Gmail.

On the Less Secure App access, you will need to turn this on.

Conclusion

Now when you go back to your Dynamics 365 Business Central (aka Dynamics NAV) application, you will be able to send the mail from the SMTP settings.

From 5 Months to 5 Minutes

Overview

Even though we’re at the age of the internet, a lot of companies still print hard copy catalogs.

If you work in any one of these organizations, you’ll know when it’s catalog season, it’s becomes a very stressful period in that the company has to put together all of their item attributes, pricing, description, pictures, etc in one “packet”.

This packet (along with your website) is your first impression to customers and prospects that may want to do business with you. Sometimes, your first impression is your only impression so companies will get it “right”.

Not only do you have to organize everything together, the information needs to be put together and shipped off for printing. The time constraints is furthered because a lot of US companies ship their catalog overseas so you will need to compile everything togehter even earlier.

The Problem

Here’s sample list of tasks for people creating catalogs:

  • Consolidating the item data
  • Figure out pricing
  • Consolidate the images
  • Make sure the right description is there
  • Figure out the Specifications
  • Get the right pagination
  • Categorize the items

Of course, this is only a partial list. To all you folks responsible for creating catalogs, I feel you bro.

To add on to the problem, in most cases, the description, spec, images, etc are never in a central location for the marketing/art department. Making the job more difficult.

Not only that, people have to deal with disjointed data. The catalog data is often not tied to the ERP/order entry system. So whoever is looking at the ERP/Order Entry system often will need their catalog next to them to flip through the actual page on what the customer is talking about.

So wouldn’t having all of the data in one central place be wonderful? Yes. Yes it would be.

Fed Up

So one of our clients, fed up with the amount of work they have to put into creating catalogs every year, decided to make a change. Of course we were tasked with finding or creating the right solution for them.

In addition, they have to create “mini catalogs” every month and every quarter.

The Challenge

As we looked for an add-on, but was most were too expensive and not scalable or customizable. They are not too thrilled on having to rely on a proprietary software. In addition, they needed to pay an annual enhancement for a product that didn’t do everything they wanted.

So having add-on or a separate piece of software for catalog was out of the question.

Putting everything in a central place like Business Central (Dynamics NAV) makes a lot of sense. However, even if you have all of the data in Business Central (NAV) there’s another problem. RDLC.

Let’s face it, RDLC is a disaster. Despite multiple complaints from partners and multiple releases, RDLC is still absolute trash. You will still run into memory issues, it’s still slow as hell, it’s still tough to make changes.

To print >5,000 page catalog with images and data from all over the place in one go? Har Har…

So having add-on or a separate piece of software for catalog was out of the question. Putting everything in a central place like Business Central (AKA Dynamics NAV) is good, but RDLC is trash. What to do?

Figure It Out

First we needed to create an infrasture to house their item categories and the text descriptions of the catalog. That part of it was straightforward since we know Business Central (Dynamics NAV).

The next challenge was to actually print the thing out. RDLC simply didn’t work. Period.

It couldn’t handle the number of records that we’re going to pass to it, and it couldn’t handle the images we’re going to send to it.

Any developer that has worked with RDLC will tell you that trying to make a RDLC look good on a form type report will require a sacrifice of your first born on a specific day to the software Gods. Not to mention the margins and the page breaks…

The Solution

Our prayers seems to be answered with a simple tool from a company in Europe. ForNAV.

Note that I’m not getting paid to promote their product, infact, I’m paying them to use their product…

Not only was it easy to create the catalog, it could handle everything we threw at it.

Here’s the result printing from with in NAV:

The customer was extactic! This effectively cut their time to put together the catalog from 5 months to 5 minutes!

This is what they created for their catalog using NAV:

Not just printing catalog, this allows the customer to utilize the same report to print their weekly and monthly promotional catalogs at a fraction of the time.

Conclusion

The whole concept of ERP is to save you time and make processes more efficient.

Somehow, in the pursuit of integrating different silos of software togther, large software companies are losing sight of one simple goal why people use software in the first place; to make our lives easier.

I do miss those days where we can have one software with one interface where we can do what we needed to do and go home… But the industry and the customers wants to go where they want to go.

By the way, I’m still waiting for MSFT to trash RDLC.

Changing Protection Level to Boost Performance

Overview

Just a quick note about boosting the client performance for full Windows or RTC clients for customers using Dynamics 365 Business Central (aka Dynamics NAV).

This was brought to us by one of our customers that is looking for ways to reduce the lag for their users using the full Windows client.

One of the newer features in Dynamics 365 Business Central (aka Dynamics NAV) is to allow different connections to the data within NAV. This means security is a big issue since you do not want random programs to connect to your financial data.

Changing Protection Level

When you set the Protection Level as the default (EncryptAndSign), every data packet being sent and received are encrypted and authenticated to ensure you are who you are.

This means that when the users are viewing, for example, the customer card, if you disable their user on the Active Directory, they will get kicked out immediately. Yes, even if they’re not sending and receiving any data.

This may cause additional traffic to your data packets being sent and received as it requires additional layers of encryption and signing to ensure the data is legitimate as it ensure the person accessing the data is legitiment.

For users using NAV locally within the company where the server is hosted locally, these kind of security may not be needed.

For our client that’s running Dynamics NAV on-premise, changing Protection Level to None has significantly boosted the Windows client for the end users.

IMPORTANT NOTE!

You should only change this for users that are using NAV locally and are using Windows Login.

Your security is important and you should definitely consult your local security expert before changing this.

Proceed at your own risk!!

Addressing Inefficient Business Processes

Overview

Addressing inefficiencies in any company is a crap shoot.

Often times, the management of a company will have a discussion with us to discuss their challenges. The conversation in these meeting usually leads to how can they address their “mess”. For example, their inventory quantities are always wrong.

It’s not like the managers have nothing better to do than to discuss these issues with consultants. These types discussion are usually forced on their company because their business environment is changing.

Their competitors are offering things like same day delivery, integrated e-commerce, real-time shipping notifications, inventory availability, customer self-service, etc. All in an effort to entice their customers away from them. These managers feel like they have to do something or they will be left behind.

The Lie

Most companies believe (or are sold) that if they upgrade or move to a new ERP or CRM software, their efficiency problems will magically go away (it’s a lie).

The analogy I like to use is visiting someone’s home. If the person is messy, the house will be a mess. It doesn’t matter whether they live in a small apartment or a large mansion.

The common belief is that if they live in a house that’s a mess, if they move into a larger home, it’ll be magically be not-messy. Unfortunately, that’s never the case. If you live in a small apartment and it’s a mess, moving to a larger space, it will still be a mess; but in a larger space.

The Cost

The technology portion is always where misunderstanding occurs. One of the justifications for a company that stays with inefficient processes are because they thought those type of systems are only for large companies. They do not have the budget for these expensive and complicated systems.

For example, one of the common problems that plagues every company is inventory. To resolve negative inventory in their system, the topic about using wireless scanners will come up.

The goal is the warehouse employees can be on top of inventory quantities and report discrepancies immediately as they see fit. The common rebuke will typically be “that’s for bigger companies, not a small company like us”. In reality, it’s not… It’s really not just for big businesses.

Back in the 90s and the early 2000’s, the technologies used by larger corporation had a high price tag. This means if you’re not a large corporation, you wouldn’t be able to enjoy a full ERP software without spending a chunk of your money.

For a large company with deep pockets, they can withstand these expenses, even if it doesn’t work out well. For a smaller or medium sized company, that may be a big risk.

Now, the functionalities enjoyed by large corporation are pretty well replicated for the small and the mid-market. This means you can be a micro-business and can still use the same functionality that large corporations uses.

In fact, the functionalities difference offered to large corporations and small companies are getting more narrow with every release. Case in point, Dynamics 365. You can be a 5 user company or a 500 user corporation, they can all use Dynamics 365. They can all use warehouse/shipping automation tools, they can all use dashboards, they can all integrate e-commerce to their system.

The Real Cost

The real cost of addressing the mess is the management of the company.

Of course, me being the terrible salesperson, pointing this out to them usually gets me in all sorts of troubles… But I digress…

In our example, if there is not a culture or process in place to have accurate inventory, then it’s not a priority. Doesn’t matter what system is in place, in the inventory will be a mess.

Just by implementing a warehouse system in place will not magically make your inventory accurate. It requires people to be on top of recording their work using scanners.

If there’s a culture of “I’ll just move this item here and record it later cause, you know, we’re busy”, your warehouse management system will ultimately fail.

That’s the funny thing about technology and automation is that if your process is efficient, it will make you a lot more efficient. But if you’re process is not efficient, technology and automation will make your operation a lot more inefficient, faster.

Conclusion

In the end, technology will only faciliate your existing process. What I always recommend people to do is to get their house in order before they consider automating it.

Don’t get me wrong, switching new systems is a perfect time to reorganize your process, but if you’re not fully onboard and get the key player’s buy in, it will turn into a nightmare really quickly.

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!