Rarely in a NAV implementation that the problem you get stuck on is techincal. As we all know, Dynamics NAV aka Navision is simple to implement and simple to customize. It’s one of the reason why it’s the dominate mid market ERP today.

Most of the challenges you’ll face are with people. And one of the toughest challenges when implementing Dynamics NAV is working with 3rd party consultants the end user company hired to help them implement a new system.

Perhaps, this is one of the bad side affects our industry has brought on to ourselves. With too many software  partners not knowing what they’re doing (or as some people call them: crooks), it’s natural for clients to feel fearful that their implementation will fail. So the client will naturally want to bring an objective 3rd to give second opinions and help the client through this transition.

Most of the time, these 3rd party consultants will have years and years of experience in the accouting software industry. They will often hold certifications, have CPA or MBA background, have good relationship or are friends with either the owner or a top executive of the company, and may have developed or sold the old system they’re replacing with Dynamics Navision.

Having worked with the client before you come in, they’re often unusally firm on how they want things to progress. The challenge is to work with them and sell them on your game plan to get the client implemented successfully.

Some of the pitfalls when implementing through a 3rd party consultants are:
- They try to lead the implementation even though they do not understand NAV or the implementation process
- They claim knowedge of all aspects of clients business, often they don’t.
- Get caught up with “what should be there” instead of opening their mind to new ways for the clients to get things done
- They are pressured to be productive, so they often take a small pieces of a business process and create unnecessary steps, error checks, reports that sounds great verbally, but inpractical when actually doing it.

In addition, some of the non-implementation problems you may encounter are:
- Eating into the client’s IT budget
- Clients avoids responsibility for the implementation of Navision
- Thrid party consultants have their own priorities

As an implementor, you cannot simply brush these people aside. Obviously, they’re able win the hearts and minds of the top executives in order to get the contract. Brushing them aside would award you with the biggest enemy during and after the implementation.

Unfortunately, years in the accounting or ERP software business are not useful if the person has no NAV experience. I equate that to hiring a general doctor and asking him/her to perform heart surgery.

This is not to say that companies does not need 3rd party consultants. They are important to fulfill key expertise you may not have. They are also potential key allies during implementation to convince the users of the ideas and changes in business processes. This is true especially if they have a close relationship with the company management.

Some of the benefits they provide are:
- Organize the relevent people during interview process
- Cut through the politics and get you the information you need
- Help you get the implementation moving when it has stalled

Some of the best 3rd party consultants I’ve work with does the following:
- Provide services that compliments NAV. (i.e. server, Sharepoint, network, etc)
- There to learn NAV with an open mind and attempt to learn table, form, report, etc designer
- Document new processes and procedures after the implementation of NAV
- Eager to become part of your team and learn how to support the client after they’re live

The best case scenario is the 3rd party consultant stays out of your way implementing Navision and help you when you ask for it.

If you cannot avoid working with a 3rd party consultant, the best advice is to let down your ego. Remember that we’re there to do the job for the client, NOT to take the job from the 3rd party consultant.

Take the time to explain the whole process and treat him like he’s part of the management. Again, the key is to convince the 3rd party consultant to allow you to take the lead on the implementation, then have him take the lead for taking over ongoing support.

Ensure that you do not let him/her feel threatened that you’re going to discredit him or take his job, this is NOT what we’re there to do.

There aren’t that many how-to documents on the Microsoft Customersource website. However, this one has to be one of the most important must-reads for all Navision (Dynamics NAV) end users and implementers wishing to setup fixed assets in Navision.

The article is titled - “How to Set Up Modified Accelerated Cost Recovery System (MACRS) Depreciation in Fixed Assets” and can be found here:
https://mbs.microsoft.com/customersource/documentation/howtodocuments/msd_navsetupmacrsforfa.htm

For end users, you will need to be current on the Microsoft Enhancement Plan in order to view the document. 

