Friday, June 21, 2013

Not an eConnect Bug: taPMTransactionInsert Error 313: Tax table detail does not equal the tax amount

Mea culpa!  After further digging, I found that *I* was the culprit behind this error--not a huge surprise.  I had mistakenly assigned the document number to the VCHRNMBR node for taPMTransactionTaxInsert.  My bad!


A client asked for a modification to an existing AP invoice eConnect import.  They wanted to start importing freight and sales taxes for their AP invoices.  No big deal, right?

So I do a quick test to confirm that there would be no issues bringing in freight and tax.  When I attempted to import a Payables Transaction with sales tax, I received the following eConnect error:

taPMTransactionInsert Error 313: Tax table detail does not equal the tax amount

I figured I did something wrong with the sales tax setup, so I double checked the tax setup and confirmed that I could manually enter the same transaction info I was attempting to import.  Everything looked okay.

But the Error 313 just wouldn't go away.  I assumed I was doing something wrong, perhaps not populating an eConnect property, or setting a value incorrect.  I tried several things, but nothing worked.

I then did a full trace of the transaction insert performed by taPMTransactionInsert, as well as the insert performed by taPMTransactionTaxInsert.  I retrieved the EXEC call and all of the parameters from the trace, confirmed the tax record was being inserted properly into PM10500, and then tested the validation code from taPMTransactionInsert that was throwing the 313 error.  Everything looked fine.  But obviously something wasn't working properly when the process was called by eConnect.

After Googling the error several times and checking various forums, I finally tried searching the GP Partner Forum.  Behold, I found a post from May 2011 where a poor soul was experiencing the same problem with eConnect 10.

Miraculously, he had discovered that if you set the document number and voucher number to the same value, eConnect will successfully import the AP invoice.  But if the document number and voucher number are different values (which they normally are), eConnect will return the 313 error.  (David C., hats off to you for figuring that one out!)

Skeptical, I modified my import to set the document number value to be the voucher number.  And to my surprise, the transaction imported without error.  So it seems that this is an eConnect bug that has been tucked away for at least 2 years.   So I then incorrectly started to think that this was a bug.

I've glanced at the eConnect stored procedure code to see how this workaround could possibly solve the problem, but it isn't obvious where or how the problem might be occurring.

UPDATE: After reviewing the serialized XML, I found the my mistake in my code.

In my test data, I have a voucher number of V0000560, and a DOCNUMBR value of 11.

    < taPMTransactionInsert >
      < BACHNUMB>MXAP0906-13< /BACHNUMB>
      < VCHNUMWK>V0000560< /VCHNUMWK>
      < DOCTYPE>1< /DOCTYPE>   

But in taPMTransactionTaxInsert, the document number is being sent in for the VCHRNMBR node.

     < taPMTransactionTaxInsert>
        < VCHRNMBR>11< /VCHRNMBR>
        < DOCTYPE>1< /DOCTYPE>
        < BACHNUMB>MXAP0906-13< /BACHNUMB>
        < TAXAMNT>1< /TAXAMNT>
        < PCTAXAMT>1< /PCTAXAMT>
        < TDTTXPUR>12.22< /TDTTXPUR>
        < TXDTTPUR>12.22< /TXDTTPUR>
      < /taPMTransactionTaxInsert>
After reviewing my code one more time, I found that this was my dumb mistake.  I was incorrectly assigning the invoice document number as the voucher number in taPMTransactionTaxInsert.

I'm going to write it up and submit a support case.  No need for a support case!

Written By Steve Endow

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

No comments: