eConnect 2010 / 2013 error: Procedure or function 'ta___________' expects parameter '@________, which was not supplied

By Steve Endow

It can be really strange how some Dynamics GP issues come in clusters.  One week, all will be quiet, but the next week, you'll get multiple calls, often regarding the same issue.

Last Saturday, I received an email asking for help with an eConnect error.  An existing POP Receipt integration worked fine with GP 10.0, but once it was upgraded to GP 2013, the import would get the following error when trying to submit serialized XML to eConnect:

Procedure or function 'taPopRctLotInsert' expects parameter '@I_vPOPRCTNM', which was not supplied

For an existing integration that was working fine to have this error suddenly occur after being upgraded is pretty odd.  Obviously you wouldn't submit a lot record without assigning the value for the POP receipt with which it is associated.

I offered one or two guesses as to the possible cause, but those didn't pan out.  But the next day I received an update explaining that they had found the issue.  When they reviewed the serialized XML prior to submission, they found an extra node:

< taPopRcptLotInsert xsi:nil="true" / >

(spaces added to the end caps of the node to keep it from being stripped out by Blogger)

The exact same integration worked fine with GP 10, but has this problem with GP 2013.  It would seem that something changed with the eConnect Serialization library, and one might assume that this is an "eConnect bug".

But not so fast.  I've developed several POP Receipt imports that have upgraded from GP 10 to GP 2010 and 2013, and have not run into this issue.  So I had a hard time imagining that this was a fundamental bug in the POP Receipt eConnect serialization.  In this case, the developer implemented a workaround to strip out the extra "nil" node, and that solved his problem.  But I was puzzled--something didn't seem right.

So this morning I glanced at the GP forum posts, and saw a post titled "eConnect 2010,2013 Bug".  Posts like that always catch my attention, so I reviewed it.

Interestingly, this user was experiencing a very similar issue.  An eConnect integration that worked fine on GP 10 suddenly has a similar error when upgraded to GP 2013.

Procedure or function 'taPMDistribution' expects parameter '@I_vDOCTYPE', which was not supplied

(I'm guessing that the error message was mistyped and actually read "which was not supplied", but perhaps the error message does vary between eConnect methods)

Finding it very odd that I have seen this error twice in less than a week, I tried searching for this particular version, and I found gold.

http://dyndeveloper.com/thread.aspx?Threadid=1069

On this thread, someone else had the same error.  Coincidentally, the last post references one of my eConnect blog articles, but at the bottom, it appears that he traced the issue to how he was dimensioning his taPMDistribution_Items array.

In VB, you can use the ReDim Preserve command to dynamically increase the size of your eConnect arrays as you build them.  Well, if you have an incorrect counter, or forget that you are working with a zero based array, you can easily end up dimensioning your array to be one larger than what it should be.  When you do that, an extra node gets serialized and gets output with the "nil" value.

So here is my theory:  eConnect 10 used to dispose of these extra "nil" nodes during serialization, but eConnect 2010 (and 2013) do not ignore them, and dutifully output them.  So when someone upgrades their integration from GP 10 to 2013, an integration that used to work perfectly may get an error, due to what they will believe is an "eConnect bug".

I also theorize that this issue will only affect integrations that were written in Visual Basic, as VB has the ReDim Preserve command, which is not available in C#.  I speculate that these VB developers are really running into a bug in their integration code that improperly dimensions the array to be one value larger than it should be.

In C#, this is probably very unlikely, but I suppose if arrays were used, someone could still incorrectly dimension the array.  I personally use List<> objects for my eConnect array, and there is no dimensioning required, so I should never experience this particular issue.

I've responded to the forum post, so I'm interested to see if they confirm that they are using VB and if they did improperly dimension their array.

If anyone else thinks this theory makes sense, or has a different interpretation or theory, I'm interested to hear about it!

Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified IT Professional in Los Angeles.  He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

You can also find him on Google+ and Twitter

http://www.precipioservices.com