Confessions of a Dynamics NAV Consultant

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!

Accounting Cost vs. True Cost

In Microsoft Dynamics NAV, when doing costing and profitability analysis, you need to differentiate between a transaction's True Cost and Accounting Cost. Don't bother looking up these terms in the manual, I made them up for a lack of better terms.

To better explain the difference between True Cost and Accounting Cost, we will use this example:

8/15/08 - Item A was received at 10 pieces for $2.00 each.
8/30/08 - 6 pieces of item A was sold for $5.00 per piece
9/1/08 - The vendor invoice for Item A is posted at $3.00 per piece
9/15/08 - The freight invoice came in and item charge is used to allocate an additional $1.00 per piece
9/20/08 - The rest of the 4 pieces of item A was sold for $5.00 per piece

Accounting Cost:
Assuming on 9/30/08, you're asked to do a sales analysis for the month of August. When the costing is analyzed for the sales made on 8/30/08, the COGS that accounting recognize will be $2.00 per piece. This means that if we're printing reports based on Value Entry posting date filter from 8/1/08 to 8/31/08, the profit margin would be 60% per piece. Not bad! For accounting, the cost is indeed $2.00 per piece since that's the only amount that was recognized in that period. (Some companies makes an accrual on the G/L side for the expected cost of good sold, but that's a separate topic). This number to management, of course, is incorrect.

True Cost:
In actuality, the cost of the item should be $4.00 per piece because each piece came in at $3.00 with an additional $1.00 in freight charges. The margin of the item should be 20%.

Another scenerio is you're running the sales report from 9/1/08 to 9/15/08, you would show 0 quantities sold, but the cost recognized in that period would be $12.00 ($1.00 in the additional vendor cost + $1.00 in the freight cost * 6 pieces sold). If you did not check this report and you present this report to the management, be prepared field a load questions on the integrity of both you and the numbers.

Solution:
Both Accounting Cost and the True Cost are correct! Do not assume otherwise! It's just a matter of how the user wants to look at the numbers. For accounting, they need the numbers to be recognized in the proper periods so the previous period numbers does not get changed. For management, they want to see the true cost of sales transaction. What to do?

As a simple rule, the Value Entry stores the accounting cost, the Item Ledger Entry stores the true cost. Since most NAV reports dealing with Contribution Margin uses Value Entry table, we typically remove those field from the report because they are misleading for everyone. We create separate reports using the Item Ledger Entry table taking the Cost Amount (Actual) since it rolls up all the costs associated with the sale transaction.

One thing to note when presenting the report off of the item ledger to the management, depending on when you post the vendor invoice and other landed cost charges, the profitability number will change. This means that, in our example, the profitability report ran on 9/1/08 will be different than the same report with the same filters ran on 9/20/08. However, in my experience, once you properly explain this concept to accounting and management, they will understand.

Where do you put the Customer PO No.?

In Dynamics NAV 5.0SP1, the caption for Your Reference has been changed to Customer PO No. For us, we've always used External Document No. to store the Customer PO No. on the sales order.

It's obvious that the change in 5.0 SP1 was done due to partner requests. I just want to get your opinion on where you put the Customer PO No. when entering a sales order. Please vote here:
http://dynamicsuser.net/forums/t/23238.aspx

My Microsoft Conundrum

First of all, let me state that I'm a amateur investor in the stock market. I have a discipline when it comes to stock investing in that I look for companies with good products and/or strong management. One of the major holdings I have is Microsoft (MSFT), in fact, my Microsoft stocks takes up about 20% of my portfolio.  As an investor, I want to see the stock shoot up and demostrate increased sales of the product quarter after quarter. Likewise, I want to see the profit increase quarter after quarter.

The reason I bought Microsoft stock is because I believe in their products. I believe in their vision of "business software" will be. As to what I believe their vision is, that's a separate BLOG post.

