Change Log in Navision/Business Central

Estimated reading time: 8 minutes

Who changed article 4711? Who changed the terms of payment for debtor 0815? Why was the delivery condition deleted for the vendor Müller? It would be nice if Navision/Business Central could write (log) the changes to certain data. Not just with "Date modified" or "Corrected on" and a non-helpful date...

These questions surely sound familiar... but you don't have answers. Do you? You do! Navision or Business Central can answer these questions. With the 2009 version already. And you can use it with RTC and Business Central as well. That makes tracking and changes way easier than just the info with "corrected on".

Turn on change log

If you want Navision/Business Central to support you in the future when searching for the cause of justified/unjustified changes, you must first activate (switch on) the change log. At Navision Classic Client (e.g. versions 2.01, 370, 5.00, 2009 R2) please use the following path:
Administration/IT Administration/General Setup/Change Log Setup:

in RTC starting from NAV 2013, 2015, 2016, 2017 press CMD+F3. In the correct webclient (Nav/Business Central from 2018, V14, V15 etc.) Alt+Q, and enter änd pro einr and use the same pathAdministration/IT Administration/General Setup/Change Log Setup:that's in the Classic Client:

In Navision Classic Client then go to the Setup button, in RTC and Webclient go to the Ribon menu item "Tables". From here on all 3 versions can be set the same.

Which tables/changes to monitor?

Master data and setup tables

Note: All data in Navision/Business Central is stored solely in tables. No matter where you are: In the Classic Client you can use CTRL+F8, in the RTC or Webclient CTRL+Alt+F1 (if no Intel graphics card driver is interfering...) to see which table you are currently in.
Please do not log any changes in item tables! If possible also not in movement tables! Concentrate on the master data tables, and basically on the setting "Some fields", like e.g. in this screenshot:

Please don't touch these item tables:

17 non-cash items
21 Accounts receivable
25 Accounts payable
32 Article item

Und auch diese Tabellen sollten Sie nur mit Samthandschuhen Protokollieren:
36 Sales header
37 Sales line
38 Purchase head
39 Purchase line
43,44,

Also, do not save changes to buffer tables or posted documents, e.g., from tables 110,111,112,113,114,115,120,121,122,123,124,125,126....
An exemption may be the Edit logging from the Tracking code field in the posted sales delivery header table 110.

Why?

Item tables and posted receipts

can't be changed anyway or only in very few exceptions ("clearing with document type", "tracking code"). Monitoring therefore makes no sense, and only unnecessarily burdens your native or SQL server.

Buffer tables

usually have no content, and are used intensively by the system to condense data and then write it to the database to save time. So logging changes on these tables negates the associated optimization. Most of the time (always, if not done by a bad programmer) these buffer tables are also only cached in RAM and not on the server. In this case the log function doesn't work at all.

Hottables such as 36, Sales header or 37 sales lineAccounting posting sheet line, article posting sheet line

experience so many changes that a log on them quickly generates millions of records in the change log, cluttering up their database and putting additional load on their server or slowing down transactions unnecessarily. This is why they are called hottables. Most often, an urgently needed database cleanup is the result of such an attempt.

How to monitor?

As so often in Navision/ Business Central 365: Less is more

Please avoid at all costs the seemingly so convenient setting "All fields" to monitor a table completely. This will quickly clutter up the change log and thus the Navision database. The log becomes way too large to evaluate, and the changes to the master records in your database that are relevant to you are lost.
I have already found Navision/Business Central databases where only the change log took 90% of the database, with millions of entries. A database like that needs to be cleaned asap..

Log insertion

Usually only the primary key makes sense here! For customers e.g. the customer number.
Why? As soon as a customer number (delivery term code, payment term code, G/L account number...) has been assigned, the record is technically created and Navision is now in "Edit" mode.

Edit log

Here you mark the fields that are really relevant for tracking. Payment term code, payment form code, name & address, vendor code, credit limit, booking group, vendor code, price group code... These are the fields that will hurt if you make a wrong change. But there are also many fields in almost every larger table, whose change you probably don't care about. In my facilities, there is often only one accounts receivable posting group and only one dunning method. So monitoring these fields makes little sense then. You will quickly get hundreds of change log entries without content, especially for fields that are not used at all ("All fields").

Deletion log

Here you select the columns / fields that help to restore the most important properties of the record in case of accidental deletion. As a rule, these are fewer than in the case of Edit Logging.

Remember: Less is more! Navision and the database have a lot of work to do with logging. Don't make it too hard for Navision or Financials/Business Central.

Evaluate / research changes

In addition to the intentional wrong setup, you can make the next big mistake here.
It's because the protocol is optimized for writing, not for researching changes.
That's why in Navision that I manage, there is a small but important menu item in that place:

Administration/IT Administration/General Setup/Change Log Setup:

With this menu item you get the change log items directly pre-filtered for the selected table. This makes the work (filtering & searching) in this table a lot easier for Navision (or more precisely: the database server). Please do NOT go directly through the change log items, each query you make there will take (with a well filled change log item table) what feels like an eternity.

The deluxe version also provides a simplified call for each relevant master data table (customers, vendors, articles, G/L accounts):