Oct 02
Extensions are the Answer. What’s the question?

Several times last week at Directions North America 2016 I heard people saying:

"Extensions are the answer. What's the question?"

For many years, we have talked about Dynamics NAV's biggest strength being the ability to be highly customizable, however the ability to highly customize it is also the greatest weaknesses. Highly customizable solutions come at a price when it is time to upgrade.

Current versions of Dynamics NAV allow you to customize just about everything as you have direct access to modify any part of the code you would like. It is so very powerful, however when people do that over years it can be very costly to get the code upgraded no matter how well the code was written or how good tools we have at our disposal.

There are several reasons for this:

  1. Most code changes are not isolated, so when they are not needed anymore no one removes it as it is just too costly and hard to figure out what to remove and what to keep. There is also a risk you might break something in the process.
  2. No matter how good and clean some one's code is there is always room for improvement. In other words, code is often written by multiple developers with different skill levels and very rarely written with upgrade in mind.

Now let me first make perfectly clear that NO ONE is removing the option to customize in any way or shape in Dynamics NAV 2017.

That said the options for developing extensions have been highly improved with the inclusion of all objects types, so why is this good?

When we create an extension we have the changes totally isolated. The code or extension can be uninstalled quickly and pain free if no longer needed. Even better is that an extension is built with upgrade in mind so when it comes time to upgrade your solution you can do so fast and pain free. It is even possible to upgrade on a monthly basis as Microsoft issue Cumulative updates. There are also great options with extensions for making reusable solutions across customers and installations without any additional work.

This gives everyone more value for their money as the software constantly improves and getting these improvements in the hands of end users could often resolve issues before the users are even aware they have them.

Yes extensions have limits and yes extensions require a little more work to create, but trust me it is worth it.

Extensions was the answer. What was the question?

PS. Sorry if I stole this Quote from someone without naming the source.

Aug 25
Initialize Setup Tables

Something that has been bugging me for a while is how we initialize setup tables in standard Dynamics NAV.

Today I came across it again as I needed to add a setup table in an Extension I was developing and I thought it would be time to write a little blog post on it too see if we cannot get this improved.

Let's take a look on how it is done and to illustrate the issues I will look at General Ledger Setup

On Page 118 we see this code on the OnOpenPage trigger

As setup tables are singletons this code just makes sure a record is created. So the first question here is why this code is being placed on the Page and not a function on the table. From an object oriented point of view and with "Clean Code" in mind the initialization of the record is a method on the class where the class in this case is the table. So let's move this function to the table and call it from the Page.

That said it is still code cloning as the same code 5 lines of code currently place on all pages showing a Singleton Setup table is just moved unchanged to the table.

The code can be written generically and called from every table. The function could look like this

Where the variable DataTypeManagement of course refers to Codeunit "Data Type Management".

It is not really important where this function is placed, however it should of course be done centrally.

All that said this code is actually repeated again for all Singleton Setup tables in the function "InitSetupTables" in "Codeunit 2 Company-Initialize"

But now that we have made this a function of the setup table all this code cloning can be avoided by simply calling the function and reusing the same generically written code.

I only found one table with a small issue and that is the "Company Information" table where "Created DateTime" field is populated at the time of creation of the record however this code could easily be places on the OnInsert trigger of the table and do the record creation with INSERT(TRUE)

All in all, this is simpler code, easier to modify, implement and maintain and good for everyone.

Hope this will find its way to the right place and one day be found in the product.

Jul 24
Is My Record Temporary

Very often when developing we have logic we would like to execute on records, but only when the table is actually a real table and not when used as a temporary record. This could be things like inserting, modifying or deleting attached records in another table which would make no sense in most cases if the table you are currently in is temporary.

Now when we use a RecordRef we have a command that will return true or false based on the RecordRef in question is temporary or not. The command is called


However this command sadly doesn't exist for Records.

So how can we get around that issue?

I have created a RecordRefLibrary codeunit that contains the following 2 functions among others

IsVariantTemporary(PassedVariant : Variant) : Boolean




Variant2RecRef(PassedVariant : Variant;VAR RecRef : RecordRef)


PassedVariant.ISRECORD :


PassedVariant.ISRECORDREF :

RecRef := PassedVariant;





Now in each table where I need it I add the following function

IsTemporary() : Boolean



Now I can write



anywhere I use the Record and it will return if the record I am currently in is temporary or not.

I could of course also just call directly to the codeunit if I would like not to make changes to the Table, however it would be good practice in my view to expose the functionality on each table where needed, so everybody knows where to find it.

Hopefully this was helpful to some of you if you don't have a solution for this already.


Jun 30
A couple of “secret” switches in Dynamics NAV

