Hardware Requirements for Dynamics NAV 2013 “NAV 7”

Looking through the hardware requirements for Dynamics NAV 2013, it looks like there are a couple of things the end user will need. More noteable, it looks like now the computer has to be running at least Windows 7 in order to use the NAV 2013 Windows client.

There are mixed feelings about this, while I do understand that Windows XP is no longer supported at Microsoft, I’d safe at least half of our customers that are using NAV are still using Windows XP. So if an upgrade is considered by the end user, they will have to budget for the OS as well.

Not to mention the new customers that are considering Dynamics NAV as their ERP of choice over the competitors. If XP is running okay, why am I going to spend another chunk of money on each computer?

Options Available
Fortunately, the era of desktop computing is dying. We actually have quite a few customers replacing the desktop computers with Thin Client boxes for each non-executive people in the office. What people basically do is RDP into a powerful server to do all of their data entry, report processing, e-mails, etc.

Let me say that these thin clients has dramatically lowered the IT cost of maintenance for each user in the company, not to mention virus infections, going to sites they’re not suppose to, etc. So the next time you’re planning to do a mass upgrade for all of the computers in your office, thin clients may be the better option. This is especially true in this case where the new ERP requires new technology.

Depending on how hard the community pushes back, maybe they’ll add XP compatibility probably as a service pack or something. I personally do not believe this is necessary, but I’m just one man.

Here’s a complete list of the requirements if you’re upgrading to Dynamics NAV 2013 or Navision 7.0.

Thought Process on Receiving Defective Inventory in Dynamics NAV

Receiving items from vendor can be a tricky thing. This question has come up quite a bit during implementation regarding defective inventory. I know a lot of companies has put a lot of modifications into receiving defective inventory, I’d like to propose an out of the box solution to receiving goods that have some defective quantities.

Here is the scenerio:
1. A purchase order came in on a container for ItemA with 100 pieces
2. Of the 100 pieces, 30 are damaged and they want to reject these pieces and send them back to the supplier
3. The user wants to be able to return the 30 pieces to the supplier and revert the Qty. to Receive to 30 to indicate there is still 30 to be received

Before we get into processing this, I want to bring up an important concept a person taught me when I was starting out doing Dynamics NAV:

Processing any task on a computer is no different than if you were to process processing a task manually.

This is a very important concept that changed the way I thought about automation, implementation, and how we can use Dynamics NAV (or any other computer software) to help us. This is especially true in the world of accounting where paper trail is everything. This concept is literally the difference between 100 hour modifications or 2 hour training session.

The Quick and Dirty Way
Looking at this problem, the natural instinct would be to do this:
1. Use the undo receipt function to undo what I’ve received
2. Post the receipt of the correct 70 quantities so the PO would look like it has 30 remaining on the original line

Here are the problems with the above approach:
1. Undo Receipt will not work if the received quantity has been sold
2. You have no record to match up with the vendor bill of lading
3. There is no record of the return to the vendor

Realistically speaking, is the truck unloading the shipment going to wait for you to do QC on the pieces received? The trucker has people to see, places to go, the trucker is a driver and probably does not even work for the vendor you bought the stuff from.

Being a developer with limited knowledge of operations, this would be the process that’s the easiest. For accounting, they want it easy and just want everything back to how it should be. For warehouse and operations, just do it and avoid the system at all cost.

This process would work in the perfect world. The problem arises if there are disputes, lost items, vendor reconciliations where they said you received some stuff but your records says you didn’t.

As I’ve said it time and time before, skip any data entered into the system you want as long as the financials balances out. The problem only arises when it’s time to reconcile.

The Manual Way
Going back to the original concept that’s laid out before, let’s solve the problem on the same issue if we had no computer in front of us. Here’s what I would do.

1. Unload the goods from the truck and sign the BOL because the trucker need to leave
2. Place the goods in a holding area in the warehouse to be checked/put-away
3. As the goods are checked, move the defective items into a separate area in the warehouse and put the good pieces in the warehouse bins
4. Call the vendor and say “Dude, your product is broken, I’m gonna return it. I also need you to replace the 30 that’s defective.”
5. Arrange transportation, prepare packing list, bill of lading, (if international, prepare commercial invoice, etc).

Bring in the System
Knowing how we process this manually, we can then replicate this into the system, in our case, Dynamics NAV:
1. Receive the items in full into the QC location (or into your main warehouse and into the QC bin if you’re using WHM)
2. As the items are checked, the good items should be moved to your main warehouse or bins using the item reclass journal or movement worksheet
3. Create Purchase Return Order for the defective goods. Use the document to generate the packing list, commercial invoice, etc.
4. Add a line to the purchase order to indicate replacement of the additional goods

Doing the above will create some additional steps and data entry, but it also has the benefit of having a paper trail. You need the full story on what happened to the PO. You need to show that you received 100 pieces originally, returned 30, then received the additional 30.

Each of the steps above can be handled by one person, but it should split out to ensure checks and balances. For example, it’s not realistic for the warehouse guys to call your vendor asking for a return.

In addition, it’s not realistic to generate a return every time there’s a defective part especially if the vendor is in another country. For returns dealing with international vendors, the company will ususally accumulate all fo the defective parts until they can fill a container, then process the return in one shot.

Again, doing things the proper way will create some additional steps, but I’m assuming you bought Dynamics NAV to help you organize your business, not creating more mess. Not every tasks requested by the end users will make sense in the long term.

It’s really up to the consultants to challenge the end user’s way of thinking and what’s the proper way to process certain business tasks. If you find that every request you made to the consultant always results in additional modification instead of training, you probably need to challenge your own request to see if your request makes sense if you were to do it manually.