Chapter 9. Implementing Functional Changes

The world changes constantly; therefore, the demands for every company that's interested in keeping doing business will need to change with it.

A company may require functional changes on their Microsoft Dynamics NAV or Microsoft Dynamics 365 Business Central implementation as more and more demands from external parties they do business with emerge. The new project may not be an implementation project, but some of the steps that have to be taken on an implementation project also apply. There are some other things to take into account and this chapter will explain how to handle a project like this one, by analyzing the actions to be performed using four examples of a functional change in an installed and operative system:

• The Requisition Worksheet
• Fixed Assets
• Item Tracking
• Extending a customized functionality

General guidelines

Depending on the requirements, the functional changes will be different. Some will just require a few actions to complete the change; others may require many actions, which are not just related to the functionality being changed. There are a few things to take into account when implementing a functional change. In this section, we will provide some general guidelines. Later on, we will follow the guidelines for all the examples in the chapter.

The following diagram shows the general steps that should be performed to implement a functional change:

The steps in detail are as follows:

 

1. The first step is to clearly define the functional change.
2. Think about how this change will affect existing Microsoft Dynamics NAV or Microsoft Dynamics 365 Business Central functionalities and whether those functionalities will need to be changed as well.
3. Define a list of all the actions that will have to be completed to be able to implement the functional change.
4. Choose the right time to implement...

What is a functional change?

A functional change in a Microsoft Dynamics NAV or Microsoft Dynamics 365 Business Central implementation involves using an application functionality not used before, or to change the way certain application functionalities were used in the past.

Note

From the introduction of Microsoft Dynamics NAV 2016 to Microsoft Dynamics 365 Business Central, the development model has changed. As already said, it is not recommended to change the standard of the product as done previously with the old versions of Microsoft Dynamics NAV (in Microsoft Dynamics 365 Business Central SaaS it is not possible to change the standard code). It is mandatory to use the extension model supported by the events for development; in this way, it is possible to preserve the standard product's code and easily remove the customizations installed in the system.

Here are some examples of some new functionalities that a company might want to explore after these ERP systems are implemented.

Scenario...

Interactions with other functionalities

If you have to make a functional change in a Microsoft Dynamics NAV or Microsoft Dynamics 365 Business Central implementation that has been working for a while, the questions that should be answered are as follows:

• Does the functionality being changed (or that will begin to be used) have interactions with other functionalities?
• What are those interactions?
• How will the other functionalities have to change? 
• How many of these features could have an invasive impact on the standard product with a view to installing updates?

The Requisition Worksheet

The Requisition Worksheet has interactions with the Purchase functionality of Microsoft Dynamics NAV or Microsoft Dynamics 365 Business Central, since purchase orders can be created as the result of running the Requisition Worksheet.

However, it also has interactions with items (as they hold the replenishment parameters that the Requisition Worksheet will use, and since the Requisition Worksheet will check this functionality...

Writing documentation to implement changes 

Several actions will have to be performed to implement a functional change. All of them will have to be written down so that everyone is aware of what has to be done for the new functionality to work properly. Documentation on developments is fundamental; it is not possible to develop and modify without tracing what has been done, and it is always advisable to have the test reports of the new implementation signed, so that no one can contest what has been done.

All Microsoft Dynamics NAV and Microsoft Dynamics 365 Business Central developers should always write documentation about changes.

The Requisition Worksheet

Let's examine the Requisition Worksheet implementation. The actions that have to be performed are as follows:

1. Study the different reordering policies Microsoft Dynamics NAV and Microsoft Dynamics 365 Business Central offer.
2. Determine which replenishment parameters apply to each reordering policy. Notice that some replenishment parameters...

Choosing the "right time" to release and implement the changes, and analyzing the risks

It is important to choose the right time to make a functional change on an existing Microsoft Dynamics NAV or in Microsoft Dynamics 365 Business Central implementation. Some functional changes can be deployed at any time, others not. Some of them may require a lot of time and no users to be working and changing data; you may want to choose a weekend for that. Some others could be implemented at any time, but to keep a better track of the time at which it began to work differently, you might want to choose the start of a fiscal year or the start of a month.

The important thing is to think about it, analyze it, and choose the right time for every functional change implementation, as a wrong choice could cost you dearly. It is always useful, in cases with complex procedures, to draw up a risk analysis in order to have a way out in case of problems that could arise.

The Requisition Worksheet

Using the Requisition...

Planning the change

Good planning (and actually sticking to it) is something you always need. As we have seen, some implementations may require a lot of actions to be carried out some of them before the new functionality is implemented, some during the implementation process, and some others right after the implementation process is completed. Some implementations can even be done progressively, so they could last weeks or even some months.

Everything has to be planned and scheduled so that all the work needed for the implementation of the functionality is ready on the chosen date to go live.

Take the to-do list written in the previous section and determine the following for each action:

• Determine when the action has to be performed:
  • Before the implementation date
  • During the implementation process
  • After the implementation process is completed
• Estimate the time that will be needed to complete the action.
• Establish relations between actions (some actions have to be completed so that other actions...

Changes in Microsoft Dynamics 365 Business Central

I would like to mention that the Microsoft Dynamics 365 Business Central on-premises and SaaS environments are different. For the Microsoft Dynamics 365 Business Central SaaS environment, we must remember some restrictions:

• The SaaS environment is always on.
• Only the web client exists.
• The standard cannot be changed.
• It's possible to develop only with Visual Studio Code.
• The extensions must always be used to load the customizations.
• In multitenant environments, it may be more costly and time consuming to implement the changes.
• If a problem emerges, we do not have a physical server in front of us.
• We do not have access to the SQL Azure database.
• The times of implementation, release, and application of the changes are quite different (more expensive).
• If something is not successful, it could be a problem.

For the rest, the concepts seen earlier (as general concepts) are valid and applicable for both Microsoft Dynamics NAV and Microsoft Dynamics 365 Business...

Summary

In this chapter, we have seen that Microsoft Dynamics NAV and Microsoft Dynamics 365 Business Central implementations are not only for companies that have never used these ERPs before and will start doing so. An implementation can also be done for companies already using Microsoft Dynamics NAV or Microsoft Dynamics 365 Business Central. They will not be complete implementations, of course, probably just the implementation of a new module or functionality. There are some things to take into account in these kinds of implementations. We have talked about them using different examples.

In the next chapter, we will be talking about reporting in Microsoft Dynamics NAV and in Microsoft Dynamics 365 Business Central, and how to analyze the data stored in the database.