Unless you are very new to Microsoft Dynamics NAV I am sure you know of the General Ledger Setup.

This is where we setup most General Ledger related settings such as Check G/L Account usage, the local Currency Unit (LCY) ,if VAT is in use or if we are using Unrealized Tax.


Many might not be aware that this also has a few hidden settings.

If you run table 98 General Ledger Setup from the Object designer you will see a few more fields then what the users sees in the standard page in your client.

A few that I have found very use full from time to time are:


What the helps say

Mark Cr. Memos as Corrections

Specifies whether to automatically mark a new credit memo as a corrective entry.


You can use the field if you need to post a corrective entry to a customer account.


If you place a check mark in this field when posting a corrective entry, the program will post a negative debit instead of a credit or a negative credit instead of a debit. The Debit Amount field (or Credit Amount field) on the relevant account will then include both the original entry and the corrective entry, which will have no effect on the debit (or credit) balance.

Amount Decima Places

Determines the number of decimal places the program will display (for example, on invoices and in reports) for amounts in $. The default setting, 2:2, specifies that amounts in $ will be shown with two decimal places.

Unit-Amount Decimal Places

Determines the number of decimal places the program will display (for example, on invoices and in reports) for sales and purchase prices for items, and for sales prices for resources in $. The default setting, 2:5, specifies that sales and purchase prices in $ will be shown with a minimum of two decimal places and a maximum of five decimal places.

Amount Rounding Precision

Specifies the size of the interval to be used when rounding amounts in $.

Amounts will be rounded to the nearest digit.

Unit-Amount Rounding Precision

Specifies the size of the interval to be used when rounding unit amounts (that is, item or resource prices per unit) in $.


Use this field to have the program round item prices on invoice lines when you sell to a customer or buy from a vendor in $. The program rounds the amount in the Unit Price field for customers and the Direct Unit Cost field for vendors, on the invoice line. Amounts will be rounded to the nearest digit.


Especially the "Unit-Amount Rounding Precision" have come in great use many times where customers have special rounding requirements on their unit amounts (things like Item Costs, Prices with more).

One setting to rule them all.


Jun 05
Let’s Clean up NAV #13 – Chain Name

Adding to Luc van Vugt little miniseries on his blog about things we can do to clean up NAV here is another one.

Table 18 Customer has a little known field called "Chain Name". It is field No. 18 and has been in the system "forever". Well almost…

If I remember right this field has roots as far back as I can remember and I actually use it quite often as customers often request some kind of Chain association to be indicated on the customer card. However the field as it is today has a few issues. First it is not located on any page so kind of hard to use for the end user and secondly it doesn't have a table, but is free text (or I should say Code as it is a code 10 field).

Now we normally don't call code fields something ending on "Name", but that is maybe beside the point in this case.

My suggestion would be one of two:

Either we need to get rid of the field and remove it from the table. Hey that is the easy thing to do.

Alternative we should rename the field to "Chain Code". Create a Chain Table with associated List Page and setup a table relation. We of course should also add the field to the customer card.

My 10 cent on this one.




Jun 05
Let's clean up NAV #12 - Next Counting Period

My good friend Luc van Vugt started a little miniseries on his blog with things we can do to clean up NAV. What a great idea, so here is something I have noticed.

In NAV 2015 the Next Counting Period was replaced by 2 date fields after I reported it. The field was used to store the date filter for the next counting period, but if you used counting cycles and had users with different date setting in their regional settings you quickly got quite the mess to figure out. You should of course never store Date filters in text fields unless they are used with in the same transaction ensuring that the user have not changed regional settings in the meantime.

After this was done the Field "Next Counting Period" Text(250) which exist in Table 7380 Field 8, Table 5700 Field 7382 & Table 27 Field 7382 was never removed in 2015. It is not used in the code or in the UI to my knowledge, so maybe it is time to clear it up and get rid of it permanently.

Should there be a need to display the date filter we can always display it based on the 2 new date fields by calculating it on the fly which would ensure it is consistent with the uses current regional settings.

It is a low impact issue as the field has no use today and it is easy to fix not to mention it reduces record length of a tables considerable.

Apr 07
Why Microsoft should add a “Surrogate Key” to Microsoft Dynamics NAV

If you have meet me at a conference last year I am sure we have discussed my favorite topic: "Surrogate Keys"

Why is this so important to me?

The key message we have heard the last few years at every conference has been repeatable solutions, but if you want to create repeatable solutions it all starts with repeatable code.

So what has that to do with Surrogate Keys you might ask?

Well Surrogate Keys are one way (and until today one of the best I have found) to create functionality that is completely generic and reusable. Back a few years before I had even formalized my thoughts about this I called it "LEGO Programming" (okay I am Danish and love LEGO. Deal with it J) because I wanted to create code similar to these wonderful building blocks that can be placed anywhere in a construction and they just work.

