The 278 notification & acknowledgment spec says that the receiver can add their own trace number when generating the acknowledgment, and there is similar language in the TRN situational rules. However, the event (2000E) and service (2000F) TRN segment limits are 3 on both the notification and acknowledgment. The notification can also send both trace type codes, but we’d expect they could only send current. Is there a typo in the segment limits (notification limit should be 2 or acknowledgment limit should be 4) and the allowed types for service TRN? Otherwise, please clarify how we can echo received trace numbers and add our own.
The situational rules for the event and service loops state they should only be sent if there was an error or a receipt number was assigned. Does receipt number refer to an administrative reference number (REF) assigned by the receiver, such that we should omit this loop if it was valid even if TRNs were received?
The subscriber (2000C) and dependent (2000D) loops also use similar language regarding echoing and adding our own trace number, but they can’t be sent on the notification, just the acknowledgment. We are unclear how to use these segments. Can you provide an example of how to use these segments? Were these possibly hold-overs from a previous version of the spec?
Guidance on how to generate a valid acknowledgment when receiving a 278 notification.
Due to a limitation in the technical report, all trace numbers cannot be “echoed” back. If more than 2 are sent, the transaction will fail during the compliance check. The TRN segments (2000C and 2000D) have been removed from subsequent versions.
The 005010X216 implementation guide contains valid examples at the TRN segments at both the event and service levels.
If this is functionality that is needed for your business and is not currently supported in a published TR3, submit an X12 maintenance request at https://x12.org/resources/forms/maintenance-requests.