Bug with Address Name in SOP Entry of Dynamics GP 2015R2

We found on this issue, setting the ship to address from the main SOP entry window in our production Dynamics GP does not pull the correct field from the Ship To Address Name of the address book record into the order Ship To Field. Instead the company name of the account is used. It does work correctly when the selection is made on the Sales Debtor Detail window.

We have mods running on this server and I don’t currently have a clean VM to test on, so wouldn’t mind some verification from anyone else with this issue.

To reproduce the issue

Set an Address name in a debtor customer address, in our example I have set the company address name to be “Fake Address Name”, as shown below:

Fake Address Name set as Address Name for Ship To

Now create a sales order for that customer, then select the above address, do so by using the picker on the main window of SOP entry, for Ship To Address, as highlighted below.

Use Ship To Address Picker

Now check the ship to address that has been set. You will see that the name from the debtor has been used and not the Ship To Address Name from the address record.

Address Name set to account Name

Repeat the previous procedure, just this time use the address picker in the Sales Debtor Detail Entry window to select the ship to address. Now go check the ship to address, see how it has taken the correct ship to address name.

Address Name correctly set to ship to name

Although the users have be instructed to use the latter method to select an address, they slip back into using the former method, that then causes customer service issues with deliveries not being made as the shipping to company name is incorrect on the order.

 

UPDATE: 2016-10-19

I had a few moments today so I tested this today on my GP2016, a clean VM and found the issue was not there, so now even more curious as to if this is a bug with our 2015R2 instance or something that has been fixed in 2016. Rob Klaproth kindly pointed out my lack of documentation on the issues, version of GP especially, these are now included in the post! I don’t think I have reported this to MS as a bug, but with the GP2016 revelation, I don’t feel the need now.

Comments (4) -

  • Thanks for the post.  It would be very helpful to avoid mis spreading of information if you could point out what versions of GP are affected and if this is known to Microsoft and a planned fix is coming.  I do see from your screen shots that you are using 2015 so I am wondering if this was fixed in 2016?
    • Rob
      Indeed it is fixed in 2016, I don't know if this is a general error in 2015R2 for everyone or not, I guess the post was me hoping to find out from others.
      I've updated the title with the version and added the update to the end regarding 2016.
      Thanks for keeping me on the straight and narrow!

      Tim.
      • I am also experiencing this error, so this was not a mis-spreading of information.  I found Tim's comments very helpful.  so thank you Tim.  I am on version 2015R2 currently.  We have just dealt with it glitch, but look forward to finally having it fixed with upgrade to 2016.  
        • I ended up just password protecting the field and lookup to deny anyone using it, with field level security until we upgrade.

Add comment

Loading