ArcherPoint Dynamics NAV Developer Digest – vol 82

The ArcherPoint technical staff—made up of developers, project managers, and consultants – is constantly communicating internally, with the goal of sharing helpful information with one another.

As they run into issues and questions, find the answers, and make new discoveries, they post them companywide on Yammer for everyone’s benefit. We in Marketing watch these interactions and never cease to be amazed by the creativity, dedication, and brainpower we’re so fortunate to have in this group—so we thought, wouldn’t it be great to share them with the rest of the Microsoft Dynamics NAV Community? So, the ArcherPoint Microsoft Dynamics NAV Developer Digest was born. Each week, we present a collection of thoughts and findings from the ArcherPoint staff. We hope these insights will benefit you, too.

Note on Avalara support for NAV 2009:

Beginning May 1st, Avalara will no longer be supporting Connectors for Dynamics GP 2010 and Dynamics NAV 2009. Clients can continue to run this software; however, Avalara will no longer provide software fixes. Avalara will provide software updates, fixes, and support for versions of Dynamics which are under "Mainstream" support by Microsoft. We wanted to make you aware in case clients are still running these older versions of Dynamics GP and NAV and to let you know the latest supported AvaTax software is available for them to install.

Here are some key reasons clients should update their connector version as soon as possible:

• Improved performance and usability: Avalara is always working to improve performance and usability of the AvaTax for Dynamics Connectors
• Improved functionality: See the Release Guide for Dynamics NAV Connector and Dynamics GP Connector
• Software support: To avoid possible issues now and in the future, Avalara recommends that clients update their connector now

Here’s how clients can get the latest version of the AvaTax for Dynamics GP and Dynamics NAV:

1. Download and follow the Steps to Install Dynamics GP / Dynamics NAV

2. Ask your questions in the Avalara Community

To contact Avalara support, email support@avalara.com or 877-780-4848, option 2.

Saurav Dhyani discusses handling an error message during data migration:

In case you ever get the error message during data migration From NAV 2009 TO NAV 2015:

"The Metadata object Table was not found".

It took lot of time, to figure it out, but with Help of Mahadevan, we figured it out. The issue is:

We deleted some Custom Tables having references to Dimension Tables. When the System tries to assign a Dimension Set ID to the Table, the Table is not found.

Resolution steps:

If you delete any Custom Tables / Vertical Tables, make sure to delete all references from the Dimension Tables in NAV 2009.

Figure 1. Error during data migration: "The Metadata object Table was not found"

Helle Madsen: During upgrades, I've also had to delete records directly in SQL from that table; Object Metadata.

Kyle Hardin offers this Sneaky Code Trick of the Day: Use for a CASE switch:

Sneaky Code Trick Of The Day: This is a neat use for a CASE switch.

CASE TRUE OF

condition 1

condition 2

Of course, you have to work the conditional logic such that you don't have more than one positive, but still... I've always used a CASE to test for specific values, not to run a bunch of condition testing until you find the one that is true.

Jon Long: If this interests you, you will enjoy reading about "truth tables". Truth tables are a way to have a table of conditions, then refer to the table with your "case". Truth tables allow you to store combinations of conditions that represent every possible combination of the case, not just true or false. Let's say you have to evaluate if A, B and C are either true or false and have a case for each. Your "truth table" would contain every possible combination and would look like this:

A B C

True True True

True True False

True False True

True False False

False False False

False True True

False True False

False False True

So, you can see that with 3 conditions, there are 8 possible combinations. You can then write a case statement that simply looks at the table for the case result, perhaps even referring to a 4th field in the table for a command, or Entry No.

I once had to write a program that used a truth table that had 8 conditions. It would have been nearly impossible to write a Case statement to include every combination, so, the truth table made the code easily readable and manageable.

I can't remember the program, it was years ago, but, it had something to do with setting priorities for donors and triggering interactions based on several complex criteria, including donation amount, program affiliation, several statuses etc....

I've had one reason to ever use a "truth table", but, if I was in more of a developer role, I could think of many applications where it could be used.

Come to think of it: The new Dimension Set Entry table is a type of truth table. It stores every possible combination of dimensions, each of which can be referred to by the field in that table called Dimension Set ID. So, that is a very good example of a truth table making a data intensive process much more efficient. For example, 100 Million Dimension Ledger Entries can now be represented by a mere 10 thousand combinations.

You can Google "truth table" and find a plethora of very boring math centric pages on this subject. Cheers.

If you are interested in NAV development, check out our collection of NAV Development Blogs.

For step-by-step instructions on how to perform specific tasks in Microsoft Dynamics NAV, see our collection of How-To blogs.

If you found this post useful, you might also be interested to read through our archive of the Dynamics NAV Developer Digest.