Microsoft Dynamics 365 for Financials will offer the full functionality of the regular Dynamics NAV by the end of the year!
Dynamics365 for Financials will now cover all functionalities in Dynamics NAV
Overview
Until the functionality update take effect, if you signed up for Dynamics 365 for Financials you will only receive limited functionalities for within the Dynamics NAV product. The area available are mainly in the finance and order fulfillment areas.
After the update, which is promised to be by the end of the year, you will receive the full functionality as if you purchased Dynamics NAV. This includes manufacturing and WMS functionalities.
What Will be the Difference?
This is the first question that everyone will ask. Why does my company want to purchase a full Dynamics NAV license instead of just signing up for Dynamics 365 for Financials?
The answer is Customization.
For Dynamics 365, the way to “customize” what’s available out of the box is to implement extensions available from the Microsoft Appsource. This means that if you need a one-off change because you provide a differentiating service than your competitors, you will need a work around.
Whereas if you purchased Dynamics NAV product, you will be able to make these types of changes.
The Future
Extensions for Dynamics NAV (and Dynamics 365 for Financials) is ever changing. With each release, Microsoft introduces new features and expanding on the previous release. So it’s tough to say whether the paths for Dynamics 365 for Financials and Dynamics NAV will truly converge.
I’m just glad the customers do not have to sign up for the complex Azure infrastructure if they want their solution to be truly on the cloud.
Everyone once in a while, we will get a support call from a customer about archiving their historical data.
Dynamics NAV (formerly Navision) has been in the US since 1996 and for customers that were first to adopt Dynamics NAV, they have kept those data with them through the years.
Some will argue that with the cost of storage in decline, why is it necessary to archive old data. While I tend to agree with that statement, but trying to manage a 700 GB database backup, if nothing else, very time consuming.
There are a couple of ways to “shrink” the size of your database by eliminating the data within Dynamics NAV.
Data Compression
Date Compression Dynamics NAV
The date compression processes will consolidate multiple entries in the table in question into one entry.
The problem with date compression process is that it takes a loooong time to run. It takes so long to run that we usually just stop the process. The design of the Date Compression process seem to want companies to run it periodically when they start using NAV instead of running it when you’re database is 700GB. This is never the case.
Most Dynamics NAV consultants out there will never recommend their clients to use Date Compression (me included). One of the main reasons is because in the prior versions of Navision caused data problems when you did date compression when you try to upgrade.
Removing Data That Adds No Value
There are data in the database that one can consider as low priority value. You’re keeping the historical data, but the historical data is more “nice to have” instead of regulatory compliance or critical to running the business. These tables include, but are not limited to:
Change Log
Sales Document Archive
Purchase Document Archive
E.D.I. Receive Documents
E.D.I. Send Document
Posted Sales/Purchase Documents
Posted Warehouse Documents
Warehouse Registered Documents
Any posted documents
This is not to say you should delete all of the data, but you can certainly delete those data not required by the tax or audit authorities.
Re-implementation
This is the nuclear option. Basically, start fresh in a new Dynamics NAV database with only your setup data, master data, and opening balances. This option is popular with companies that have been using Dynamics NAV for a long time. It gives an opportunity to eliminate a lot of bad data, in addition, to modifications that are no longer needed.
The historical information is basically kept at the old database environment. If an old data is needed, the user basically goes to the old NAV database to retrieve the information.
But re-implementation is really overkill to specifically address the database size issue.
Conclusion
With the performance and capacity of storage ever increasing and the cost of storage ever declining, these types of question does not come up as often. I suspect as time progresses, these questions will come up once in a very long while.
I typically would recommend companies remove the data that adds little or no value first before attempting to do anything drastic. Usually holding those data takes a ton of storage in the Dynamics NAV database.
There was a company I visited that had 10 GB worth of Change Log entries. Worst is that the customer didn’t even know what the change log is…
This is a story of our Dynamics NAV implementation in Taiwan.
One of the things that I’m most proud of is the people that choose to work with me and the company that we built.
I am proud that everyone shares the same vision on what software implementations should be. That we care about doing the right things, even if it hurts our own bottom line.
That pride is none more so apparent than our team in Taiwan. A little background, our Taiwan branch began operation in 2014. In the relative short amount of time, they developed the Chinese Language Pack for Dynamics NAV. During this time, they’re also involved in a tough implementation in Taiwan for a licensed toy distributor.
Fast-forward today, the customer in Taiwan is so happy with how their Dynamics NAV implementation went, they agreed to speak on behalf of us with Microsoft on one of the most popular IT magazines in Taiwan.
– Origially had a 5 year plan to move out of the HEAVILY customized UNIX based system. We only utilized 1.5 years to implement Dynamics NAV. (According to the article, 6 months for analysis and 9 months for implementation)
– Reduce their inventory return amount up to tens of millions in local currency.
– Redesign the inventory put and pick process and increased the accuracy by at least 100%.
– Implement wireless handheld device and doubled the warehouse shipping efficiency
– Improve order process efficiency. Now it only takes one fifth of the time to proces an order (500% increase).
The Challenge
This implementation in Taiwan was indeed one of the most complicated that I’ve been involved in. Not only has their UNIX system insanely customized, but there were virtually no documentation on the operation.
Because of the type of business they’re in, they add between 10,000 to 20,000 items every month. That’s right! over 10k new items every month. You can see why order entry and communicating those new items with their large distribution network is a nightmare. In addition, think about how the warehouse will go about fulfilling these orders.
When we did our first analysis, I was personally shocked at how they were able to manage such a large volume of business with their current setup. Basically, our job was to go from no documented business process to having Dynamics NAV fully functional. The fact that our team did it in 1.5 years is nothing short of amazing.
There were countless fierce meetings and conversation both internally and with the client to better their existing business process. Even though these discussion were fierce, the client really appreciated that we did not just go with the status quo and replicate their existing business process.
Conclusion
Having the right people in the right place really makes all the difference in the world. This project wouldn’t be a success without their involvement. The people that works with me, quite honestly, can work anywhere else and any company; but they choose to work with me. That really gets me in the feels…
This is a story of upgrading one of our clients from Microsoft Dynamics NAV 2013 to Microsoft Dynamics NAV 2016 (we recommended going to NAV 2017, but they didn’t want to be guinea pigs).
The upgrade itself was done on the customer’s live server, which was a brand new powerful server on VM (virtual) environment. During the upgrade, our developers complained that the performance on the live server was extremely slow. Initially, we thought it may have been the large amount of data (100 GB) that are being upgrade so we brushed it off.
When we went live, that’s when the performance on NAV got worst.
The Problem
Researching on Google and the Dynamics NAV forums on performance issues with Dynamics NAV 2016 came up with nothing. Of all the researches, NAV 2016 should perform a lot faster, not slower.
We’ve tried reindexing, changing the settings on the Dynamics NAV service tier, changing the CPU cores, SQL tuning. Nothing worked.
The problem in the end was how the VM hosts were setup. It matters which host SQL Server and Dynamics NAV server were setup. The following VM configuration was how the server was setup:
The Solution
The internal IT director put the Dynamics NAV server and the SQL Server on the same host on the VM and *poof*… All the performance problems went away. NAV was back running in blazing speed.
What was strange was that for NAV 2013, the SQL Server and the Dynamics NAV Server was running on different host and there were no performance issues.
Conclusion
When you’re in an VM environment, put the SQL Server and the Dynamics NAV server on the same host machine.
Upgrading to Dynamics NAV 2016 is nothing new for us. We’ve done quite a bit of the upgrades for companies but this issue baffled me a bit. The same structure used on NAV2013 did not work well on NAV2016.
Hopefully, if you read this, it will save you from some headaches that I’ve gone through.
With the release of Dynamics NAV 2017 and Dynamics 365 for Financials (which is technically NAV2017), the buzz word in the Dynamics NAV development community is the development function called Extensions.
What are Extensions?
Extensions is a way for NAV Developers to put modifications in your live environment without modifying your core NAV system.
How Does it Work?
The extension basically implements the code on the Service Tier instead of the NAV development environment. The clients connects to NAV using the service tier, this is how you see your NAV in whatever state it’s in.
Implementing the code directly in the service tier means that you won’t see any of the modifications if you go into the NAV development environment. You can only see the new tables created and table field changes if you look into the SQL tables directly.
Why is the Development Community Buzzing About This?
I honestly don’t know. I think the hype of Microsoft releasing something new have people gagaing and swept up into the hype.
I remember when Microsoft first announced the idea of multi-tenant for NAV services. Even though people didn’t fully understand it and it didn’t apply to 99% of the NAV population, the community still tauted like it was something that was the second coming. But… That’s hype and marketing for you.
At its current state, the NAV Extension will benefit partners and ISV in that they can quickly take their code and implement it on customer sites. In addition, it gives partners, ISVs, and independent NAV developers to protect their code from everyone else that does not have the “source code”.
For customers, the benefit is that the partners won’t charge too much for putting modifications that they’ve developed for other customers. They will now have a wide range of solutions that are developed in extensions they can essentially “bolt on”.
Lastly, it’s the only way to get your IP (intellectual property) on the Microsoft AppSource.
Why it’s a Weapon of Mass Destruction for a Company?
Notice the statement I made above:
It gives partners, ISVs, and independent NAV developers to protect their code from everyone else that does not have the “source code”
By implementing the code on directly on the service tier, nobody in the world will be able to modify what the original developer has done. The code that your partner/ISV/internal developer has put in is effectively sealed off from the rest of the world.
This means that if you are, for whatever reason, unhappy with your partner/ISV/internal developer, you better make sure, as a company, you have the original source code on which they built their extensions on.
Playing the devil’s advocate and assuming the worst scenarios with extensions
If you have a NAV or ISV partner that delivered their modifications to you as extensions and they provide terrible service and lacks basic knowledge of the product. If you want to ask another NAV partner or a freelancer to come in and help you, you will need the blessing of your previous NAV partner and pray that they are cooperative in provide the source codes.
If you purchased an ISV for your business, however, there are still some missing features on the ISV that you need your partner to add. Your partner will be unable to help you. You will need to reply in the ISV to re-release the extension for you.
If you have your own internal NAV developer on staff. If you need to terminate his employment for whatever reason, it’s very possible he/she can take the source code with them and leave you high and dry. No partner can come to your aide and you essentially have to live with what you have.
Conclusion
Even now, if you purchase an add-on in the 30 million object ranges, you’re effectively held prisoner by your ISV or the partner. There are special ways to “hack” the 30 million object ranges within SQL, but it’s usually messy and will incur a lot of additional expense on your part.
However, with Extensions at it’s current form, it will be impossible for any NAV developer to come help you if you do not have the original source code for the extensions.
Dynamics NAV (Navision) has always been an open source software. Implementing a structure where you effectively seal off the code is troubling.
It seems like before you do any kind of Extensions development with your partner or customer, you will need to lawyer up first. And as we all know, once you get lawyers into the mix, it just goes downhill from there.
Straight from the official announcement from the NAVUG Summit at Tampa yesterday.
Rebranding of Dynamics Product Line So there won’t be Dynamics CRM or AX anymore in the future. It’ll be called Dynamics 365 for <insert business function>
The only Dynamics products that will retain it’s name are the NAV, GP, and SL lines.
Dynamics 365 names in the future
So basically, you will be able to buy individual business functions with Dynamics 365. The best part about all this is that all the products has a Common Data Model. This means that all of the business functions you buy from Dynamics 365 will automatically be synced together. This is too cool.
Release Date Announced! The official release date announced for Dynamics 365 is on November 1st, 2016.
Overview
This is a recap of my experience at Directions US 2016.
NAV Directions is an event hosted by NAV partners for NAV partners. In reality, it’s just a large Microsoft infomercial for partners. Microsoft has giving us what’s to come and the directions (pun?) they’re taking with the future of business software.
Welcome to Directions 2016: Figuring Sh*t Out
The NAV Directions committee should’ve created an appropriate name for this year’s event. The conference featured a lot of cool stuff, but also a lot of questions surrounding its details.
The event highlighted what Microsoft is currently doing as well as where they’re going with the product and the product ecosystem. However, a lot of what they’ve released to do seemed half-baked and left all of us wondering not only when Microsoft will be figuring their stuff out, but how will partners try to figure out what Microsoft is still trying to figure out so they can figure out what to do.
Important Takeaways AppSource
In case you have not heard of it by now, Appsource is the way of the future that allows all developers to publish their mods for sale on Appsource. This is a welcomed news for independent developers as they can now sell their mods for the general public. It’s good for customers as well; Microsoft has indicated that they will “let the market decide” the pricing and the apps that are popular. Hopefully, we will see an end to outrageously expensive add-ons that are on the NAV channel.
Pros:
– Anyone and their moms and publish apps on the Appsource
– way to quickly get your mod out into the world without doing too much marketing.
Cons:
– You can have people that have no business doing NAV publishing crap on Appsource.
– No monetization?! It’s not a market if you can’t sell anything. Microsoft is still trying to figure this one out.
Extensions
It’s the way of the future. Microsoft has open encouraged all partners to develop their mods on Extensions. I will make a quick video on how to create an extension in a future blog post.
Pros:
– You can deploy it on multiple sites easily quickly
– Deploy it on Appsource for sale to customers that you would never otherwise talk to
Cons:
– Debugging, no one can see the source code. You can easily see the problem here in that users can be held hostage by the app developer for their financial data (this is not Angry Birds we’re talking about here).
– Still a ton of questions on flexibility of extensions. Microsoft and partners are still trying to figure this one out
Dynamics 365
The initial release will be called Dynamics 365 for Financials. It’s built on a Dynamics NAV 2017 platform. It will be part of the Office 365 offering at around $40 – $50 per user per month. The target for this product, as it stands, will be to replace Quickbooks Pro users. Later on, they will release (or unlock) more functionalities.
Pros:
– Appsource. You will get a wide varieties of add-ons that you can quickly buy and deploy.
– It’s cheap and packs the power of Dynamics NAV.
Cons:
– Frankly, I don’t even know who my clients buy their Office 365 from. How will NAV partners compete in this space? How will the NAV pros help in this sector? Perhaps the product will be so easy to use that you will not need a professional to help you. Still trying to figure out how to incorporate this as a VAR.
Conclusion
After leaving this event, I left with more questions and uncertainty than I came in with. It’ll be interesting on how it will all shake out.
Overview
One of the most often asked about features when dealing with inventory is the ability to keep track of inventory by bins in the warehouse. While The Warehouse Management System will benefit the accuracy of the items that are stored in the bins, careful consideration must be made during setup so when you go live, less additional work is needed for the system to work for you.
On a macro level, before you eve consider implementing a warheouse management system, your warehouse itself MUST BE ORGANIZED! What I always tell customers is that the purpose of a computer systems is to help you do something faster. This means that if you’re warehouse is a mess, implementing a warehouse system will make it more messy, faster. However, if you’re warehouse operation is efficient and optimized, then implementing a warehouse system will help you become more efficient and optimized, faster.
The Bin Codes
While there are many considerations for setting up warehouse management in NAV, this article will focus on one of the most overlooked areas.
The Bin Codes.
The Path of the Picker
There are many differnet theories about how to create the most efficient picking path. But generally, you want the path of the picking so the following occurs:
1. When picking for an order, they would not have to come back to the same bin in the same level
2. When picking, they should pick from the eye level (or the level where they don’t need special equipment). This is typically the first level.
Keeping it simple and not concerning with spliting into Zones, wave picking, and whatnot, the pattern the warehouse picker should walk is the following:
Warehouse path for picker
Only when the above is exhausted, do we use special equipment and pick from the higher levels. The general rules are the same, you want to use the run time for the special equipment should be as minimal as possible.
The Sort Order of the Pick Bins
In order to get the path described above, we have to first understand how Dynamics NAV priortizes what bin is selected when a pick is generated. Consider the following bins numbers for your warehouse:
Typical Bin Code for Warehouses
The first 2 characters is Section, then Isle, then Level
When the pick from NAV is generated, it will suggest the pick in the following order (assuming no bin ranking is used).
NAV Suggested Pick Order
As you can see, it will create the pick on a decending order.
Why Suggest the Bins in Decending Order?
The answer lies in the help for the Bin Ranking field found in the Help or on MSDN:
The program will suggest a pick from the bin with the highest numerical ranking. Items in the highest-ranking bins (bins with the highest number in the field) will thus be picked first
Makes sense.
Why Not Use the Bin Ranking?
We could. But tread carefully! Bin Ranking provides a lot of flexibility on how the bins are ordered during the directed pick/put-away. Not paying special attention to how to rank the bins will give you more pain and suffering.
Assuming you rank all of the 1st level bins the highest, and level 4 the lowest. The resulting pick order NAV would generate for its pick is the following:
This means that NAV will ask the warehouse picker to pick from the section that’s furthest away from the warehouse (assuming that’s section C). Very good for letting your warehouse picker get excercise, not really good for pick efficiency.
Two Ways You Can Go About This
Property Setup the Bin Ranking
If you want to utilize the Bin Ranking, then you will need to sort it based on how you want the warehouse user to logically pick/put-away. In the example above, the bin ranking would be set as the following:
Proper Bin Ranking Setup for a Warehouse
You will need to carefully configure how to assign the bin ranking. In addition, if there are any changes to your bins (add/remove), you will need to break out the spreadsheet and reassign all bin rankings again.
Modify the Default Bin to sort in Acending Order instead of Decending Order
Doing so will allow Dynamics NAV to “sort” to pick from A section to D section. However, it will also ask the picker to pick from multiple levels first instead of the 1st level.
You will need to reconfigure how your bin codes are setup. Instead of Section – Row – Level, you will need to reconfigure your layout as Level – Section – Row:
This will ensure that all of the 1st levels are picked first. Then it will then pick the 2nd level, then the 3rd, etc. This option may not be feasible if you’ve already spent the time and effort on labeling all of your bins. This option may also not be feasible if you want them to pick from the same column once they got the forklift truck. However, this option will require the least amount of maintenance.
Conclusion
Having implemented both methods for clients with warheouse management requirements for Dynamics NAV, both methods have their pros and cons. And they both work for the respective companies.
Bin Ranking will work wonders if you take the time to set it up right, but maintenance is a hassel. Reconfiguring the bins is simple, but you have to becareful about how NAV sorts the bins.
Again, both methods work. It really depends on how you implement this.
Overview
When people talk about WIP account, it’s what it is. An intermediary account where the raw material is being worked on, but it’s not yet a finished good for sale. This is important for companies to audit in a manufacturing process where the inventory is being produced or in the middle of being produced.
WIP it Good
But there’s a Dynamics NAV WIP and WIP for companies.
When people account for WIP in their company, it’s usually an output of a product that still need to go to some finished good.
For Dynamics NAV, it’s the components that has been posted as consumed, but not outputted. So all NAV WIP reports are not what companies wants for WIP.
To identify WIP, we typically setup 3 inventory accounts. RW, WIP, and FG. For example, assume you’re in food manufacturing and you make frozen pizzas (because I’m hungry right now).
The flour, tomato, cheese, raw meat can all be considered RW
The marinara sauce, pizza dough, sausage can be considered WIP
the finished pizza (the holy grail) the FG
For a typical manufacturing company, they would have the following accounts:
Raw material
WIP
FG
The Actual Setup You Should Have in NAV
For Dynamics NAV, we typically utilize the following accounts:
Raw material
WIP
WIP (NAV)
Finished Goods
What NAV is Doing
When you post a consumption in a Released Production order for your WIP items, it will hit the following accounts:
– Raw Material
+ WIP (NAV)
Then when you output the production order and finish the production order, it will hit the following accounts:
– WIP (NAV)
+ WIP
Similarly, when you are producing the frozen pizza, the accounts that will be affected will be:
When you consume:
– WIP
+ WIP (NAV)
When you Output:
– WIP (NAV)
+ Finished Goods
Why Not Combine Them?
You could, but I would not recommend it. When you look at the WIP (NAV), you can easily tell if there are any production orders that has been consumed but not outputted and finished. If you lump it all into your regular WIP account, while you can still get the information by running reports, will be an extra step you need to take.
On the financial statements, you can easily lump the WIP adn the WIP (NAV) accounts together as a total WIP in the inventory.
Been working on this book for the past few months. Although it’s not a book that I wrote from scratch, I’ve spent a considerable amount of time updating the contents for Dynamics NAV 2016.
