I inhereted a botched and poorly written integration using eConnect 10 for RM invoices / credit memos and PM invoices / credit memos.  I've got it working now, but so far there is one remaining error that is a little puzzling.

In the most recent incident, while trying to import an RM invoice, eConnect returns an error 190 indicating that the RM invoice document number already exists.  Two weird things:

1) The document number does not already exist in GP

2) The document info that eConnect is returning in the error is not the document that is being imported

I have had situations long ago where there was an error in the document (perhaps the distributions were bad), but eConnect returned a different error that was not technically correct.  But at that time, eConnect was at least referring to the correct document and returning proper document info.  But this situation with the wrong document info seems a little too odd to blame on eConnect.

 
So I can only think of two theories:

1) eConnect has gone haywire for some reason and is returning invalid error info

2) More likely: There is a bug in the integration such that the integration is sending the wrong invoice info to eConnect--while it logs one doc number, it is actually sending a completely different doc number.
 

Given how the code was written, I would not be surprised if #2 was the case, but when 9 out of 10 invoices import fine, and one invoice just won't import, I can't yet imagine how the code could be doing something like that.  And even harder to believe, when it attempts to import just the one invoice that failed, eConnect still returns different invoice info in the error, which seems completely bizarre.

I'll be running a trace to see what the actual doc variables and XML are that are being passed to eConnect, but just wondering if anyone has had an experience where eConnect returns an error code that was not the actual error, or returns document info that does not match what was passed.

Are you manually creating the XML document, or are you using 'serialization'?

 If manual, carefully check the order of the nodes agains the help file. The order is important.

Hi Steve,

The integration is using serialization. 

The original developer did choose to write out the xml file first, then bring it back in as an xml doc before he passed it to eConnect (I don't believe that is necessary, so I'm assuming he borrowed that from one of the eConnect .NET code samples), but he did not attempt to build the XML node structure.

I'm planning on digging into the code to add some debug logging to see what it is querying, what data it is sending to eConnect for each record, and compare that to eConnect's errors.  Wild guess is that there is some problem with the logic of the looping where variables aren't getting updated or the wrong record is being retrieved somehow.  Doesn't make any sense at the moment, but I'll post a follow up once I learn more.

 Thanks,

 Steve

 

Just before the XML doc is passed to econnect, stop and print out the XML doc. Carefully check the order of the nodes against the help file. In the SOP Transaction Type, for example, I originally send the 'header' node ahead of the 'lines' node ('cause I thought that was more logical). The Type requires the header to be second. The error that I got was the same as yours.

Well, I can now report that, in this case, eConnect 10 is not producing random errors and is not returning invalid document info in its error messages.  The problem I experienced was caused by a poor application design by the original developer, and that design was unable to properly handle certain simple errors and program failures, resulting in the appearance of bizarre and misleading errors coming from eConnect.  So eConnect 10 appears to be working fine, but this is a lesson on how NOT to code an eConnect integration.

For those who like The Daily WTF (http://thedailywtf.com),  here are the fun details:

The application had one "main" routine that imported RM invoices.  That routine starts by retrieving a list of the document numbers from the source system that are available for import.  Only the document numbers are retrieved--the full invoice info is not retrieved (that would be too efficient).

In the second step of bad design, the main routine then loops though every document number, and for each document number, calls a sub-routine that initiates a connection back to the source system, retrieves just 1 record with the invoice data, serializes the data, and then saves the data as an XML file to the hard drive.  The main routine then calls another sub-routine, which reads the XML file, passes it to eConnect, and handles error messages.  If you aren't dizzy already, read on.

So, with this design, what happens when the first sub-routine attempts to retrieve the 1 record with the invoice data, but for some reason the SQL statement fails or experiences an error?  Well, the developer simply writes a catch statement that does nothing, including not overwriting or deleting the last XML file that is sitting on the hard drive, and the app returns back to the calling procedure.  The calling procedure dutifully calls the next sub-procedure, which plods along and reads whatever XML file is on the hard drive.

Of course the XML file sitting on the hard drive was from a prior invoice that did import properly, and of course, eConnect errors and says that the document number already exists.  But the great part is that the integration application is logging a completely different document number--one that was never even written out as an XML file, and one that was never actually passed to eConnect.  So the log file info and the eConnect error cite completely different invoices, and the great part is that both are correct.

The code is like a .NET Rube Goldberg device.