Business consultant specializing in Microsoft Dynamics AX.Specialties: AX 4.0, AX 2009, AX 2012 Trade and Logistics (certified in AX 2009 and AX 2012), production, inventory management, and master planning
Passionate about the user community - especially in Illinois and Wisconsin.
I’ve been busy recently, so I haven’t had much time to blog. I was at the AXUG Summit, though, and something came up I thought I should write down because it originally confused the heck out of me and I don’t want to forget what I found.
Since AX7 or Dynamics AX was released 18 months ago, reporting and access to the data has been a concern of mine. Also, since the release, the terms “entity store” and “BYOD” have been bandied about and interchanged, so I’ve been confused. I got to the bottom of this at Summit, though, by confirming some of my assumptions in a great discussion with a couple of people on the Microsoft team and some other partners.
For starters, BYOD and entity store are two separate things. BYOD stands for Bring Your Own Database. While this could really mean any sort of database external to the D365FO database, it’s usually referenced in terms of data management. Entity store is something completely different. The entity store is a name for an internal, inaccessible data set within the D365FO product. For all intents and purposes, it’s part of D365FO and is treated the same way as the underlying transactional database – it’s there and behind the scenes, but an end user can’t see it, can’t query it, and can’t use it. The only way the entity store is used is for embedded Power BI reports.
I had heard discussions at the Tech Conference last year about using BYOD as a data warehouse. Staging data from D365FO, including external data, and then building Power BI reports on top of it. While this is technically possible, it doesn’t seem like this is the intended use. The main reason I say that is the way that it’s populated. The only way to dump data out of Dynamics 365 for Finance and Operations en masse and into the BYOD database is to use the data management framework (DIXF.) This is fine, but this means the BYOD database needs data entities created for each set of data needed. Again, not a problem, but the out-of-the-box entities don’t include any relevant transactional datasets. They’re mostly setup, master, and reference data. To me, these facts make it seem like the intended use of BYOD is for master data management or providing some master data access to other external systems in an enterprise. To keep them refreshed, you setup a recurring export project and periodically push over datasets.
The entity store is completely different. It’s a transformed data set built on aggregate data measurements. These are created using views and perspectives that sort of mirror how the OLAP cubes in previous versions of AX worked. While this seems like a logical place to connect to for access to this optimized data, it’s 100% invisible to the outside world and not accessible by a D365FO user.
Now, to get around this, Microsoft showed a new set of solution templates you can download from AppSource (https://appsource.microsoft.com/en-us/.) I had the hardest time understanding what these were for, but I think I finally wrapped my head around it. If a BI developer or Power user needs access to this analytical data for a Power BI report that isn’t going to be embedded, there’s no real way to do that right now. These solution templates, though, basically extract the data from the entity store using an Azure Logic App and dump them into a standalone Azure SQL DB. This way, you’re basically replicating the entity store in a standalone Azure SQL DB that you can use for a source in your reports. If you have external datasets, you can also plug those into the Azure SQL DB that you’ve created and basically make a data warehouse. This all requires additional Azure consumption, though, so you’re going to have to pay a little extra for this new feature.
Long story short, the entities used in DIXF for the BYOD population have nothing to do at all with the entity store. Additionally, there’s no real great way to get access to these aggregated data sets without using the solution template to push them to a separate Azure SQL DB. Hope this helps!
A whitepaper was recently published that documents the way that Contoso Incorporated (Microsoft’s demo company) is implementing Azure services. It’s a pretty cool document; it shows all the layout, user count, different features being used, and licensing. Being a Dynamics partner, I naturally decided to look at the Dynamics 365 licensing.
Here’s a link:
The first thing that’s documented is the structure of the company. The company is setup with a headquarters in Paris, 12 regional offices around the world, and 25 additional satellite offices.
Contoso’s structure showing HQ, regional offices, and satellite offices
To determine the total number of employees across the globe, I put this data into a little Excel workbook.
Contoso’s user count by office
Looking at page 7, we see Dynamics 365 user counts enumerated. Per this document, Contoso Inc., with 45,000 employees, only has 100 Dynamics 365 licenses. 100. Unless Contoso is running SAP or some other ERP system, I don’t think that makes any sense. If we do a 10/90 split between Operations users and Team members, this would represent a $2,800 monthly spend on licensing if Contoso has an Enterprise Agreement.
Licensing Contoso for 100 Dynamics 365 users
Since I’m a curious person, I figured I’d try my best at estimating the licensing requirements and cost a little more realistically.
First, I made some assumptions. Out of the 15,000 employees at headquarters, I’ll assume 10% of them require a Microsoft Dynamics 365 for Operations license. Since Microsoft is encouraging all employees to be in the ERP to increase visibility across the company, the remaining 90% will be team members.
I’ll be generous and assume that only 5% of the users at the satellite offices and regional offices need to be Dynamics 365 for Operations users. Again, the remainder of the users will be team members.
In addition, there’s a small percentage of users that may need the Dynamics 365 for Enterprise Sales App (CRM) – I’m assuming 10% at headquarters and 15% at regional and satellite offices.
Also, I’m going to assume that Contoso Inc. is on an enterprise agreement and is therefore subject to the published pricing announced at AXUG Summit.
The following breakdown is what this looks like:
User count for Contoso’s Dynamics 365 licensing
If we use the EA pricing announced at AXUG Summit, the following screenshot shows the estimated licensing spend (retail pricing, no discounts):
Estimated monthly spend for Contoso’s Dynamics 365 license
In the grand scheme of things, for a 45,000-employee company, a yearly expense of ~$11.5M for Dynamics 365 licensing probably isn’t the end of the world. The fact that Microsoft is using a 45,000-employee company as an example for who can belong fully to the Azure ecosystem (and use Dynamics 365) is sort of telling. Gone are the days when Axapta was perfect for a mid-market manufacturing company and being sold as such. Unfortunately, it seems like these customers are being left behind in search of the much larger enterprise-level customers.
The post Contoso’s Dynamics 365 Licensing appeared first on Dynamic Consulting.
In the grand scheme of things, for a 45,000-employee company, a yearly expense of ~$11.5M for Dynamics 365 licensing probably isn’t the end of the world. The fact that Microsoft is using a 45,000-employee company as an example for who can belong fully to the Azure ecosystem (and use Dynamics 365) is sort of telling. Gone best canadian casino are the days when Axapta was perfect for a mid-market manufacturing company and being sold as such. Unfortunately, it seems like these customers are being left behind in search of the much larger enterprise-level customers.
I’ve run into this a couple of times now. Someone comes to me with an error message when trying to post an invoice saying “Insufficient inventory transactions with status Received” even though there ARE sufficient received inventory transactions.
Each time I’ve seen this has been caused by the same thing – something other than letters or numbers in the packing slip for the inventory transaction. One time it was a comma, one time was caused by a period, and another time was caused by a tab. Even though there’s nothing preventing you from using these “special characters” (although I wouldn’t really consider a comma a special character,) AX can’t seem to interpret this very well.
There’s an issue in LCS that specifically describes this, but the fix doesn’t seem to work for me:
Instead of Microsoft’s suggestion, I’ve had to change the packing slip number in three places to remove those offending characters: VendPackingSlipJour, VendPackingSlipTrans, and InventTrans. As always, if you’re going to do this, DO IT IN TEST FIRST!
After doing that, the invoi
Just thought you’d like to know.
The post Special characters in packing slips? Don’t think so! appeared first on Dynamic Consulting.