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.

Dynamics GP Drill Down Protocol Handler error

When using drill-downs in Dynamics GP the following error message may occur,

A error has occurred trying to process your url.

To fix this error and solve the problem read on…

The error is displayed in the following basic error dialog. There is no information as to what the root cause issue is.
A error has occurred trying to process your url

If you read my previous post on the Dynamics GP drill down protocol handler then you will know its application executable is found in the following location,
"C:\Program Files (x86)\Common Files\Microsoft Shared\Dexterity\Microsoft.Dynamics.GP.ProtocolHandler.exe"

The configuration file associated with this is "C:\Program Files (x86)\Common Files\Microsoft Shared\Dexterity\Microsoft.Dynamics.GP.ProtocolHandler.exe.config"

There are some undocumented configuration settings to help out.

  • LogFile (boolean)
  • UseLogFile (string)
  • DebugMode (boolean)
  • UseWindowsEventLog (boolean)
  • UseErrorWindow (boolean)

The result of putting these settings into the configuration file is that extra debug information will be presented that will uncover the source of the issue.

<!-- String value, please use good file system notation (i.e. "c:\Dynamics\GP\DynamicsGPDrillBack.xml") -->
<add key="BindingName" value="NetNamedPipeBinding_IDrillBackToGP" />
<add key="DebugMode" value="true" />
<add key="UseWindowsEventLog" value="true" />
<add key="UseLogFile" value="true" />
<!-- Boolean values only (true/false) -->


After making the above changes to the protocol handler configuration file, execute the drill down again. The following, now more detailed set of error dialogs will be shown, the subsequent boxes shown after clicking the “inner exception” button to drill down on each one.

The final box shows in this particular example the machine cannot reach the domain controller to get the required authentication.

inner exception1

Next level down…

inner exception2

Next level again…

System cannot contact a domain controller


The changes to the configuration also switched on logging to windows application log. The resulting error is logged into the application log.

Protocol Handler Application Error Log

Some other errors we have seen:


A connection Microsoft Dynamics GP could not be established Be sure that you are logged onto the appropriate company and try again. There was no endpoint listening at
net.pipe://dgpb/{}  that could accept the message.

A error has occured trying to process your url. Insufficient memory to continue the execution of the program.
(Grammar and spelling errors are genuinely in the error message)
Here is a variation of that with COM Exception rather than OutOfMemoryException.
“A error has occured trying to process your url. Unspecified Error.”
A error has occured trying to process your url. ‘System.__ComObject’ does not contain a definition for ‘getElementById’
I hope my research on the protocol handler helps some people diagnose issues, do comment if it has helped, it motivates me to write more.

GP Report Writer still gives me nightmares

Grim Reaper in front of Report Writer

People who have had to set invoice, order, purchase order and every other customer facing document layout to meet the company style guidelines using Dynamics GP report writer will curse when its name is used. It has limitations on image sizes, multiline text formatting, to difficulties in getting data from external data set or tables. Compared to SSRS for example, it is a general pain when trying to accurately lay out good looking designed documents with prescribed fonts and graphics and sizes or do sophisticated document generation.

SQL Server Reporting Services

I thought long ago by now native SSRS support was going to take all that away. I fully expected SSRS to replace Report Writer with full integration into GP. I honestly expected to see embedding of the SSRS designer into the GP application, as the native report writer is today. That never happened, instead another idea was announced, using word as a reporting tool.


Whilst GP does well at supporting choices when it comes to reporting, non are refined or seamlessly integrated for design and runtime (other than the native one). I applaud the recent moves to allow SSRS reports to be called from some of the standard windows with standard parameters passed, but really all I want is the report writer experience with a crystal/SSRS quality of design time experience, including the use of ad-hoc data sets, c# scripting against fields, right click property windows full of rich controls, report section layout groups,  all the kinds of things you get used to in other tools.

It is not a reporting tool

Today I realised I’ve been thinking about Word incorrectly thanks to something Mariano Gomez said. It was never a reporting engine, the implementation is actually just a document generation engine. Think about it, the report design still originates in the native report writer. In fact the dataset is generated in XML by the GP report engine. It is not supposed to be a Crystal or SSRS replacement, it is a different beast, an experiment. Perhaps thinking of it in this way will make me feel better about what could have been?

It has issues

The Dynamics GP Word templates functionality is layered awkwardly over the native GP report writer, with security, configurations and settings scattered in various places. This makes setting up and administration of Word Templates daunting. I do concede that I really like some aspects of the design, like keeping report document templates in the database. However it feels unfinished. Examples are having to drop files onto the TemplateGenerator.exe to create new reports, having to extract XML from existing reports and feed them into word, having to keep the native reports and Word reports in Sync, all these feel like areas where the tooling was never finished. There is also lack of one GUI view to see a holistic view of the setup of Word Templates.  Surely all that should be hidden behind a smooth easy to navigate GUI?

Am I bitter?

Why am I bothered? - I am bitter, I admit that, I dislike the native Report Writer with passion and remember Errol announcing what sounds like its retirement some time back, a retirement that has never arrived. Indeed that announcement raised a cheer from the listening audience such was the emotion around report writer. The delivery of Word Templates whilst on an operational user side of things is great and is really interesting from a developer perspective to see what they achieved with the solution, but it’s just too clunky, disjoined and slow, finicky to work with for the administrators and developers. I never like it when I feel like I’m fighting with a tool rather than the tool helping me -that is the feeling I’ve had for the last couple of days working with it again.

Dynamics GP Word Templates does not give option for “Template” in Report Destination Window

It all started when I went to do some work on Word Templates in Dynamics GP after a long absence from them (thankfully). This involved setting up a new template, I lost lots of time and then realised my whole Word template experience was broken.

Other users were using word templates making me feel inadequate as I struggled trying to print a PO.

The standard report destination window looks like the window on the left, if word templates are installed then the word “Template” is displayed for type, or is available in the combo box.

Report Destination Window normalReport Destination Window Word Template

I just could not get the Template option working. I left work and came back to it another day, again with little luck on day two.

I switched from test into production and back again, tried removing/resetting configs, scouring the permissions and accesses to reports, all to no avail.

After a few hours I went to login on another machine, it worked, so not my permissions.

I tried reinstalling GP, still nothing, uninstalled GP and reinstalled, still nothing, reinstalled the client image the standard users use and still nothing.

Then I stumbled on this post among many I was referring to during my painful trek:

Creating a Word Template for Dynamics GP

This reminded me of something I already had stored in the back of my memory, that templates has some dependencies. In fact the reason I had reinstalled GP twice was to try to ensure that all dependencies were installed, I did run from the bootstrap setup.exe by the way. Anyway, the post said,

You must have two applications installed before beginning this process:  Microsoft Dynamics GP Add-On for Word and Open XML SDK 2.0 for Microsoft Office.

I went to check in my installed programs, it was listed. I thought by this point that I had nothing to loose and everything to gain so uninstalled and reinstalled the Open XML SDK 2.0 for Microsoft Office.

Guess what, all of a sudden after too many hours stomping around the building in a bad mood Word Templates sprang to life again! Yay! Now what was it I was supposed to do a few days back…?