As you all know, I'm also the principle of AP Commerce, Inc. based in Los Angeles. We are a small Certified NAV partner; we do nothing else other than to implement Microsoft Dynamics NAV (Navision). Personally, I've been working with NAV since 1999 and have been involved in hundreds of implementations to date. Our company is created to be a service company, not a software sales company. It just so happens that NAV is the product that we uses so we can help our customer achieve greater success.

However, this post is not to discuss accomplishments. It's a genuine conundrum I have being an investor of Microsoft and a business owner doing business with Microsoft.

Before I continue, let's make one thing clear about Microsoft. Microsoft is in the software sales company. Their core business is to sell software. Not service, not hardware, not internet content, not social media, not whatever. Yes, we all can see they're trying to diversify, but at the end of the day, their business is to sell software. Period.

It's not a secret that Microsoft loves partners that can sell and sell and sell. Since Microsoft channel reps are evaluated by how their region performs, channel reps throws all of their support and time into partners that sells. As an investor, I love this strategy. More sale means more revenue and hopefully fatter profit. By exceeding these arbituary numbers set by Wall Street, stocks shoot up. Wall Street loves growth. When I receive the annual reports from Microsoft, I always turn to the revenue and the profit section. I look at how much revenue growth this year as compared to the previous year, and the year before that. I look at the earnings per share, I look at what the cost of doing businesses. In short, I want to see growth and more GROWTH! In the world of Wall Street, public companies are evaluated by the quarter. If the quarter sucked, the company will get hammered and executives get fired...

As such, it's not a surprise that Microsoft wants more partners to sell all of their product suites. And more and more hardware dealers and bulk software retailers find out about Microsoft Dynamics NAV (Navision), studies the manual, pass the required tests, and acquire the competency to sell Navision (among other softwares). In a push to sell more software, my suspection is that even larger solution centers, to be more aligned with Microsoft strategy have shifted their focus software-sales centric.

As a business owner working with Microsoft Dynamics NAV. I'm deeply concerned by this practice. As we all know, selling and implementating Microsoft Dynamics NAV is different than selling and implementing Microsoft Office or setting up a network using Windows 2003 Server or implementing Exchange Server with Sharepoint. Without proper skillset or the resource, the implementation of ERP usually fails. Once the software implementation fails, customers blame the software, the vendor, and ultimately, Microsoft. 

These bad implemenations creates a deep distrust in Microsoft; confirming their belief that Microsoft is an Evil Empire and all of Microsoft products suck. Pretty soon, word of mouth spreads (business executives and managers have powerful friends) and before you know it, more and more people have the mental imprint that Microsoft sucks because their friend of a friend got screwed. For the record, Microsoft products does NOT suck. Microsoft Dynamics does NOT suck.

Most of these companies either bite the bullet and live with a software that they can't really use and hates Microsoft for the rest of their lives, or they call around for other solution centers to come help them out. We have quite a number of situations where companies called us help asking us to help them with a failed implementation. In one instance, the owner of a company that bought NAV over a year ago expressed to me that he absolutely hated Microsoft and his lack of due dilligence in selecting the right vendor and the software. He couldn't believe that his original vendor got to be a Gold Certified Partner. He was so upset that he wanted to sue the solution center and Microsoft.

To make a long story short, I accepted the task and decided to let the chips fall where they may be. Fortunately, we were able to help them out quite nicely and the owners and the employees became a fan of NAV. Not only did they became our reference and paid their bills in full and on time, but they also agreed to go back on the enhancement program with Microsoft and bought additional NAV sessions. In the end, by making the customer happy, they ended up doing more business with Microsoft.

When I started the company, I promised myself that we would be a service company, not a software sales company. What we did for this company took time. It takes time to ask the company to believe in us, then to believe in NAV, then to believe in Microsoft. Trust is the hardest thing to build once it has been broken. Unfortunately, the time Microsoft spends working with this customer doesn't translate into revenue quickly.

As a business owner who believes in Microsoft, I want Microsoft to reward partners that can do the job correctly, not reward partners that can only sell. As an investor, I want Microsoft to spend the time and effort supporting people that can generate revenue quickly. So I can see an increase every quarter and see Microsoft meet or exceed Wall Street expectations.

