We all know the situation: A customer needs a copy of the live environment to run a number of tests. Or it could be that a new Test/Development Environment must be made periodically. Often it is necessary to update the Test Company with the latest data. Therefore, it is necessary to create the live database and restore it with a different name. Having done that, it must be prepared so that data from the test company cannot be confused with data from the live company.

The preparation can involve quite a number of things:

Change Company

The company must be renamed in Companies.

Rename the Company Name

The company name must be renamed in Company Information so that all sender addresses on external documents clearly reflects that is origins from a test company.

Change the System Indicator

I also change the System Indicator to tell the user that they are in a test environment, both by Changing the text shown in the corner to show the word TEST clearly and to show the date the test company was based on, this will help the users later running tests in the system.

Giving this signature in the right corner of each page in the Windows client:

Redirect printers

It is also necessary to redirect the printers so picking lists are not suddenly printed in the warehouse or production orders in the production department. Even worse would be that external documents like purchase orders, sales quotes or orders accidently are printed and sent by mistake.

Freight integration

If the integration with the shipping company is automated, then it is advisable to make sure that it is disabled in the test company. Otherwise, you will face some very angry truck drivers.

Stop Job Queues

There is no need to keep all jobs in the Job Queues running, like automatic posing of invoices or printing of invoices. So stop all the jobs that will give problems in a test environment.

EDI flow

If the company communicates with external partners with EDI or the like, it is necessary to redirect all documents to a test folder.

Prevent Electronic Invoices

Many companies send invoices electronically, the paths that are uses for sending and receiving invoices and credit memos must be changed so nothing is sent or received by mistake.

Electronic Payments

Payments sent and received are usually initiated manually, so the chances for mistakes are few. However, it is best practice to change all paths so the payments are not imported or exported to the bank by mistake.

Captured Documents

Capturing purchase invoices are commonly used in companies, and the paths used for the captured documents must be changed.

Inter-Company Flow

If the company a part of a larger organization with an automated IC-flow, it is very often desirable to make sure that there are two IC-flows, one for the live transactions and one for the test environment, otherwise it can be difficult to test the Inter Company functionality. In any case, the functionality must be redirected so the flow either stops or runs on the test environment instead.

Master Data Replication

If the company a part of a larger organization with an automated Master data replication flow, it is just like the IC Flow desirable to make sure that there are two replication flows, one for the live replications and one for the test environment. The functionality must be redirected so the flow either stops or runs on the test environment instead.

Automate the tasks

These are only a few of the changes that needs to be done. Others could be integration to production facilities, machines, BI databases or CRM systems. The list can be endless.

Now the customers will not be happy if they have to call a consultant to perform all these tasks, not to mention the actual backup/restore functionality every time they need a new test environment and even worse, to remember all the different tasks that needs to be done. Secondly, the number of databases that must be copied in a large organization can make the task so complex that errors will eventually happen.

Therefore, I have automated the creation of the test environment with my customers. It comes in two or three parts depending on which Dynamics NAV version the customer runs:

1. The backup of the live database and restore to the test database

   This is not covered here in detail but it can be performed in many ways:

• Manually from SSMS
• Automatically with a SQL job
• Automatically with PowerShell (SQL Server 2012 & SQL Server 2014)

1. The Company must be renamed in the test database. If the customer run Dynamics NAV 2009 or 2013, it must be done manually, but in Dynamics NAV 2013 R2 or 2015 there is a PowerShell CmdLet for exactly that
2. All the rest must be performed inside the company in NAV. Here a codeunit is built to handle all changes. If the customer run Dynamics NAV 2009 or 2013 it must be run manually, but in Dynamics NAV 2013 R2 or 2015 there is also a PowerShell CmdLet for to execute the codeunit

If the test company is in the same database as the live company, a simple PowerShell script can be run to insure that everything is done properly. This will work in Dynamics NAV 2013 R2 and 2015.

This is the script for real Men; it removes the company NO QUESTIONS ASKED. A gentler version could without the –Force parameter on the Remove-NavCompany command. This will politely ask before removing the company.

The CodeUnit

Creating the codeunit basically, involves a lot of “hard code”, here is an example:

			Http://b-a.dk