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!

(originally posted on, and migrated to this site in October 2017)

5 thoughts on “eConnect error, but not the real error!

  1. Reply
    Victoria Yudin - December 24, 2013

    Jen, I can’t believe you were expecting the error message to actually tell you the reason it was failing. I think you need a few days off! 🙂

    Happy Holidays!

    1. Jen Kuntz - December 24, 2013

      LOL! They don’t speak to you? With a slight Fargo accent? Hmm, maybe you’re right about those days off!

      Happy holidays to you as well!

  2. Reply
    Deanne - December 27, 2013

    OK – but how do you fix this error?

    1. Jen Kuntz - December 29, 2013

      Hi Deanne,

      If you’re getting the same one due to the same issue, in my client’s case, they needed to fix their integration code/data to have both SOPType 3 or 4 on the header or line, depending on what they were actually trying to import. You cannot have a mix, on the header tell it it’s an invoice but feed lines in with a type telling it it’s a return, for instance.

      Hope that helps.

  3. Reply
    Jose Conde - December 26, 2016

    Hi Jen,

    I know this is an old post. But i want to share my findings. I’m using eConnect to integrate Sales Order to GP. Evething its working well and one day the eConnect integration stops working for one particular file. I received this “Marvelous” error to.

    That’s what I do to find the problem,

    1. Check SOPTYPE, Header/Detail, it’s OK
    2. Check SOPNUMBER, Header/Detail, it’s OK
    3. Verify if the SOPNUMBER exists in the SOP10100 Unposted/Work Transactions (header), not find record
    4. Verify if the SOPNUMBER exists in the SOP10200 Unposted/Work Transactions (line detail), BUYAAAAAA, find one record.

    I’m sure that something bad happened with this transaction. I run Check Links for Sales Work and WALLAAAAAA, now the “Error Number = 67 Stored Procedure= taSopHdrIvcInsert Error Description = Subtotal does not match the line item totals” vanish. The integration just start working againg.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scroll to top