X12.56 Interconnect Mailbag Control Structures

Overview

Version 1.0 by

Todd Gould March 8, 2010

Loren Data Corp. PO Box 600

Indian Rocks Beach Florida 33785 USA

813-426-3355 www.LD.com

Introduction

EDI Value Added Networks (VANs) use the X12.56 Interconnect Mailbag Control Structures (X12.56 Standard) to pass interchanges between each other. Millions of X12.56 Mailbags are processed each day. The fact that the X12.56 Standard is so widely used among most North American VANs is a testament to its usefulness. That it remains essentially in its original form shows that it was well thought out for its intended needs. This is a practical, not technical, overview of the X12.56 Standard. For the X12.56 technical specification, please refer to The ASC X12 (X12.56) Interconnect Mailbag Control Structures documentation. From the X12.56 Standard under Purpose and Scope:

This standard defines the control segments used to start and end a mailbag containing EDI data to be exchanged between two interconnecting entities. The mailbag includes zero or more interconnect acknowledgment segments and zero or more EDI data interchanges. The basic interconnect mailbag consists of an interconnect mailbag header segment (IH), the EDI data to be transmitted from one interconnect entity to another, and the interconnect mailbag trailer segment (IT). In addition, an interconnect mailbag acknowledgment segment (IA) is provided to report complete receipt and safe storage of an interconnect mailbag. The purpose of this standard is to provide control structures and an audit mechanism to facilitate the exchange and receipt acknowledgment of EDI data between interconnecting entities. The original sender and the ultimate receiver of the data contained in the mailbag have no responsibility for creating, managing, or removing the interconnect mailbag segments. This standard is solely for use between sites acting as interconnect entities.

The X12.56 Standard also recognizes its limitations: Delivery of data from the original sender to the ultimate receiver may require several

interconnect links. It is recognized that other point-to-point data tracking mechanisms exist. The interconnect mailbag control structures are designed to stand alone in addressing a given interconnect link. The structures are in no way dependent on the types of data tracking mechanisms that may be used in links prior to or following a link that employs the interconnect mailbag control structures.

How it works

Process

The process is an asynchronous send and acknowledge model. VAN-A places one or more Interchanges in an X12.56 Interconnect Envelope, which includes a unique Control Number and a count of the number of interchanges included. This Mailbag is then sent to VAN-B over the preestablished communications channel.

© 2010, Loren Data Corp. X12.56 Interconnect Mailbag Control Structures: Overview All rights reserved 1-3 v1.0

VAN-B then evaluates the Mailbag to confirm that there is the indicated number of “valid” interchanges in the mailbag. The interpretation of “valid” varies from VAN to VAN, but generally means confirming a valid Interchange envelope without regards to full transaction syntax (this is left for the end-user processing). If the IH/IT envelope is intact and the count of interchanges match, then VAN-B generates a Mailbag back to VAN-A with an IA segment positively acknowledging the receipt of the VAN-A mailbag. If there is a problem with VAN-A’s mailbag, VAN-B generates a Mailbag back to VAN-A with an IA segment indicating the nature of the problem.

Interchanges

While an X12 construct, the X12.56 Mailbags regularly contain X12 ISA/IEA envelopes, EDIFACT UNB/UNZ envelopes and any other recognized traditional EDI standards (e.g. Tradacoms).

The Segments

For those familiar with the ISA/IEA Interchange envelope, the IH/IT Interconnect envelope is very similar. The X12.56 Standard consists of three simple segments. The IH and IT are used to define the X12.56 envelope itself and the IA is used to send ACKs and NACKs. Without getting into the technical details of the Mailbag segments a brief description follows.

IH – Interconnect Header

The IH is the very first data in the mailbag structure. Contained in the IH segment is the sending and receiving VAN information, date/time stamp and a control number.

IT – Interconnect Trailer

The IT is the very last data in the mailbag structure. The IT segment contains a count of the number of Interchanges, a count of the number of Interconnect

Acknowledgment Segments (IA) and a repetition of the control number in the IH segment.

IA – Interconnect Acknowledgment

Zero or more IAs can be contained in a mailbag. While they can be combined with Interchanges in the same mailbag, most commonly they are sent in their own mailbag. The IA contains a reference to the control number of the mailbag being acknowledged, a status code (e.g. Accept/Reject) and if rejected one or more codes explaining the reason for the rejection. (e.g. the most common W1 means rejected duplicate mailbag – based on control number).

Real-World Implementation

Common Usage

The “Mailbag Number” corresponding to the Control Number in the IH segment is the main way VANs use to verify the receipt and processing of Interchanges over Interconnects. When a company on VAN-A sends an interchange to a trading partner on VAN-B and the interchange does not arrive, one of the first requests of VAN-A is, “What was the Mailbag Number?” The second significant benefit of the Mailbag is the ability to prevent duplicate transmissions. VANs routinely reject any Mailbag that has the same Mailbag Number from the same VAN. The standard rejection code of W1 makes it easy for the sending VAN to understand this is a low level warning, and not the case of interchanges that cannot be processed.

Common Problems

By the definition of the standard, Mailbags are to be fully rejected or accepted. In practice, some VANs do partially process defective mailbags. Some VANs do not send or properly process reject codes. As mentioned, the most common code is W1 indicating a duplicate Mailbag. Several VANs do not send the W1 code for duplicates but substitute another. Other VANs do not process the receipt of a W1 code properly and regularly follow up with a

© 2010, Loren Data Corp. X12.56 Interconnect Mailbag Control Structures: Overview All rights reserved 2-3 v1.0

© 2010, Loren Data Corp. X12.56 Interconnect Mailbag Control Structures: Overview All rights reserved 3-3 v1.0

support call of the “why didn’t mailbag ### process.” Also, since not all VANs properly catch duplicate mailbags, there is a lot of wasted NetOps interaction and wasted time with the “did you receive Mailbag ##” request. If all VANs properly blocked duplicates and sent a W1 NACK, it would be a simple process of automatically resending any missing mailbag. If it had not been processed the first time, it would get an ACK, if it was a duplicate a W1 NACK, and if no response on the second try escalation would be indicated.

Limitations of the Current Standard

Partial Transmission

The current standard says that partial transmissions should not be NACKed as the sending system would know that the communication line was dropped. As that is not the case in today’s world, it is necessary to NACK partial mailbags and this wording should be removed from the standard.

NACK Codes

In general, the NACK codes (other than W1) often do not communicate enough information for recovery and require manual communication between the two VANs to solve.

Multi-Hop

The X12.56 Standard only handles a single hop between VANs. If the payload is forwarded to another network it uses a new mailbag without any reference to the original.

Non-Delivery

A positively acknowledged mailbag does not mean that an interchange can be delivered, only that it is intact. Interchanges sent to the wrong VAN or to terminated mailboxes are not communicated via the X12.56 protocol.

Acknowledgement Turnaround Time

Mailbag Acknowledgments are not returned in real-time, nor is there even a standardized, expected response time.