Should acknowledgement messages be responded when they have invalid control numbers?
-
I understand you should not respond to 997 and 999 acknowledgement messages, since they are themselves responses. But, what if the ack has a syntax error, or has an invalid or re-used control number. Do I respond to these with another ack message? Should I process the ack at all (partially process), or should I always ignore acknowledgement messages with errors?
-
@ross most 997/999s are automatically generated by an EDI system, so 'broken' (syntactically-invalid) files should be rare – but people hand-roll files during testing all the time, so it certainly is within the realm of possibility.
That said, there are semantic notes on both the 997 and 999 that address exactly this question.
From the 997:
These acknowledgments shall not be acknowledged, thereby preventing an endless cycle of acknowledgments of acknowledgments. Nor shall a Functional Acknowledgment be sent to report errors in a previous Functional Acknowledgment.
From the 999:
Neither the 997 nor the 999 Acknowledgment shall be acknowledged, thereby preventing an endless cycle of acknowledgments of acknowledgments. Nor shall an Implementation Acknowledgment be sent to report errors in a previous Implementation Acknowledgment.
There is no such note on the TA1. In the X12 standard itself (X12.5, section 3.2), it says the following:
The TA1 reports the results of the syntactical analysis of the interchange control header and trailer. There is no acknowledgment for the TA1, thereby preventing an endless loop of acknowledgments.
While it does not address the case of whether to send a TA1 to report errors in a previously-received TA1, I would assume it would follow the same convention. To be certain of this, I'd recommend submitting a Request for Interpretation to X12.
-
- We should not sent an acknowledgement for an acknowledgement
- One of the two options could be picked
a) Create an 824 (text msg with rejection and request for corrected document)
b) If the exceptions get reviewed by someone (like a support team) someone may need to reach the source of bad acks (acks with invalid control numbers)