Why you should build a healthy relationship with your data

Overview

Having worked with Dynamics 365 Business Central (Dynamics NAV) for years, one of the biggest concerns I have when working with clients is receiving a really big Excel file with a message saying “my numbers don’t match! Please match it up for me!”

While I always love a good challenge on solving complex problems, after some time, these types of questions concern me. Most of the time, the client did not do their work on looking through the spreadsheet and did not try to figure out where the numbers went wrong before sending them to me.

Part of the challenge with working with anything new is to put in your own work and your own time. You can see the process as a time investment, but also the understanding of how to diligently figure out where the numbers are going when you perform certain actions within Business Central.

Being Young and…Not so Wise

Back in the days when I was a young consultant, I would always solve these big Excel sheet problems myself and help customers make sense of the numbers in the huge spreadsheet.

However, a few months later, the clients would inevitably come back with another big spreadsheet asking me to figure it out for them again…And again and again.

Hey, these were free billable hours, so why not?

Over the years, I realized what I was doing was wrong.

All the knowledge that I’ve built analyzing the data and tracing the transactions through Business Central was almost impossible to transfer to my clients. While I can tell them where to go to do the tracing, knowing how to do it, what tools to use, and what fields to look at is really the key.

More often than not, when I was telling the clients where to do the tracing, the clients kind of nodded, acknowledged what I said, but in the end just took my answer as is, without really understanding how to get there.

These hours I spent getting to know my clients systems and data, in the end, was lost – and that’s something they could have benefited from if they did it themselves.

Knowledge Lost

Effectively what I was doing was showing the client how to fish, but in the end, I was giving the client the fish. By doing all the work myself, I was robbing my clients of the ability to gain further understanding of their own data and how they relate to Business Central (Dynamics NAV). More importantly, they wouldn’t grasp the key understanding of what tools to use so they can navigate their data within their system.

Even if I figured out the mystery, the client did not get the key knowledge of how to figure it out themselves the next time their numbers don’t match. All the knowledge about reconciling between their Excel sheet and Business Central (Dynamics NAV) was then lost.

Instead, I realized that the smarter thing to do was to teach the users how to fish and insist on the clients to do the fishing themselves! In the first few tries, I would walk through with the user on the data they’re looking at, then assign them the tasks that I would do if I was doing the work. They would come back with the results from the first lists of tasks then I would guide them to the next set of tasks, and so forth, until the conclusion is reached.

Conclusion

We all need help with what we do. We grow up with the tradition of transfer of knowledge, by learning from someone more knowledgeable. With more knowledge about your surroundings, life will inevitably get easier because then, all complex problems can be solved without too much effort.

One big part of having an easier work life is to understand what’s going on with your operation and how it translates into your system. There’s no way to build this knowledge without doing your work yourself beforehand. You need to understand your tools and understand your data.

I find that the users that are able to pick up the system the quickest are the ones that come to me with specific questions confirming their suspicion.

For example, if my clients asks whether they can change an account setting on the General Posting Setup to affect certain sales transactions because they want their financial reporting to look a certain way – rather than asking me why their revenue accounts don’t match the financial reports they want – that’s a sign that eventually, they’ll be able to figure everything out by themselves.

Building an understanding of your data and your system can take more time at the beginning, but it pays off in the long-term, and in the meantime, AP Commerce is there to get to know them!

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.