Difference between AX 2012 and D365 Finance and Operations

 Ax2012:

Microsoft Dynamics AX is an enterprise resource planning (ERP) solution for midsize and larger organizations that helps people to work effectively, manage change, and compete globally. Microsoft Dynamics AX works like and with familiar Microsoft software and is a solution that automates and streamlines financial, business intelligence, and supply chain processes in a way that can help you with your business.

D365 Finance and Operations:

Dynamics 365 for Operations is web/browser based, hosted by Microsoft on Azure (like Office 365) is provides similar functionality, but has a completely new UI. It is part of their family called Dynamics 365 that merges elements of Microsoft Dynamics CRM, AX and the financials from Dynamics NAV.

Although they are essentially two different versions of the same business solution, there are a few key differences between the two ERP solutions. For the sake of this post, we will compare Dynamics AX 2012 to Dynamics 365 for Finance and Operations.

1. Infrastructure

The biggest difference between Dynamics AX and Dynamics 365 is the infrastructure the systems are built on. When Microsoft committed to putting cloud technology first when CEO Satya Nadella took over in 2014, they moved the Dynamics products into the cloud, as well. This meant that Microsoft’s cloud service, Azure, would host D365 and any other applications from the Dynamics 365 suite of products. In contrast, Dynamics AX 2012 can still be run on-premise, meaning that customers can host the application on their own servers that are physically onsite.

2. Custom development

With any ERP implementation, there is bound to be some software configuration or customization needed to meet specific business requirements. With Dynamics AX, custom development can be applied using the over-layering method. Over-layering is a concept that allows the core product, customer code and any value-added reseller (VAR) code to be separated from each other in different layers. The different sets of code are then layered on top of each other within the ERP system. Sometimes, when the code is merged, compatibility issues arise, and developers must adjust their code before it can be deployed.

D365 requires the use of the extensibility model as opposed to over-layering. This means the core code of the ERP system is locked down, not allowing any customizations. Developers must customize the software through built-in extension points.

3. Upgrade Models

Upgrades from AX 2012 to D365 can typically be done without a new implementation, depending on the amount of custom code involved. However, upgrades from AX 2009 to D365, require a new implementation since there is no direct upgrade path from one to the other.

With the move to the cloud came the opportunity for Microsoft to adopt a new upgrade model, similar to the upgrade model of modern applications consumers are familiar with today.

This model, used in D365, does not require a new software implementation. Instead, monthly updates are pushed out to customers on the ERP application. Large feature changes are delivered as parameters or configuration keys, allowing customers to decide if they want to turn on the new functionality. For customers with custom code, the chances of conflicts with the upgrade are drastically reduced.

4. User Interface

A very apparent difference between Dynamics AX and D365 is the user interface. With Dynamics AX, a user can launch the application from a desktop and perform their work within the program. Dynamics AX has the aesthetic of most ERP systems, which is, to be honest, a little out of touch with today’s typical ERP user.

With D365, a user can launch a web browser and enter a URL. Within the browser, the user can perform his or her work and open additional tabs if necessary. D365 can be launched from desktops and mobile devices alike – anywhere with an internet connection. The look and feel of D365 is more aligned with Microsoft’s branding and matches the style of other Microsoft products, like the Office 365 suite.

In Dynamics AX, the homepage defaults to an area called Role Centers. Here, users can create custom queues and links that make performing their daily functions easier.

In D365, the homepage defaults to an area called Workspaces. While similar to Role Centers, Workspaces are prebuilt queues, links, lists and graphics that are related to specific modules and security roles.

5.Navigation

Navigational differences, though minor, are worth noting.

A common theme across ERP systems is that certain screens can be launched from several different places in the system. In Dynamics AX, a user must know the menu path to a specific screen. For example, to create a new sales order, a user can navigate to Sales and marketing > Sales orders > All sales orders. However, this is not the only place to launch the sales order screen, which makes it difficult and time consuming for users to memorize any particular path.

In D365, a new search capability was added to allow users to type in the name of the screen they are looking for and click from the results to launch the page.

Key terms in D365 FinOps:

Packages : A package is a deployable unit, which may have multiple modals.

Model: A model is a group of elements, a model is collection of elements that represent a distributed software solution.

Element: Element is any object residing in AOT.

eg: Base Enum, any EDT, Table, Form which you see in AOT tree in an element itself.

Project : Project are the logical container for everything thats needed to build your application.

A project can be associated with any one model.

Enhanced User Experience :

• One of the biggest differences in the new version is in the user experience, as Dynamics 365 for Operations has a new interface .
• Also, the entire program is now web-oriented, so everything you need is located within a browser, which should make everything faster and easier to use.
• The user experience will be enhanced even more by the fact that Microsoft has now made Dynamics 365 compatible with mobile devices like phones and tablets.
• Users having real-time access to data on these devices is a game changer for nearly any company, as it will allow them to do business anywhere and at any time.

Integrations :

The intelligence of Dynamics 365 is also miles ahead of previous versions. There is now full integration with CRM, Office 365, and PowerBI, not to mention Cortana, so the speed at which you can retrieve data and make accurate and informed decisions is quite impressive.

