Only a short post however I thought I’d blog this one as its a frequent query we receive on the Bank Management module in Dynamics GP.
Clients who have the “Bank Management” module for Dynamics GP will often create a new chequebook via “Cards > Financial > Chequebook” and notice the “Bank Management” option isn’t immediately visible to add the additional setup:
This is because you first need to grant access to the users in the bank management module and then you see the option.
You grant access via “Cards > Financial > Bank Management > Setup”
Once in the Bank Management Setup window click “Access”
Once in the Access window pickup the relevant users and grant them access to the new chequebook:
Once this has been granted the “Bank Management” option is visible on the chequebook in the “Cards > Financial > Chequebook” window.
A colleague and I worked on a very interesting support ticket today. A client reported that when logging into Dynamics GP using their own Dynamics GP User ID they received the error “No Obligations Found” when retrieving the obligations for the VAT Return however it worked fine when logged in as “sa”.
**Please note there has been a service pack to correct this exact issue however this has been applied to the clients system so it can’t be causing this issue**.
As this worked with “sa” we checked the SQL Error log and surprisingly we found the following messages recorded at the time the routine had been ran:
As you can see the error log is scattered with “Login failed for user” messages for the user in the question.
The next part of the investigation was to setup a SQL Profile Trace to see what SQL statements were running just prior to the login failed message and we found the following:
As you can see the SQL statement “select SERVERPROPERTY(‘ServerName’)” runs just prior to the login failed errors.
My colleague then recalled they are using a DNS Alias for the SQL server name in the ODBC connection rather than the actual SQL server name.
We therefore ran “select SERVERPROPERTY(‘ServerName’)” on the server and, as expected, this returns the actual SQL server name rather than the alias name that is used in the server name in the ODBC connection on the clients PC.
Intrigued that the issue could somehow be related to how GP encrypts passwords using the SQL server name we setup the following test:
Created an additional ODBC connection on the clients PC pointing to the actual SQL server name rather than DNS Alias name.
Logged into Dynamics GP as “sa” using this new ODBC and created a new GP user, copying the security of the existing user. (so the password gets encrypted using the actual SQL server name)
Finally, we logged into GP using the new ODBC and the new GP user.
After successfully logging in using the new user, and the ODBC pointing at the actual SQL server name, we walked through retrieving the obligations and the whole process worked. We also checked the SQL error log and there were no “Login Failed” error messages for the user.
I have to admit at this point I’m guessing as to what is going on however based on the results of this isolated test I can only assume that somehow during this process the users Dynamics GP credentials are being re-submitted to SQL using the actual SQL server name, and as the users password is encrypted with the SQL server DNS Alias name, its failing with “Login failed”. This works when logged in as “sa” because this is the only User ID that doesn’t have its password encrypted by GP. (its not encrypted because its the SQL System Administrator account)
Therefore although using a DNS alias can help with server changes (ironically because of how GP encrypts the password), this has got us thinking that using a DNS Alias for the SQL server could be causing other issues with GP that we don’t know about, so we may avoid this in the future if we can.
After discovering this little oddity I’d be interested if anyone else has any other experience of issues when using a DNS Alias for the SQL server.
Disclaimer :- I’d usually attempt to recreate this type of issue on my own system before documenting and sharing however I can’t in this instance as I don’t have an account with HMRC to complete the full process. However given how interesting this does seem I thought it worthwhile sharing anyway.
I recently came across the following error when trying to post an Inventory Pick in Dynamics NAV 2018
On investigation this is being caused because although the Inventory Pick had been created from the Sales Order, the Sales Order had subsequently been shipped and invoiced directly from the Sales Order screen rather than via the Inventory Pick. (this surprised me as I assumed the system would prevent the Sales Order from being shipped and invoiced from the Sales Order if an unposted Inventory Pick existed for it)
For clarity, as I understand things when a location has the “Require Pick” option ticked in the location setup (important to note “Require Shipment” isn’t ticked) the usual process for shipping and invoicing a Sales Order would be:
Create the Sales Order.
Release the Sales Order.
Create the Inventory Pick in a push or pull fashion from the Sales Order.
Post the shipment from the Inventory Pick.
Post the Invoice from the Sales Order.
It seems that somewhere between point 3 and 4 someone had opened the Sales Order and clicked “Post” and selected “Shipment and Invoice” even though the Inventory Pick was still unposted.
On investigation this removes the internal “Warehouse Request” from the warehouse request table and when you try and post the Inventory Pick you are presented with the error “The Warehouse Request does not exist”.
As far I can see the only option here is to delete the Inventory Pick as it can’t be progressed. (I also assume the goods have been shipped)
I’ve tested this same process on a version of Dynamics 365 Business Central and it seems to prevent the Sales Order being shipped and invoiced if an Inventory Pick exists for it. When you do try you get the message below:
This does make more sense to me, I’m just surprised Dynamics NAV doesn’t prevent it.
As with all issues I did learn something new and also had fun looking at the importance of the internal Warehouse Request with all this. This is something I’m hoping to look at it more depth in future.
thedynamicsexplorer.com 