Saturday, September 26, 2015

Compare Microsoft Dynamics AX for Retail, Commerce Essentials, and Retail Realm Essentials: Features and Licensing

Within Dynamics AX, there is the 'Retail' module that everyone is calling AX for Retail. Recently, there is discussion about the 'Retail Essentials' module which is the AX system with just the retail component and a simplified setup. Retail Essentials is marketed towards the small to medium sized businesses market (SMB).

While explaining the different ways to deploy and license AX for certain scenarios, things can get confusing. I was confused as well for a while :-) The goal of this post is to demystify this as well as verbalize the branding that Microsoft is using to help rid the confusion. There were two options for 'Retail Essentials in licensing

We'll look at three different examples of how to use, deploy, and license AX for Retail. Note that the code base for all of this is the exact same regardless of the scenario.

Scenario 1: Full blown AX with AX for Retail module

The licensing for AX Retail is the same as it is for any module in AX. Full access to the modules and modification to the business logic in the application object tree (AOT) are granted. This is what people would consider a 'typical' enterprise level implementation of AX. You'll see all modules but will not see a module called 'Retail Essentials' in the list.

Scenario 2: Commerce Essentials 

This module was formerly labeled 'Retail Essentials' if you looked at the modules list in AX but was re-branded.

The licensing of this is the same as full blown AX but you are able to leverage the simplicity of the Retail Essentials configuration. When the AX system is configured, you'll check the configuration keys for retail essentials and will only see one module in AX (Figure 1 below). All the functionality still exists behind the scene but, again, the system configuration and views are simplified for a targeted type of deployment. Just uncheck the 'Full feature set' check box and you'll be in Commerce/Retail Essentials mode.

Of note, from a developer perspective, you can expose and have access to anything in the back end AOT wise without violating a license agreement. This is because you are paying for a full AX license.

Note that the name in Figure 1 will be 'Commerce Essentials' here shortly to differentiate it from Scenario 3 covered below.

Why would you use this? There are a variety of reasons but one good scenario is where a company is using another ERP as their master and only using the AX Retail components in their deployment. Another could be a phase 1 where its speed to market to get AX live for a customer just in their retail operations. Or you want a simple retail solution but need modifications that aren't in the base product and they don't want to violate their license agreements.

Scenario 3: Retail Realm Essentials

The third scenario is still going to be called 'Retail Essentials'. Functionally it is the same as scenario 2 above but with the very important distinction that larger modification or exposing of other AX functionality past what comes in base will be a violation of the license agreement. So think of this as a static code base with the exception of small changes like adding fields.

The trade off is the licensing is cheaper for Retail Essentials than standard AX licenses. The licensing is purchased through a separate company for this scenario called Retail Realm but they work directly through Microsoft. This software licensing also includes Retail Realm's utilities which contain an additional cost to utilize for scenario 1 and 2.

If the company later decides to go full blown AX or enters phase two where they will need more than what this offers, they can change their licensing to Scenario 1+2 and start that process. All the code and tables behind the scenes are the same so its just a matter of licensing, configuration keys, and data setup/migration.

Why would you use this? It is an ideal solution for the SMB market. A company wanting retail in a phase one approach can also use this model as its cheaper, but they would only be allowed very simple customizations without violating their licensing agreement.

Summary
Hopefully this post shed some light on the new licensing of the AX retail platform and added some clarity to confusion!
Figure 1 - Retail Essentials view. Unselecting 'Full feature set' in retail config key will enable this functionality.

Thursday, September 24, 2015

AX 2012 Modern POS error: "Device Activiation Error Application Error"

I restarted an old Azure instance of the Modern POS (mPOS) that was once working, and when it was loaded back up, the mPOS loaded up like it had not yet been activated. I'd actually activated it and used the install setup for this instance in a previous post: Retail Modern POS (mPOS) installation and setup via AX 2012 R3 CU8 demo machine.

When attempting to reactivate it, I was getting the error 'Device Activation Error' with the detail 'Application error' (Figure 1 below).

Figure 1 - MPOS activation error: 'Device Activation Errror: Application error"'

I used the normal debugging techniques to try to figure out the issue (Event viewer and Fiddler primarily) to no avail. I also pushed all of the data from AX down to the retail channel again to make sure nothing was out of sync. Note: when using Fiddler, make sure there is a Win8 Loopback Exemption for the MPOS (Fiddler>Tools>'Win8 Loopback Exemptions>'Microsoft Dynamics Retail Modern POS application' [AS OF 9/24/2015]).

After digging more and more, I found out that a setting had been changed in AX for the channel profile of the store where the Retail server URL was reaching out to an Azure address rather than the localhost I was specifying on the Service URL for the Device Activation screen from Figure 1 above. The setup for the wrong setting is in Figure 2 below. The correct setting is in Figure 3 below as well as where you can validate what channel profile the store is using.

The setup in Figure 2 was not necessarily wrong but the setup was not complete hence the error. So I changed it back to what was working locally. To note, the MPOS was installed locally on the same instance as the AX instance. 

Hope this helps!


Figure 2 - The non-working configuration for the retail server channel
Figure 3 - The working configuration for the mPOS. This resolved the error