Blog

Microsoft Dynamics NAV has a very consistent user interface, that helps user get used to it pretty fast. Yet it has its own ways, that aren’t so intuitive to most of typical business application users. There is one specific feature which causes a lot of confusion, especially with those users only starting to use NAV. It’s the data persistence: as soon as you enter something in a form, it is automatically saved, you don’t need to press any Save button. Nor is there any Cancel button to forget the changes entered.

This little gizmo can cause many headaches, because when working with master data it’s only so easy to start configuring an item, or a vendor, or a customer (or any other master data for that matter) and then close the form leaving it there half-configured and completely unusable. Then you forget that you never finished your work. Then you want to use such an item on a document, or enter an invoice for such a vendor or customer, and you find out that you can’t post it, because the master data isn’t configured completely, and NAV doesn’t know what to do with it. Did it ever happen to you, or your users?

Take a look at the Item Card, there are dozens of fields:

I am not going to show other tabs, but trust me, there are many more fields, and if you don’t know what all of these are good for, you can easily feel completely lost. Now, which of these fields should contain a value before you are able to use this item in all kinds of transactions? In NAV, there is no such thing as a completely configured item. As soon as you enter an item number, the item is inserted into the table, and anywhere you can see a list of items, you can see this one too. The system doesn’t know that it isn’t usable yet. In NAV, anything can be usable, and unusable at the same time, depending on what you want to do. That’s why NAV lets you configure an item without filling all of the information into the item card at once.

However, if you do so, your users might start getting errors during postings, which may be a little bit confusing. Typical question I came accross was: Why the system lets me choose such an item, if I can’t post it? Whatever your answer to this question may be, another question will surely follow: Is there anything you could do to prevent us from choosing an item which isn’t yet configured? Err, not really. Or at least not without a modification.

I’ve seen many approaches to this problem, the most common probably being providing some kind of visual clues as to which fields must be entered, such as different background color for those fields, or something similar. However, this still doesn’t prevent users from not configuring items completely. Trying to include any kind of business logic which would reject modification to item (or any other master data) in case all required fields aren’t filled in, would cause so much frustration to users, because of the way how NAV handles data storing.

Once, I solved this problem as follows. I modified the OnInsert trigger for all relevant master data tables, so that it set Blocked to True (or to All for Customer and Vendor tables). Then I modified the OnValidate trigger for Blocked field in the way that it TESTFIELDed all fields that the customer considered mandatory. What this would achieve is that any master data record entered into the system would start off by being unusable, because it would be blocked. You couldn’t use it in any of the transactions or setups, because it was blocked, and the systemwide consistent behavior is to check whether a master record is blocked when you try to use it. You couldn’t just go and unblock it, because unblocking would cause a number of checkings to make sure you really configured everything you had to configure to be able to use it properly all over the system. So, I relied on a simple system wide mechanism to enforce a more complicated set of business rules.

Although I personally don’t think solutions like this one are really necessary, and my own firm position is that users are better off getting used to the NAV’s way of checking master data completeness as late as possible, instead of as early as possible, sometimes you will end up having to do something like this. If this happens, I hope you will find this little piece of advice helpful.