This document will teach you how to setup Navision so it can properly depreciate fixed assets according to IRS specifications.

As an implementer, I always encourage the client to use Dynamics NAV for all of their accounting and bookkeeping. This is especially true since the system can be easily setup and used. In addition, keeping all the books in Dynamics NAV will allow you to freely choose the right CPAs for your company without having to be held prisoner by one CPA. It also ensures continuity of your records should you have to switch to a new CPA.

During a new implementation of Dynamics NAV (Navision), most Dynamics NAV (Navision) consultants understand how to load in A/R and A/P beginning balances. However, when it comes to bank beginning balance. The subject is usually more murky. On one hand, you need to put in the bank balance so it shows up on the bank ledger, on the other hand, if you put in just a lump sum, doing the first bank reconciliation will be a nightmare.

The goal when entering a beginning bank balance, is to update the bank ledger to ensure the amounts are correct. In addition, the bank transactions that are not cleared needs to be come up so it can be properly reconciled.

In this example, we’re going to assume the Navision client is going live on 1/1/2010.

Here’s the information we need from the client:
1. The G/L bank ending balance as of 12/31/2009
2. The last bank statement (from the bank obviously) on 12/31/09
3. The beginning G/L balance

First of all, the Dynamics NAV (Navision) client or the consultant needs to itemize what checks are outstanding (not cleared yet as of the 12/31/09 bank statement).

We all know that to load in beginning G/L balance, we use the General Journal. We typically use loading of beginning balance as the same step as we load in the bank balance.

Let’s say the Dynamics NAV (Navision) client has the following:
Bank Balance on 12/31/09: $10,000.00
Outstanding Check #123: -$2,500.00
Outstanding Check #124: -$500.00
Deposit on Hold: $1,000.00

While we load in the beginning balance, we set the Account Type as Bank Account. Doing this will automatically update the bank ledger and the G/L ledger based on your Bank Account Posting Group.

So your beginning G/L balance would look like the following:

Assuming you received a bank statement on 1/31/2010. There were no transactions that were cleared and no additional transaction made to the bank. Your bank rec would look like the following:

Doing so, the transactions will match exactly to the bank statement and to the G/L.

In conclusion, you can say that the bank beginning balance is the Bank Balance + Outstanding Checks - Deposits on hold.

First of all, there are no 2 businesses that are exactly the same. I don’t care if they’re in the same industry, if the owners are siblings, and/or if they live in the same household. Companies are as unique as the fingerprints of the owners that run them.

As such, no 2 implementations are exactly the same. This is because the people that work inside the companies are unique. They live the company culture that are defined by their managers. And the company culture are as unique as the personalities of the people setting them.

There has been countless times where I hear “we do everything like everyone else” or “can’t we take what you did for other customers and implement it here?”. No. You don’t do everything like everyone else and no, we will not take other implementations and apply it here. Unless we want to guarantee failure.

If you’re a robot and have no personalities, or you want to fit your business process to the software, then use Quickbooks. Any other unique data that you need to keep track of, use Excel. Don’t bother buying an expensive hard-to-modify software that you will have the same problems with if you were using Quickbooks.

For the record, Microsoft Dynamics NAV (Navision) is an easy to modify software that fits your business like a glove. As such, there are setups that will be involved to fit the software to your business.

There are definately similarities that applies, however, the task is up to the implementor to make recommendations on how to implement these similarities without making too much distruptions to your business.

Having said that, making a post about the average cost to implement Microsoft Dynamics NAV (Navision) will surely draw criticism. This post is about MY experiences implementing Navision. OUR Dynamics NAV (Navision) practice is DIFFERENT than other company’s practice. OUR company is unique, just every company out there is unique. So before you flame me, remember this is based on MY experience, NOT yours because you are not me and I am not you. You and I live in different areas, grew up with different environment, eat different foods, breathe different air, is allergic by different things. Did I get my point across? Good.

