eConnect error, but not the real error!

One of my customers is doing some Sales Order Processing integrations with GP 2010… and for the most part, when we run into eConnect errors, it pretty much tells you what the issue is, and you fix it and move on.

We ran into one the other day and this error wasn’t even the real error, so it wasn’t until I looked at the XML they were trying to pass did I see what the real issue is.

The Issue

The error message was this:

“Error Number = 67  Stored Procedure= taSopHdrIvcInsert  Error Description = Subtotal does not match the line item totals”

The conversation with the developers went like this:

  • Devs: Hey Jen, we’re getting this error, can you help?
  • Me: Sure. This one sounds like you need to check that the sum of the line items you’re passing in match the Subtotal field you’re passing on the header.
  • Devs: It does match.
  • Me: Well, that’s not possible… it’s saying it doesn’t match. Can you double check?
  • Devs: Already did, it still doesn’t work!
  • Me: I’ll be right over to look at it with you.


The first thing we checked was that we were all speaking the same language and that the dollar fields they were passing indeed were the same, so this error text itself wasn’t the “correct” error.

Side note: as painful as it is, when you’re troubleshooting, don’t be afraid to start with the obvious.  Had it been a simple “lines not adding up to the subtotal” error, it wouldn’t have surprised me.  It would not have been the first time I’ve helped a client where there was either a misunderstanding of what I meant or that the most basic of things that they skipped trying to find a “rare” error were actually right there like low hanging fruit.

In this case, I said we need to look at the XML they are passing in the SOP transaction.  In this case, here was a sample of the Header code, where they were receiving the error:


We looked at this and kept looking at the dollar fields, since the message was talking about subtotals not matching lines. It was clear that wasn’t the issue so we then looked at the SOP line XML, and there I saw what the issue was:


For whatever reason, the SOPType on the Header and the Line were being passed two different values.  They were passing SOPTYPE 3 on the line (Invoice) and SOPTYPE 4 on the header (Return).  GP in theory was comparing the dollar values in the context of the document type and realizing they weren’t a match.

Of course the error text REALLY should say “The SOPTYPE on the header does not match the SOPTYPE on the line”, and it would be have all been a little more obvious!

comments powered by Disqus
Built with Hugo
Theme Stack designed by Jimmy