Lesson in Code Re-Use: Vendor Item Number Error Importing POP Reciepts Using eConnect 9

UPDATE:  I found the problem, and it was the guy sitting at my keyboard!  It turns out that I had re-used some code from a prior PO receipt import, and that code was the source of the problem.  The old code was designed to read PO receipt XML source data files that did not contain the vendor item number.  The code was dutifully using the vendor ID and item number to query GP, get the current vendor item number, and then update the XML with the current vendor item number value just before sending it off to eConnect.  So that explains why the vendor item number value was changing from the time I validated it, to the time eConnect was validating it.  D'oh!

Nothing to see here folks, please move along...

I've spent the last puzzling hour trying to figure out why I am seeing strange errors with a POP Receipt import that I've developed using eConnect 9.

When importing a particular receipt, eConnect returns an error saying that the vendor item number was invalid.

Okay, no problem, I added some validation to check the vendor ID, item number, and vendor item number of the receipt data so that a validation error would be logged in case there was a discrepancy.

But after adding my validation, the receipt data validated successfully, sent the receipt on to eConnect, and eConnect once again returned the same vendor item number error.

Thinking that my validation code was somehow being skipped, I added detailed logging to try and see how the validation code was being skipped.  To my surprise, I saw that it was not being skipped.  It was running, validating the receipt, and the data appeared to be valid.

Validating receipt 234376027 Item 5948-267764
Validating vendor item for PO PO100585, Item 5948-267764, Vendor Item D81639D
--Vendor item IS valid

I then logged into GP and checked the PO, and sure enough, the PO showed the same item number and the same vendor item number.

Puzzled, I then went back to the eConnect error.  After looking at it more closely, I saw the oddity.

Error Number = 9343  Stored Procedure taPopRcptLineInsert  Error Description = Item/vendor item/vendor combination is not available to receive from the PO Line                          
POPTYPE = 1
POPRCTNM = 234376027
PONUMBER = PO100585
ITEMNMBR = 5948-267764
VNDITNUM = 296059816397
VENDORID = GPINGRAM


Notice anything fishy?

Notice how the vendor item number in the eConnect error data does not match the vendor item number that I validated?

I then looked up the vendor item number record in GP, and sure enough, it showed 296059816397, and not D81639D.

From what I can tell at this point, eConnect  my old code! is replacing the vendor item number in my receipt transaction with the current vendor item number setup in GP.  Because this current vendor item does not match the vendor item number on the PO, the import is failing. 

In GP 9, I am able to manually enter the receipt fine by using the vendor item number from the PO, so this is obviously a problem with my code!  behavior appears to be an "issue" with eConnect 9.  If I need to change my vendor item number, I don't want to invalidate outstanding POs, so this behavior seems puzzling.

I don't know if this behavior is the same with eConnect 10, and unfortunately probably won't have the time to test it and find out.

I'm now having to figure out if there is a workaround for this.  Never a dull moment!


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

http://www.precipioservices.com