Moving Customizations from Dynamics SL to Dynamics 365 Business Central

One powerful feature in Microsoft Dynamics SL is the ability to create custom screens or modules. Those custom screens become a problem when moving from Dynamics SL to Microsoft Dynamics 365 Business Central. If the functionality that necessitated the customizations is still important (likely so) and BC doesn’t have an existing method to replace it (also probably the case), then a BC customization to replace the SL one will be needed. This is an exploration of that process as I learn BC development.

First, let’s consider SL customizations, their general characteristics and what is done when building them. These customizations fall into one of several groups: maintenance screens (including setup screens), entry screens, process screens, inquiry screens, and reports.

Types of SL Customizations

Maintenance screens tend to be fairly simple, allowing the user to control data in small tables that will be used in entry screens. Frequently they exist to allow for a possible value list. Usually only one table will be used on these screens, or possibly a header and detail table.

Entry screens are similar to but more involved than maintenance screens. Normally, there will be multiple tables used, whether for entry or for lookup, and there is a significant amount of code controlling the screen. The greater complexity of these screens (and the fact that this is the start of the module workflow) makes this a separate category.

Process screens are the system workhorses. The user interface is generally very simple; the code is the important part here. These screens take the data from the entry screens and move it along through the system. The screen might handle a step within the module or feed data into one of the standard screens.

Inquiry screens are the least common type of custom screen. They are used to look up information, allowing the user to specify values to be used as filters and displaying the matching records in a grid. Reports will actually work for this purpose, but sometimes people just want a screen.

Reports in SL are handled through Crystal Reports. Essentially, you tell the system to look up a set of data and display it in a specific format.

No matter the screen type, the construction process for a customization comes down to three steps (Well, planning will have happened first, but this is the list of actions):

1. Create needed custom tables (if any).
2. Create the screens and/or reports.
3. (If necessary), add the screens and reports to the menu.

Comparing SL Customizations to BC Customizations

On to the meat of this examination. Customizations in Business Central are similar to those in SL, at least when regarded from a sufficient distance. First, you plan. Custom tables are created as needed (the method is different of course). Screens and reports can be created to match the functionally of those done in SL. They won’t look quite the same and the coding is certainly going to be much different, but you should be able to create similar functionality.

When creating the tables you don’t define them in SQL Server. They are created in Visual Studio as a table structure – the system does the SQL work. Close enough. The field types are different, but recognizable. (The types used in the program buffers for SL were different from those in SQL anyhow.) One plus is that usually you don’t need to create queries for these programs, which is good because the actual SQL tables created are bizarrely named.

Coding the screen in BC is ultimately faster than creating the screen in SL, although fine tuning is more difficult. This is the same story as always — When you make things simpler you lose some level of control. The form and function of the BC equivalent to the SL screen will look different, but, for the most part, the functionality can effectively be duplicated. Let’s take a look at three examples to see how SL customizations can translate to BC.

Example 1: Simple one-screen customization within SL

Let’s look at a sample SL screen (a very simple one):

There are very few fields in a single table. This is about as simple a screen as you can have within SL. (A single form view record might be simpler, but that would be a matter of someone else’s opinion.) My BC version of the screen looks like this:

In this case, only a single screen is needed in BC – The table is simple enough that an editable list will handle everything. The screen is recognizable, although there are differences in the details. In most cases, a list and an editable screen will be created for the conversion. The list will handle the functionality of the SL possible value window.

Example 2: SL customization with header and details

Let’s look at a more complex example. This screen contains both a header and a detail section (controlling two tables). The SL screen looks like this:

Because of the added complexity of this screen, it will need to follow more normal “rules” for BC to use a list and entry screen (There are technically three screens for the one – the list, the main screen and the sub-screen for the detail grid). Here’s the list screen:

The list shows the fields for the order type header that are most useful for the users. This screen serves largely the same purpose as the possible values window in SL, opening the entry screen to allow changes to be made or new records to be created.

Below is the main entry screen. As you can see, it looks very much like the original screen (allowing for the standard differences). It functions similarly to the original form.

Example 3: Combining SL customizations into a streamlined BC customization

Let’s try one more example. This one makes BC look good – I modified the rules for three SL screens to take advantage of changes that would need to be made for BC anyway. The three SL screens shown below allow for maintenance of a list of employee groups and two different types of rates for those groups.

(One note here is that the values in this screen come from the SL demo database employee table.)

In the two rate screens within Dynamics SL, the header is selected from the list of groups maintained in the first screen. The values from all of the screens are used in the main entry screen for the custom module (which has not been converted at this point because it is much more complex than the ones in our example).

In the BC version of these screens, I have combined them together. Technically, this is still four screens (a list, main screen and two sub-screens), but it appears to be a tighter arrangement:

Again, the list shows just the most significant fields in the header record (the employee group). This opens to the main entry screen shown below:

The two grids for group and sales group rates are in the collapsed sections. They look essentially like the grids on the SL screens, but I can only get everything on screen by collapsing them. As you can see, the work of three screens will now be done on one. Of course, keep in mind that might be a problem when setting up security.

I have not touched on converting the other types of screens or reports here. Obviously, those conversions are possible (The standard screens do those same things after all), but I just haven’t worked through them yet. Let’s face it, even screens that fit into the same general group can require vastly different methodology. My conclusion is that SL screens can be moved to BC, but sometimes things need to be approached sideways to get the job done.