Since Dynamics 365 for Business Edition (aka Dynamics 365 Financials, aka Dynamics 365 for Finance & Operations, Business Edition) was released at the end of 2016, I’ve had the opportunity to work on a number of implementations with Microsoft’s newest entry to the SMB ERP world.
Bringing clients from different ERP systems into the new environment of D365 has been an interesting challenge – and sometimes, it has indeed proven to be a challenge. As with any new ERP, it has had growing pains and shortcomings, but it’s also shown some significant improvements over other accounting packages that cannot be ignored. Nonetheless, it has presented the opportunity to learn from the shortcomings and celebrate the triumphs.
Some marked improvements
The first thing I want to point out is that it’s immensely easier (and makes a lot of sense) to implement Dynamics 365 if you have a subscription to Office 365, or are at least planning to co-implement Office 365 and Dynamics 365. The reason for this is that the Edit in Excel feature which displays so prominently on just about every window in D365 will only work if you have Office 365.
One implementation we did was with a client who was operating on Office 2007, but still wanted to go with D365. While we were able to use our in-house license to upload master records and transactional data, the client really missed out on some neat functionality by not having O365. We can debate all day about the value of SaaS vs. on-prem installations, but if you’re going with a hosted, SaaS-oriented solution for your ERP, it makes sense to also convert your office productivity apps to the same platform.
This principle applies in other areas, too. The more your solutions fall under the Microsoft banner, the better your business apps are going to work together. To give one example, we have one client for whom we implemented Dynamics 365 Project Service Automation concurrently with Dynamics 365 Financials, both of which utilize the Common Data Model.
Because of this, they are able to easily integrate records such as customers, invoices and project information between the two systems, giving them greater visibility within a common and familiar system. When you take into account all of the other business- and productivity-oriented apps available within the Microsoft Dynamics and Office spheres, it only stands to reason that tying all of this data together is going to be more intuitive and take significantly less work than a more eclectic, piecemeal solution.
While I certainly understand that there are businesses out there which need to do this for one reason or another, I can say from personal experience that Microsoft solutions tend to work well together overall, and will cause significantly less headache when integrating your data across platforms.
Building on this, I wanted to mention the data import options available for end users. Coming from the world of Dynamics GP, I have known and used both eOne SmartConnect and Integration Manager for some time now. However, Dynamics 365 takes a different approach. For any importable records (such as vendors, customers, transactions, et cetera) you can bring your entire data set into Excel at the click of a button. There, you can modify the existing records or add new records as need be and hit another button to publish the changes into D365.
It’s stupidly easy to copy and paste this data from another Excel sheet, even throwing in a few formulas where you need, and then push it back into the cloud, thereby creating your new records. While I am a definite fan of SmartConnect, I find this to be an even easier and more elegant solution. Given that 95% percent of the data you need to put into a system can be opened in an Excel sheet, this functionality is incredibly handy while implementing, and continues to shine long after go-live as the customer can bring data down to Excel and begin building reports on it with little to no extra training. While I am a definite fan of SmartConnect, the ease with which I can integrate records using edit in Excel is a beautiful breath of fresh air.
A few hiccups along the way
As with all new entries to such a complex world as ERP software, there have been a few shortcomings as the kinks are being worked out. One of the more prominent of these is the fact that you cannot import transactional dimensions. A dimension in D365 is an additional way to track information about a transaction, such as whether it was a Sales or Marketing expense. This can be particularly handy for grant-funded institutions, as it allows them to track exactly which grant a transaction should apply to.
On one of our very first implementations, we architected out a solution that involved a client who wished to map the last segment of their chart of accounts to a dimension instead, as you can only have one account segment in D365 Financials. After this plan was signed off on by all parties, we got to the part of the implementation itself where we began loading G/L transactions.
We quickly discovered that Microsoft left this feature out of the import capabilities, and that the best hope was a suggestion to include it in a future update. After mumbling under my breath about “know-nothing developers”, I dutifully added my upvote to the suggestion on the Microsoft Ideas site, and then set about brainstorming with my co-consultant on how we were going to crack this nut. We eventually found that if you navigate to the “Account Type Default Dim.” window from the “Dimensions” window in D365, you can define a default dimension for G/L accounts.
Any new transactions integrated will then take that default dimension. We ended up splitting up the transactions by dimension and loading in each month in separate sections, one for each dimension, changing the default each time. It was a painful workaround, but luckily the client didn’t have many dimensions, and in the end, we were able to accomplish our goal.
This isn’t the only instance where the import process doesn’t expose all the fields you’d need. To give another example, the Fixed Assets module in D365 only allows you to import certain master-record information – you have to manually process the financial side of the equation.
This is unfortunate, as most ERPs (including GP) offer you some method of being able to import this information. On the other hand, there is the Bank Reconciliation process, which instead of being a tedious, manual tic-and-tie is much faster thanks to the online bank feed retrieval capabilities in D365. This is extremely easy to set up and use, as you can see from the blog post by Microsoft’s Marko Perisic. What would be a several-hour project to set up in GP is doable in 15 minutes with D365.
Another unfortunate shortcoming is the reporting capability built into D365. Leaving aside the free license you get to Power BI, the canned reports are not that easy to modify. For instance, if you wish to add a new field to the RDLC check report, you are stuck with what is built in to the check by the developers. If the field you want isn’t somewhere on the check, chances are you won’t be able to add it – this was confirmed via support case with Microsoft.
In addition, if you wish to modify the built-in financial statements that are built in to the system, because they are system reports, they are at risk of having any changes overwritten. This is evidenced by a warning message when you first go in to modify them. You can always make a copy and do your modifications there, but even this method isn’t the best, especially if you have dimensions coming in to play.
In doing some research and talking with colleagues, it sounds like most of the Dynamics NAV community (which is very similar to D365 Financials) utilizes Jet Reports. However, in speaking to a contact from Jet Reports, it sounds as though Microsoft has requested that a few minor modifications be made to their D365 version, which means that it likely won’t be ready for customer use for at least a couple of months. Therefore, users are currently limited to either cobbling together financial statements in Power BI, which is really a dashboard-oriented program, or making do with the current Account Schedule financial statements that come with the system.
More to Come
In summary, Dynamics 365 is a great concept with mediocre execution. It does a lot of things right, and I’m still excited about the possibilities. However, I’m holding out hope that the next major iteration, codenamed Project Tenerife and due out sometime in the first half of 2018, will fill in a lot of these holes and “no-duh” situations that I and many others have run into.
Microsoft has promised that this next iteration will have the full functionality of NAV, in addition to getting priority for updates, so my hope is that they’ll be able to learn from the last 12-18 months of user feedback, and give us a more full-featured program. Until then, if you’d like to discuss Dynamics 365 and whether you think it might be a good fit for your organization, please don’t hesitate to contact me at jnorberg@ktlsolutions.com.
