The above error occurred on our ecommerce to Dynamics GP integration, that makes use of eConnect to move the SOP website orders into GP. This is an integration that has been working for many years, yet this is the first time this error has occurred.
Print_Phone_NumberGB was one of the new table fields that was introduced in GP2013 to support the selection of which telephone number is used on paperwork relating to sales orders. It accompanied the long awaited “ship to” company name field for address book records.
The field name is curious, what does GB refer to, surely not Great Britain as this is international in nature. Grid Box perhaps?
The help describes the use of this field below.
Print Phone/Fax Number
Select phone or fax number to print as part of the address information on sales documents and drop ship purchasing documents. The option you select here will appear as a default in the Sales Ship-To Address Entry and Purchasing Ship-To Address Entry windows. If you are not required to print a phone or fax number, select Do Not Print. This option can be changed as needed when you’re entering or modifying sales documents.
The econnect schema describes it as not required too…
Confusing as nothing above indicates that this field should cause an issue, even if it is null! When a win merge compare between the xml of this failing order and a similar one that worked was made, it found no differences other than the account details such as account number and address etc.
So time to try searching the web and the clue that led to the answer from eone solutions
Primary Ship To Address specified on the import does not exist in the Customer’s Address list.
This brought focus to the customer address codes on the order. Indeed one of the address codes was not in the customer address table in GP (RM00102). Manually creating an address using the missing code, by entering it into the customer address maintenance window solved the problem. The order was created.
The address records are replicated up to the website, my guess is a timing issue where an address has been removed in the back office, at the same time the customer was checking the order out.
Thus this was one of those examples where the error message points to the wrong thing. Now the application has been updated with a more useful “rewrite” for this error, pointing the admin at what may be the real issue, “Check all address IDs have an address in GP to match those IDs” –obviously the original error is appended too -just in case.
Since writing this blog post I’ve seen posts by others using the Dynamics GP Web service API who have the same error. As this webserices API is actually backed by econnect, error messages are actually those bubbled up from econnect.