How would you recommend balancing being a service company and being an investor?

Etiquette for Contractors Dealing with Solution Centers and Vice Versa

Just thought I post some etiquette for Solution Centers (NSC) and contractors when dealing with each other.

For Contractors:
1. There's no such thing as job security when you're a contractor. If you want security, find a full time position at a NSC.
2. Do not set your rates based on how much the NSC charges their customers. Figure out a market rate for your skillset and make it fixed.
3. Contractors are used only for the short term. If you want long term, find a full time position at a NSC.
4. Learning time is not billable. Companies hire your skillset to produce, not to learn. If you want to be paid for learning, find a full time position at a NSC.
5. You have the right to say no to a project. But say no before a single minute is charged.
6. Make a conscience effort to not steal your client's customers. The end users will decide on their own, but do not push it.
7. Do not make a promise to deliver you cannot keep. Sometimes, a lot of people are waiting on you to finish before they can continue.
8. Make doing business easy with you. NSCs do not need you if you give them more headaches than they already have.
9. The NSC has the right to shop around for whatever reason, you're a vendor and this is a business transaction. Don't take it personal.

For NSCs:
1. Pay your contractors on time. You hired them to produce, if they've done so, pay them. Don't play games.
2. Sometimes, trial and error is needed to get to a solution. If the contractor bills you for it, pay; because you will need to do the same if you were doing the project yourself.
3. Murky project scope will get murky results. If you cannot properly define the project, no contractor in the world will be able to clarify it for you. And pay the large bill your contractor will surely bill you because you didn't do your job.
4. If you rely on the contractor to take care of your customer, you WILL lose the customer. Guarenteed.
5. Contractors you hire have their own priorities, so plan accordingly. If you want the contractor's dedication, offer them a full time position.
6. Contractors are used to address specific needs. They're not there to organize an implementation for you.

Did I miss anything? Any additions to both sides are welcome.

Warning about Upgrading to NAV 5.0 from 3.x and 4.x

IF you are using Average Cost and IF your Average Cost Calc. Type is Item & Location & Variant, when you upgrade to 5.0. The cost calculation type will be set to ITEM.

At this point, DO NOT RUN ADJUST COST!!! It will calculate your average by ITEM for all historical transactions irregardless if you changed the Average Cost Calc. Type to item & location.

This is a problem in the Avg. Cost Adjmt. Entry Point table and the Accounting Period table. You will need to write a process to update the Avg. Cost Adjmt. Entry Point table so it's by location, and change the Accounting Period to Item & Location & Variant.

Here's the code for download:

http://www.mibuso.com/forum/viewtopic.php?t=23585

Sharing the Item table in version 5.0

If you're in an environment where you have multiple companies setup and each company uses the same items, you might be tempted to share the item table across all companies.

In versions prior to 5.0, you can get away with this since the Adjust Cost process are done using the Item Ledger and Item Application Entry table. When inventory is taken out, it'll use the proper average cost when the Adjust Cost process is ran.

However, in version 5.0, they introduced the Avg. Cost Adjmt. Entry Point table and the Cost is Adjust field on the item card. This means that if if you just share the tables and adjust cost is ran for Company A, it'll mark the Cost Is Adjusted to true. This means that the Adjust Cost process will never be ran for Company B. In addition, when transactions are posted for Company B, it'll look at the Avg. Cost Adjmt. Entry Point table and detect that the cost has not been adjusted and mark it for adjustment again.

The best solution to this problem is to suggest the users to update item information for both companies. However, if the business requirement is to share the Item table, it's recommended that you keep the tables separate. And write a batch process to update items at the end of day or if it needs to be real time, write code to something like:

  ItemCompanyB.CHANGECOMPANY('Company B');
  IF ItemCompanyB.GET("No.") THEN BEGIN
    CostPostedGL := ItemCompanyB."Cost is Posted to G/L";
    CostAdj := ItemCompanyB."Cost is Adjusted";
    UnitCost := ItemCompanyB."Unit Cost";
    ItemCompanyB.TRANSFERFIELDS(Rec);
    ItemCompanyB."Cost is Posted to G/L" := CostPostedGL;
    ItemCompanyB."Cost is Adjusted" := CostAdj;
    ItemCompanyB."Unit Cost" := UnitCost;
    IF NOT ItemCompanyB.INSERT THEN
      ItemCompanyB.MODIFY;
  END;