Changes for Developers :

1. Visual Studio :

MorphX is gone, Visual Studio (VS) is the new IDE. All of Microsoft Dynamics 365 is web-based, there is no longer a fat AX client and there is no MorphX development environment to get into. You will do all of your work in VS. It is well-documented, stable, and feature rich.

2. Deployment Packages :

• The next big change is the introduction of deployment packages and the marginalization of the traditional AX concept of layers. Deployment packages are conceptually a replacement for model stores.
• Deployment packages are comprised of all of the artifacts (like assemblies and configurations files) required to make the code function.
• When moving code between environments, deployment packages will be used.
• As part of this change, when you create a model in Visual Studio (VS) you indicate which deployment package the model is a part of and what kind of dependencies it has. Similar to how in VS when you add a reference to a project, you create a dependency between your project and the one you added a reference to.
• Additionally, when you create your model, you specify which layer the model is going to live in. The layer is the traditional AX concept of a layer but in the VS world, the layer’s importance is very minimal. You are not required to provide a key for your model to live in that layer.

3. Extensions :

• Dynamics 365 for Operations includes the introduction of extensions. In all previous versions of AX when modifying or adding to sys or ISV code, you override or added something to an object which created a potential conflict at upgrade time.
• In Dynamics 365 this is still possible it is known as a customization but now it is not the only way to modify existing code. Microsoft has added an extensions model with extensions you can extend an object without touching the base object. This means you can add new fields, methods or controls to tables, classes and forms and those additions are contained in your own extension object. You have not affected the base object.
• Also the base objects have many, many events added to them. In previous versions of AX, you override methods so your code would be called when events happened – like a button being clicked. Now the button will raise an event and you can subscribe to that event. By subscribing to the event your code will be called without you having to override or modify the button.

4. Form Patterns :

The required adherence to form patterns are next big change. Form patterns are guidelines Microsoft has for how forms should be designed. Microsoft wants all forms in AX to look-and-feel similar regardless of who makes them so the end user has a consistent experience. Form patterns are not a new concept; they exist in AX 2012. However, most AX developers were not aware of them in AX 2012 because they were a guideline and not a requirement.

In Dynamics 365 when you create a form, the first thing you do in the design of that form is specify the form pattern it is going to follow. If you don’t specify the form pattern, you will get compile errors.

As you continue to build the form’s design, the pattern for the form is enforced meaning you must fill out the requirements of the pattern and if you do not you will get compile errors. This definitely takes some time to get used to.

5. Introduction of Data Entities :

Introduction of data entities. Data entities serve as the new framework for integrating with AX. They are a replacement two concepts in AX 2012, document services and the classes that comprised the Data Import Export Framework (DIXF).

With data entities, all data coming into and going out of AX follow the same path so you do not have to build two different things if you are calling an API or using DIXF to manipulate data.

The data entities are very easy to create. There is a wizard that walks you through the creation process similar to the wizard in AX 2012 used to generate document services.

Another notable change within integrations is that the services exposing data entities are restful state APIs using JSON formatted data.

In AX2012 all services were WCF services. This change means the way you call services is significantly different so if you are planning to do integrations on Dynamics 365 you will want to study up on how to call the APIs.

AXPP Files:

1. Files ending in axpp are the replacement for xpo files.

2. To export and import projects similar to what you would do with xpos on 2012:

In the Solution Explorer, right-click on a project and choose Export project <ProjectName>

The project gets saved as a file with an extension of .axpp

a. The model the project is created in is saved in the axpp file

i. The model contains the layer info.

b. The axpp file cannot be read with Notepad

3. To import the axpp containing the project in VS go to the Dynamics AX menu and choose Import project.

a. The project is created in the model (and layer) and saved in the axpp file.

i. If the model doesn’t exist in the imported environment, it will be generated.

4. Similar to AX 2012 and importing an xpo, in Dynamics 365 for Operations (AX7) you can do a comparison between the contents of the axpp file and the current environment.

a. To compare objects during the import: When you select Import project a dialog opens asking you to select the location of the axpp file.

• When you select Import project a dialog opens asking you to select the location of the axpp file.
• Once you have selected the axpp file at the bottom of the dialog there is a Details section.
• In the details section, you can see all of the objects to be imported.
• When viewing the objects, right-click on one of them and choose Compare to bring up compare window.

Packages

• It includes all of the models, binaries and additional pieces needed to deploy code.
• Similar concept to an AX2012 modelstore or in VS a solution.

You can have multiple packages per installation.

• AX ships with several packages including:

Application Suite - This is the package containing most of the application code and is the most likely to be overridden.

• Application Suite Form Adaptor
• Application Foundation
• Application Foundation Form Adaptor
• Application Platform
• Application Platform Form Adaptor
• When creating a model, the wizard prompts for which package the model should live in.
• To create customization objects (overlayer objects) you have to:

Create a new model in the same package as the objects being customized.

This is because there will be a dependency between your customizations and the objects being customized.

• The new model has to exist in a layer that you can access (usr, cus, or var).