These numbers are based on the implementation using the Classic client. We find that the Role Tailor Client is more suitable for management for doing analysis and running reports, not for data entry. For order processing, manufacturing processing, etc. we find that using the Classic client is a lot more fitting and more user friendly.

The initial implementation is to always to replace their old system with NAVision. The new features and functionalities are nice and will definitely reduce the expenses for the company, but unless they’re mission critical, we usually recommenend holding off introducing new processes until NAV is up and running. The reason we do this is because we don’t want to overload end users with too much new information where they will feel overwhelmed. For example, if the companies uses 3rd party software to process EDI and the users are used to it, we would hold off integrating EDI into NAV on the next phase whenever the customer is ready.

As a rule, we always recommend the client purchase the base of any addons they may use in the future. For example, if the client plan to integrate EDI into NAV, we always recommend the client to buy Packing (the minimum requirement) and use Lanham’s E-Ship/EDI database from the beginning. This will reduce time to merge the objects when everything is up and running.

Ok, so here it goes.

Our typical new NAV client for us has the following traits:
- Users: 11 to 20 users
- Locations: 1-3 location
- A distrubtion based company. (They usually import goods from overseas, repackage it, and sell them in the US.)
- Sometimes with light manufacturing (at most, running production BOMs without using MRP)
- Light warehousing (maybe using warehouse receipt and warehouse shipments).
- Some EDI Trading Partners

The time spent on an implementation like this are, based on the quotes I’ve written, are between 120 - 200 hours.

Some of the basic time required are:
Initial Analysis and Writeup (30 - 40 hours)
Database installation and setup (10 hours)
Development (30 - 60 hours)
Training (30 - 50 hours)
Onsite after Live date (20 - 40 hours)

The development usually includes:
- Customer information Import
- Vendor information Import
- Item imformation Import
- A/R balance import
- A/P balance import
- G/L balance import
- Open Sales Orders import
- Open Purchase Orders import
- Inventory balance import
- Busines forms modification (SO, PO, customer statement, etc)
- Mission critical modifications that’s not in base NAV
- Misc. tweaks during user training
- Transfer of all data with dataports written on the day before live

The software price is set by Microsoft. There’s nothing we can do about that. The hourly rate are different by region, so do your homework and find what the hourly rate for your region is. Around my area, it’s about $150 - $200 an hour. But don’t print out my blog to use as a bargaining tool. It won’t work.

When moving from a legacy system into Dynamics NAV (Navision), one of the areas you want to try and avoid is messing with the inventory G/L accounts. Most systems are usually pretty good with open A/R and A/P accounts, they can be transferred using the “posting back to the same account” technique that most implementers do. The beginning A/R and A/P G/L accounts would be based on your entry on the General Journal. This is assuming that the A/R and A/P aging reports matches the G/L.

Inventory valuation is one of the areas where we find the most discripencies based on what is entered on the Item Journal  from the physical count and the inventory valuation report from the legacy system. Depending on your requirements, sometimes it doesn’t make sense to go through line by line on the item journal to see where the differences are.

A rule of thumb I always go by is to let Navision determine what the inventory value should be in the G/L based on the positive adjustments posted from the Item Journal.

To accomplish this, do the following:

Suppose you have the following G/L accounts:
11000 - Inventory
58850 - Inventory Adjustment

When posting a positive adjustment in the Item journal, it will post a debit to Inventory and credit to Inventory Adjustment.

When you’re ready to enter your beginning G/L balance, enter the G/L balance for Inventory to account 58850. This way, the difference between the inventory G/L balance from the legacy system and Navision will be reflected on account 58850.

If you do not want to reflect the adjustment in the current period due to financial reporting reasons, you can adjust the difference into an asset account. We usually recommend create a separate account (i.e. 11100 - Inventory Suspense) to store this difference until you can depreciate it.

By not posting any general journal entries to the inventory accounts, you’ve ensured that inventory valuation reports will ALWAYS match G/L, making everyone happy in the process.Â