You can probably write a better code, but you should be able to get the idea. This will also require that all the item master information be entered into one company.

Abnormal Posting Dates

Abnormal posting date entries happens when the Posting Date of the receipt/shipments of inventory is after the Posting Date of the invoice. Why does this happen? You'll need to ask your CFO or Controller. Typically, I found this more in return orders where the receipt of the product is a certain date, and the accounting department decides to post the credit memo in prior dates.

Either by mistake or intentional, if this happens, your Inventory Valuation will not tie to your G/L.

Here's a step by step on how to replicate this problem, and how to solve this problem:
1. Create a sales order with posting date of 11/01/08
2. Post the Shipment with a posting date of 11/01/08
3. Change the posting date to 09/01/08
4. Post the invoice
5. Run your inventory valuation report as of 9/30/08
6. Notice that the item is not taken out? But if you look at your G/L, the inventory value is taken out.

This will work for purchase side as well. It doesn't matter how to do it either using warehouse shipment/receive, the underlying process will net you the same problem.

Usually, problems like this won't come up until the user is trying to do month end and gets really frustrated on why their inventory doesn't tie to G/L. Unfortunately, there's no easy way to reverse this transaction after it's posted, the only way is to run a report at the end of the period to see what transactions have this "Abnormal Posting Dates".

Here's a report that will give you all the transactions that have abnormal posting dates. If you take this amount, add/subtract it to your inventory valuation report, it will be equal to the G/L inventory.

To run this report, just put the period you want to close on the Posting Date field. For example, if you're trying to close November 2008, then your Posting Date filter should be 11/1/08..11/30/08.

Here' the link for the report:

http://www.mibuso.com/dlinfo.asp?FileID=920

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. 

Question of Morality?

A few weeks ago, a CFO that recently joined his company called us up asking to quote Microsoft Dynamics NAV to them. This company had gone through a couple of management changes, got sold to another company, and then resold again to a group of private investors. Needless to say, none of the current employees have been there very long.

It just so happens that the CFO had used Navision before and loves it very much. He had gotten several quotes from different solution centers which were all about the same price.  In the end, for whatever reasons, we were able to win the deal.

By this point, the budget was approved for the amount specified on the quote. When we place the order with Microsoft, to our surprise, the company had purchased Dynamics GP back in the 90’s that no one knew about. This meant that we were able to receive credit from Microsoft and apply the credit to the cost of the software. The amount of the credit was 50% of our total software deal. So this is a significant amount and would cut into our profit for this deal.

At this point, two scenarios quickly came into my mind:

1.       Keep my mouth shut and fulfill the amount as specified on the original quote. Basically we would be able to book the difference as pure profit.

2.       Tell the customer of the credit from Microsoft and apply the credit to their quote

This basically came down to whether or not we should pocket the money or be honest and give the customer the credit they deserve.

It took me some time to decide what to do. The choice was hard but it was a decision that I would expect myself to make and the people we work with to make. It’s the way we’re brought up. Its’ way we build trust. It’s making the world a more pleasant place to live: I was to give the credit to the customer from the software purchase.

Before making the phone call to inform our new customer the good news, another thought came to my mind; was this good news for the CFO? I could only imagine the questions he would face if we invoice him for something that was significantly different than the amount specified on the quote:

“Why didn’t you do your due diligence and realize that the company had purchased GP before?”

“Why didn’t you know that you could’ve applied the credit the company had in GP?”

“What other things the board hired you to do are not done properly?”

“How can you propose such a budget if you don’t have the grasp on the proper information?”

“How can the company trust your decision making ability in the future?”

