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.
Hopefully this post shed some light on the new licensing of the AX retail platform and added some clarity to confusion!