Our firm provides specialty software for the printing industry from a company called PrintVis. Their print-industry specific solution consists of a wide range of added functionality that is baked into Microsoft Dynamics NAV (as they say, “You can buy NAV without PrintVis, but you can’t buy PrintVis without NAV”). That functionality has enabled them to automate close to 400 printing operations from the largest to the smallest, in dozens of countries around the world. So we thought we’d take advantage of their expertise by sharing their recent post (#134 in a series…) on the NAV Change Log, courtesy of a consultant by the name of Doug Wiley, who wrote the post for them. Excerpts follow…
In essence, the Change Log is exactly what it sounds like: a log of changes that are made in your database. Essentially, there are two types of “audit trails” in PrintVis: those that track transactional data (like inventory movements or changes to the G/L) and those that track changes to things like master records.
The first type is always on, and can’t be shut off. The second type is the Change Log, and that needs to be configured and turned on manually.
Turning it on is easy. You just search for “Change Log Setup” and open the window. There is a single check box which turns on the Change Log (in red). The more complex setup is in the background, which can be reached by clicking “Tables” in the ribbon in the window above (in green). Here you will determine which tables, and which fields within those tables, you would like to track. You have the option to track “Insertion” (adding a record), “Modification” and “Deletion” by table.
Also notice for that each of these you have the option to turn it off “blank” (even if the change log itself is turned on), track all fields, track some fields, or to select the fields you’d like to track.
The interface to this functionality is relatively simple, but the way in which it’s configured is where the nuance and decision-making come in. In the past, it was always recommended that the Change Log be used sparingly, to prevent the size of the database increasing too much when people altered records. Now that disk space has gotten more abundant, and cheaper, you can err more on the side of using it, but there is still a good reason to plan well: If you want to find who made a change, to what, and when, you will still need to sort through all of the changes that have been logged.
Fortunately, NAV has excellent filtering and sorting tools which will get you what you want – but still there’s no need to capture a bunch of changes which don’t really matter that much from an operational standpoint. Picking which fields in which tables you’d like to track is step one of this process. For example, you probably want to know if a customer’s payment terms change, but not so much if their main contact phone number or email address does. You may want to track if someone changes your posting group setup (which drives all your accounting and financial reporting), but not if someone changes the name of a journal batch. Your consultant will help walk you through this process and give examples of best practices.
The next step is choosing when you want to track these changes. Obviously turning this on when setting up a new database would be madness, since every change made by every new record imported would generate an unnecessary entry. Generally, it’s recommended to only turn it on once final setups and master data have been approved and put into the database.
The third and final step is maintaining which changes are tracked. For example, if for some reason there needs to be a mass update to your cost centers, you probably want to turn this off while that happens to avoid generating a bunch of data (and remember to turn it back on!).
Our thanks to Doug Wiley for pointing out these Change Log tips, which we will hope will help our NAV users get even more out of this most powerful and robust ERP system.