Open Forum

1.  NAV 2016 and AD Logins

Posted 7 days ago

I did not find this topic in the forums, so I thought I would see if you all can enlighten me:

When we import in users and associate them with their Windows Active Directory accounts, it changes the username to the Domain\Username format.

Now the logins work just fine, but it creates a serious hassle factor when using any of the "Assigned User ID" fields on PO, SO, RPO's, etc.  We have to use the *.* wildcards, but that does not always bring up the correct choice(s) and adds extra steps to the process.

Is there a workaround for this, is it a mod, or a fact of life we will have to contend with?

Thanks in advance!

Andy Brandt
Lundberg Family Farms
Richvale CA

2.  RE: NAV 2016 and AD Logins

Posted 7 days ago

​Good morning Andy,

I am afraid that it is "the new way" it works.  With introduction to Azure, etc. a lot of changes were made, which hve caused surprise for many NAV Users - and not always in a positive way.

It is correct that it links to "User Setup", but a User ID is not always an AD User.  You still have Database Users, which sits in the same table in background - so to allow for both AD users and DB Users, there is now an internal NAV GUID there is used as the internal reference for many things.

By standard there should be "Intellisense" on the field, so it should give you an automatic list of records there fullfile the requirements.

It sounds like the users are using F4 for look-up instead of just typing in the field.
Am I correct?

Could you try to send a couple of examples/more info. on how You use it.

Soren Smith
Nielsen & Partners Ltd
Cape Town

3.  RE: NAV 2016 and AD Logins

Posted 6 days ago
Hi Andy,

This was a nasty surprise for us too when we upgraded to NAV2016. Our domain is 16 characters long so you can imagine how that looks throughout NAV!
The Lookup Issue
I created a custom ID field in the User Setup table that holds the shorter/simpler ID. It's not a great solution but it does work. To get the Active Lookup as you type to work, you have to set this relation up at the Page level--not the table level. **This is NOT great coding practice**.... So you might want to consider making your own custom user table instead. Use your simple ID as the PK and then make a secondary field that links to the User table.

The Ledger and Posted Document & Reporting Issue
In your reporting you likely filter by user in some reports...Adding the Domain to the front of your UserIDs just doubled your list of users. Ouch! Also, if you're like us with 16 characters before the UserID, then you can't even see the ID on a list page without stretching the column width inside of NAV. Very annoying! I "fixed" this by adding a LOT of DELSTR(UserID,1,16). Again, not pretty--but I'm not sure we have any better options here.

Greg Enns
ERP Coordinator
Technical Prospects
Kaukauna WI

4.  RE: NAV 2016 and AD Logins

Posted 4 days ago
Hi all,

This was a pain for us too, what I did, was to go into the dev and table 2000000120 - User. I then deleted the domain prefix from the User Name column, and this solved our problem.  We have to do this for every new user we add, but it only takes seconds.

Many thanks.

Adam Jones
Celebration Paper & Plastics Ltd
Burton upon Trent

5.  RE: NAV 2016 and AD Logins

Posted 2 days ago

Excellent points everyone!  At least this points me in a couple of potential directions.

Thanks again!


Andy Brandt
Lundberg Family Farms
Richvale CA

6.  RE: NAV 2016 and AD Logins

Posted 20 hours ago

Same here, this was a big pain and not expected.


Devang Mehta
NAV Practice Manager
InterDyn BMI