Would I be the person that will cause his loss of credibility with the CEO and the board and ultimately his job? Or was I just thinking too much?

 I picked up the phone and delivered the whole story about the Microsoft credit to him privately. As I expected, there was no congratulatory remarks or a word thanking us for our honesty. He listened intently, paused for a few seconds, and then said, “Hmm… We bought the software that long ago and they still recognized it? Go ahead and send us the invoice then.”

From his paused, I can sense that for a few seconds, millions of thoughts went through his mind as well. What were his thoughts? God only knows, because I wasn’t going to ask him.

In the end, there was no right or wrong. It could be right or wrong depending on how you look at the situation and who you are. I did what I thought was the right decision; it was information that I would’ve liked to receive if our roles were switched. I would not like it very much if I found out this information on my own at a later date.

I guess that’s why we were able to win the deal.

How to Print to local printer using RDP

This is a poor man's way of having users connect remotely and allowing them to print locally. Using RDP, you will not have to spend money on an expensive product like Citrix unless you really have to. Note that Citrix is a great product, but it's out of reach for customers who have limited IT budget.

1. On the remote computer check to make sure the “Printers” box is checked on the “Local Resources” tab of the “Remote Desktop Connection”.

2. On the server install the printer driver that the remote user has. 

3. When the remote user connects the server will now see all of the remote’s printer ports

4. The remote user will now need to go to the “Printers” folder of the host computer and change the port setting 

5. When they click on the “Ports” tab of the printer they will see a list of all available ports. The ports that refer to the remote user will appear as TS00x (Where x will be 1-8 depending on the number of installed printers the remote user has).

6. Started with TS001 printed a test page. If that doesn't work, then changed the port and keep test printing until something prints on your computer.

Why you have Negative Inventory Value with 0 Quantity – Navision 3.7b to Navision 5.0

Here are a couple of reasons why you would get inventory value if you have 0 quantities when you print Inventory Valuation report and Inventory to G/L Reconcile report as of a certain date.

If the adjust cost is processed on 7/31/07, and the Allow Posting From was 7/1/07 on General Ledger Setup, the following would occur:

6/15/07 - Purchase Receipt - $10

6/28/07 - Ship and Invoice - $10

7/15/07 - Purchase Invoice - $12

7/31/07 - Additional Cost for the sale made on 6/28/07 - $2

In this case, when you print the inventory valuation as of 6/30/07, the inventory quantity would be 0 and the inventory value would be 0.

If the adjust cost is processed on 7/31/07, and the Allow Posting From was 6/1/07 on General Ledger Setup, the following would occur:

6/15/07 - Purchase Receipt - $10

6/28/07 - Ship and Invoice - $10

7/15/07 - Purchase Invoice - $12

6/28/07 - Additional Cost for the sale made on 6/28/07 - $2

In this case, when you print the inventory valuation as of 6/30/07, the inventory quantity would be 0 and the inventory value would be -$2.00.

Explaination

Navision will automatically post the additional cost to the original invoicing entry because that’s where the cost originally applies to. If Navision detects that the Allow Posting From is before the adjusting date, then it will use whatever the Posting Date is when the adjust cost is ran.

If the adjust cost is processed on 8/31/07, and the Allow Posting From was 7/1/07 on General Ledger Setup, the following would occur:

6/15/07 - Purchase Receipt - $10

6/28/07 - Ship and Invoice - $10

7/15/07 - Purchase Invoice - $12

8/31/07 - Additional Cost for the sale made on 6/28/07 - $2

In this case, when you print the inventory valuation as of 6/30/07, the inventory quantity would be 0 and the inventory value would be 0. When you print the inventory valuation as of 7/31/07, the inventory quantity would be 0, but the inventory value would be $2.00.

Explaination

Navision will automatically post the additional cost to the original invoicing entry because that’s where the cost originally applies to. If Navision detects that the Allow Posting From is before the adjusting date, then it will use whatever the Posting Date is when the adjust cost is ran. In this example, since the Adjust Cost process posting date is 8/31/07, it will use this date as the Posting Date for the adjusting entry.