LEGO is just one of these wonderful toys that you can be very creative with.

Why should my code be any different?

Well back to why Microsoft should look at this as a standard part of the platform:

  1. They want us to create generic solutions, so give us generic tools to do it with. Yes we can use things like RecordID, but a surrogate key is much more flexible and doesn't depend on any record data. It also doesn't suffer from renaming issues…
  2. My implementation has some faults. If you would use the INIT function it gets cleared out which is should not unless you actually insert a new record. This is standardly done twice in Table 37 and 39 as an example. We can work around it quite easy, but we should not have to do so. A proper implemented Surrogate Key in the platform would resolve that issue.
  3. Too many places in the application things have been done locally while using global wording causing things that I find highly regrettable. Take the table 5062 "Attachment". Just based on the word you would assume it would work anywhere in the application and not just in a small local area of the functionality. Why should attachments be limited to one record when it could be so much more?
  4. A generic platform implementation of this would save the community a lot of work of adding Surrogate keys to all tables where it is needed.
  5. It is so simple to do compared to the benefit it would bring the community.

Just to be clear I am not pointing at anybody with my examples. They were developed in another age and great at the time. All I am trying to say is that we need to change gears.

It is time to start thinking generically and hold ourselves to a higher standard.

Apr 07
Copy/Move Data placed in Surrogate Key Based tables

An example of how to do things very generically when using the Surrogate Keys Design Pattern is when you need to copy or move data attached to one record to another record.

Looking at classic design you often see different functions created to copy or move data in Subsidiary Tables between different master records. Take an area like Comments (My favorite example) where we have 29 different implementations of it (at least if I can count correctly). Let's say I would like to copy or move the comments between any of these 29 implementations to any other of them. Now with 29 tables in play I would need to create a function from the first table and to all the other 28 tables. Than do it again for Table 2, 3, … & 29.

Yes that is a lot of functions and not exactly a small task.

So what is the difference if I had used a Surrogate Key and created only one generic implementation of Comments?

Well my copy function could look like this:

Because I am always using the same record to store my Subsidiary Table Data it is very easy to copy from one Master Record to another.

To make is even more generic and because I am lazy by nature I also added this function.

So now I can copy between 2 Records, 2 RecordRefs or a combination of a Record and a RecordRef without knowing anything about them.

This last function relies on a few other functions in the same codeunit.

These 2 functions in turn relies on my RecordRefLibrary Codeunit and the function

And my SurrogateKey Management Codeunit with this function.

Yes I use a fixed Field No for all my Surrogate Keys and no it is not 59999, but I had to create an example for this blog.

Before you ask why I use a fixed number I better address it.

There are 3 reasons for it:

  1. It is the easiest
  2. Once (Not when or if) Microsoft gets around to make their own version of a surrogate key in NAV it would make the most sense they did something similar
  3. It makes (at least that is my hope) for an easy and generic upgrade script once this finds its way to the standard platform

Let's get back to the real issue here. Basically in a few lines of code we have resolved all our coding needs for copying comments between any master records and it doesn't matter how many Master Tables comments are added to in the future. This will always work.

Creating repeatable implementations starts with creating repeatable code.

Apr 07
Find your Table ID

Using many hours programming with my favorite Design Pattern "Surrogate Keys" I often need to know simple things that can be a little hard to find at times.

One of these is to know the Table ID of any record I might be handling at any given time.

All the tables that use the surrogate key pattern use a primary key based on "Table ID", a "Surrogate Key Reference" & maybe a "Line No." or "Code" depending on what the table is hosting of data. In other words I often need to know the Table ID to filter correctly based on the record I am calling from.

I handle this with the following Code:

The ReturnTableID function takes a Variant as Parameter and calls Variant2RecRef to get it transformed to a Record Ref no matter if a Record or a Record Ref was passed to it. After that the function Returns the RecRef.Number which is the Table ID of whatever was passed to it.

This way I can call the first function with any Record or RecordRef and get the Table ID returned.

This creates a completely generic function that always returns your Table ID.

This is a fixed part of my RecordRef Library Codeunit and now hopefully of yours too.

Jan 20
Social Listening

While on MSDN I came across some new Help Content for Dynamics NAV 2015 talking about Social Listening.

Now while Social Listening might not be on everybody's "must have list" it is still a great way to show the power of Dynamics NAV and the application stack from Microsoft.

I look very much forward to see what these new topics mean for the product.

Have a look here:


I was made aware by Vjeko that there is an "How Do I" YouTube video on the topic too…

1 - 10Next