Resolution:
Description
==========
BC is successfully sending and receiving X12 and EDIFACT documents to trading partners. Occasionally, BC will not reconcile an inbound X12 997 and and EDIFACT CONTRL message with the original outbound transaction

Environment
===========
TIBCO BusinessConnect EDI Protocol powered by Instream 6.X.X

Cause
===========

When BC sends an outbound EDI payload, it does not log the transaction until the underlying transport indicates that the request has been successfully transmitted to the trading partner. Once the transport has confirmed the transfer, BC will update an internal DB table, called the ACK_RECONCILIATION table, with the control numbers in the X12 transaction. When a 997 or a CONTRL message is received, translated and validated from a trading partner, it will immediately check the ACK_RECONCILIATION table for to find the original transaction and then mark that transaction reconciled in the audit log. If no entry exists in the ACK_RECONCILIATION table for the 997, BC will just pass the information to the private process and never try to reconcile the transaction again. This delay can be lengthy, especially if using asynchronous receipts with AS2 transports.

If the 997 is received before BC had a chance to update the ACK_RECONCILIATION table will cause the ACK not to be reconciled

Resolution
===========
In most cases this a known issue with no workaround.  When using AS2, use synchronous logging which causes the TP to send the MDN receipt down the same channel that the original request came in on. It will also remove the race condition.