Debugger Break Rules – Break on Records Changes (Insert, Modify or Delete) in Navision

I was debugging something today and I noticed the ‘Break on Records Changes’ break rule, sweet… 🙂 I didn’t know this. In the older versions of Dynamics NAV I always used the code coverage to find where in the code records are modified, but this is much better.


Here is how to do it; start the debugger, click ‘Break Rules’, and activate the ‘Break on Records Changes’. The debugger will now stop whenever a record is inserted, modified or deleted.

Mandatory Dimensions by Account Type in Navision

Dimensions are great in Dynamics NAV and one of the things that makes it great is that you can control the required dimensions for each type of posting into the general ledger by setting dimensions as mandatory on the general ledger accounts. Most people that work with Dynamics NAV knows this. But surprisingly many people does not know that you can also specify what dimensions that are mandatory for each account type by using the ‘Account Type Default Dimension’ setup.


For each of your dimensions you can go to the ‘Account Type Default Dim’ and setup if the dimension is mandatory for all transactions with a certain type. As an example, the below setup defines that the ‘CUSTOMERGROUP’ dimension is mandatory for all Customers (table 18). This way you will not be able to post anything without this dimension against any of the customers independent on what is setup to be required on the general ledger accounts.

Run Dynamics Navision as Different User (NAV Login with multiple users on a single Machine)

A question that I receive frequently is; ‘how do I run Dynamics NAV as a different user?’. A basic question it seems, but not everybody is aware of how it can be done.

It could for example be that you are testing permissions and you want to run one client with SUPER user access to do the permission setup and another client with limited access to test the setup at the same time. Another common scenario is that you want to debug something on a users computer and for this you need your own log-in to have full permission and access to the debugger.

Luckily it is quite easy to run Dynamics NAV as a different user without logging out of windows, here is how to do it:

Right click on the Dynamics NAV icon and select Run as Different User.

Note :- If the option does not show up when you right click, try to hold down the SHIFT key while right clicking.

Then you simply sign in with the different user through the dialog that appears and that’s it!

Now you can run two or more NAV clients on the same computer logged in as two or more different users.

Nice, easy and very useful! 🙂

How to Calculate the Current Fiscal Year in Navision C/AL

In Navision, there’s no function that will give you the fiscal year according to what you’ve setup on the Accounting Period table. Here’s a code that will get the current fiscal year based on the accounting period:

AccountingPeriod is a record variable  to table 50
Date1 and Date2 are date variables

AccountingPeriod.RESET;
AccountingPeriod.SETRANGE(“New Fiscal Year”,TRUE);
AccountingPeriod.”Starting Date” := WORKDATE;
AccountingPeriod.FIND(‘=<‘);
Date1 := AccountingPeriod.”Starting Date”;
IF AccountingPeriod.NEXT = 0 THEN
  Date2 := 12319999D
ELSE
  Date2 := AccountingPeriod.”Starting Date” – 1;

Sort on Multiple Columns in Dynamics NAV

This is something I first discovered some months ago, and back then I didn’t think that much about it. Recently someone asked me if it was possible, and I thought it would be worth a quick small blog post.

Yes, you can sort on multiple columns in Microsoft Dynamics NAV (with some limitations though). You do it by holding the shift key down while clicking the next column(s). This way Dynamics NAV sorts the data based on multiple columns.

On the page you can see it by the sorting indicator (or whatever the small triangle is called) is being displayed on multiple columns.

The only odd thing is that it does not seem to work to decide if the sorting is going to be descending or ascending on the individual columns, they are either all descending or all ascending. Well, you can’t get everything. 🙂

Restarting Job Queue automatically when it Hits an Error on Dynamics Navision

Job Queue 

In Dynamics Navision, you can setup job queue to automate processing of tasks. Popular tasks that are automated are things such as Adjust Cost – Validating Entries, Batch Job processing, Reporting, etc.

Setting up job queue in Navision couldn’t be much easier. BUT..

The Problem

When the job queue runs into an error, it will never get picked up again. This means that while the Job Queue is an automated process, the IT manager will need to monitor this every day to make sure every process is running.

I know what you’re thinking, “This does not make sense!”. I fully agree.

There are some processes where the error is fatal. This is the reason why you would not want to have it run again. However, there are some situations where the error occurs when the table is locked by another process, in this case, you absolutely need to have it restart again.

This is especially true when you process EDI orders. You have to send back acknowledgment and/or confirmation within a certain timeframe or else you’ll get charge backs. Having the job queue error out because of table locks does not make too much sense.

The Solution 

The problem lies in the Job Queue Dispatcher codeunit (448). If you go down and find the local function GetNextRequest, you’ll see that for some odd reason, the process is only looking at any statuses that are Ready.

So we will need to modify the code to scan for the error entries as well.

Depending on what you use the Job Queue for, I would include job queues that are In Process. The reason is if it’s running and someone stops the job queue, it’ll stay stuck in the In Process status.

By setting this, it’s important that you set the Max No. of Attempts. You don’t want the job queue to keep running if there really is a critical error.

Items with Multiple Item Unit of Measures in Navision

Items in Microsoft Dynamics NAV can have multiple units of measures, you can for example sell in one unit of measure and purchase in another unit of measure. This is great, but there are some things to be aware of when setting an item up with different unit of measures.
An item must have a base unit of measure. The base unit of measure is how the inventory quantities are displayed and how the inventory is valued. It is also how it is produced (you can have a Production BOM in a different unit of measure, but the Routing and the Production Order will always be in the base unit of measure).

It is considered best practice to have the base unit of measure to be the smallest one, this to avoid having fractions of units leftover due to rounding. Sometimes this is not possible and then it is good to know what is behind the ‘best practice’ to avoid getting into troubles.

Here is an example of how to recreate an issue with different unit of measures:

Let’s say we have an item that we purchase in feet and sell in inch and we setup the base unit of measure to be feet. The items unit of measures will then be setup like this.

 The quantity per base unit for an inch is set to 0.08333 (the base unit must always be 1), this field has a maximum of five decimals so it gets rounded like this (which is part of the problem). One feet equals 12 inch (for all the metric people 🙂).

We now purchase 10 feet which will create the following transaction.

 After this we sell 120 inch (which is the same as 10 feet), this creates the following transaction.

As you can see the 120 inch translates to 9.9996 feet due to the rounding in the items unit of measures. This creates a scenario where we have 0.0004 feet left in inventory which we shouldn’t have.

Setting the items base unit of measure to inch would have prevented this situation (and you can still purchase it in feet). This is why it is always recommended to set the smallest unit of measure as the base unit of measure.

Although, this only happens when there is a rounding involved, knowing this you can say that it is quite safe to setup items with a pair as the base unit of measure and sometimes sell it in pieces or setup an item with meters as the base and sometimes sell it in cm, etc.

The situations that I have seen where it was more or less impossible to set the base unit of measure to the smallest unit was for produced items. In those cases all routings, work instructions, costs, etc. was related to a specific unit of measure and it was not feasible to rearrange the entire production setup just to have the smallest unit of measure be the base.

If a situation like the above already exists then having procedures to adjust the fractions out each month might be appropriate (something like a stock count).