Tag Archives: Dynamics NAV

Entering Beginning Bank Balance for Dynamics NAV (Navision) for a New Implementation

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:

Beginning Entry for Bank Balance for Dynamics NAV

Beginning Entry for Bank Balance for Dynamics NAV

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:
BankRec
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.

Dynamics NAV (Navision) Can Solve All of Your Business Pains!

Dynamics NAV (Navision) can do anything for your business. Yep, you heard it right. Implementing Dynamics NAV (Navision) can solve all of the problems for your company. It’s true! Since working with Dynamics NAV (Navision) in 1999, I have never encountered a business problem that cannot be solved in Dynamics NAV.
Compliance? No problem.
Reporting? No problem.
Unique business processes? No problem.

AND! Implementing Dynamics NAV will solve your company’s problems within a reasonable budget!

But how is that possible? We all know every software has it’s limits. What if customers makes irrational requests? What if the salesperson over promised? What if the project will take 1000 hours to program?

You can probably think of a million more “what if”s. The bottom line is implementing NAV will resolve all of your client’s business problems. You absolutely need to keep this mentality or you won’t have a successful career in NAV.

First and foremost, you MUST believe this as well. All Navision programmers knows how quick it is to deliver on customer’s request and it’s unique ability to adapt to any environment. If you do not believe this is true, you’re working with the wrong software.

The first step in truly believing this is remove the word NO from your vocabulary.

By being closed minded and using the word “No” too often, not only are you diminishing the potential of NAV to your clients. You are training yourself to become close minded on finding clever ways to solve difficult problems.

Do not say no to customers, instead, find alternative solutions. You should have enough experience to know if the requirements does not make sense. And you should have enough understanding of business process to give alternative solutions to address the client’s pains.

Take for example the following scenerio:
Client: “I want to go to the moon”
You:    “Why do you want to go the moon?” (while at the back of the head thinking “Oh crap, the salesperson promised the moon”)
Client: “I want to see the surface closely”
You:    “If I can get close up pictures of the moon’s surface, would that be sufficient?”
Client: “Ok”

Or this scenerio:
Client: “I want to go to the moon”
You:    “Why do you want to go the moon?” (while at the back of the head thinking “Oh crap, the salesperson promised the moon”)
Client: “I want to feel the moon’s atmosphere”
You:    “At the Kennedy Space center, you can feel the moon’s atmosphere. Would that be ok?”
Client: “Ok”

Instead of:
Client: “I want to go to the moon”
You:    “No, you can’t go to the moon, it’s not possible with current technology”
Client: “The salesperson said I can.”
You:    “No. It’s not possible, your request is illogical”
Client: “Get your salesperson back here, I want a refund!”

I know this is a very, very simple example, but you get the point. Every problem is diffcult and easy depending on how to approach it.

In an implementation, much like in sales, you need to get as many people on your side as possible. By throwing the word “no” around too often, you will be seen as an enemy trying to make their daily lives miserable. Furthermore, the client will be convinced that they have bought the wrong solution.

It’s important to keep a positive attitude during an implementation. Instead of directing customers to dead ends and killing their dreams and hopes, show them the light at the end of the tunnel by addressing their problems and pains in a different way. Engage their illogical request and do the work to make it logical for them. Listen carefully to their request and dig into your experience and knowledge to provide the customer with a better way. If all else fails, ask your client to write their request logically on a piece of paper (this always works by the way).

Consider this: No business that can buy NAV operates on flawed or illogical business process. So you can safely eliminate the probability that the client request is flawed or illogical. So the solution must be on the implementor/developer. It’s your job to recommend:
1. A solution
2. An alternative solution
3. A better solution

No one in the world likes to pay for “No”. And removing “NO” from your vocabulary is the first step on becoming the best implementor and developer in the world.

I know there are experts in the community that feel very strong about this. All comments (flame or non-flame) welcome!

Entering Beginning Inventory Balance

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.