Basic structure of X12 data

An X12 file can contain several interchanges (segments ISA to IEA). The ISA segment has a unique interchange ID that is repeated in the IEA segment. The ISA segment also declares the segment delimiter (usually ~), data element delimiter (usually *), and component delimiter (usually :).

Each interchange can contain several groups of transactions (segments GS to GE). A group starts with a GS segment, containing the group ID, and it ends with a GE segment, containing the same unique group ID (within the interchange).

Each group typically contains several transactions. Each transaction starts with an ST segment, ends with an SE segment, and has an ID that is unique within the group.

A transaction itself contains several data segments. Each data segment starts with an identifier, followed by a list of data elements, which are separated by the data element delimiter and terminated by a segment delimiter.

Each data element can contain either a simple value or a composite value. The sub-elements are separated by the component delimiter.

Functionality of the X12InputCheckUnit

The unit can be used in phase 5 of a so-called check profile. Differing from other units, the X12InputCheckUnit always reads the backup file (source data) of the current job. The target structure of the check profile is only important for dynamically providing parameters to the integration unit. In particular, the concrete data structure is recognised only by the occurrence of an ST segment. The appropriate processing profile (target profile) is therefore only determined by the check profile. The name of the target profile is usually passed on to the integration unit by a variable.

First of all, the integration unit checks the integrity of the interchange header (ISA segment) and footer (IEA segment), by making sure they have the same ID, and the counter in segment IEA does match the number of contained groups.

Then, each group (segments GS to GE) is checked separately, by making sure GS and GE have the same ID, and the counter in segment GE does match the number of contained transactions.

After that, within each group, each transaction (segments ST to SE) is checked separately by making sure ST and SE have the same ID and the counter in segment SE does match the number of contained segments.

Finally, the segments are checked. This is done by comparing them with the source tree of the target profile.

The parameter strong check=true causes the X12 parser to treat a data segment as an error if there is no definition for it in the source tree of the target profile. If the parameter instant check=true, the test is performed immediately on mandatory fields, data types and field sizes. This is the basis for providing the segment number and the original segment data in an error message.

If for example, a group contains four transactions, three of which are error-free and one contains an error, the erroneous transaction is removed from the original data. The counter in the GE segment is adjusted accordingly. The 'adjusted data' is sent to the target profile via Message.

The faulty transaction is placed in a copy of its GS and GE segments and the GE counter is adjusted. This group is now placed in a copy of its ISA and IEA segment and the IEA counter is adjusted. Any additional failed transactions would be added here as well. This X12 interchange is now sent to the specified error profile. If the integration unit parameter for the error profile has not been set, the data will be sent to the error profile configured in phase 1 of the target profile instead.

A formal check protocol is sent to the configured X12_997 profile via Message. It contains an OK status record for each valid transaction and an ERR status record for each invalid transaction. The actions in their sequence:

1) Check data by using the source structure of the target profile.
2) Send check protocol to X12_997 profile.
3) Send errorless data to the target profile.
4) Send faulty data to the error profile.

This check protocol can be used to automatically generate confirmations or error messages for each individual transaction. The X12 specification introduces the transaction type 997, which is intended for such feedback.

Structure of the X12 check protocol

The first dataset is a copy of the ISA segment, followed by a copy of the GS segment and below that the status records (OK, or ERR) for each transaction of the group. Each status record starts either with an OK, or an ERR. The next line is a copy of the complete transaction data (ST to SE), to which that status refers, followed by an empty line. This is repeated if there are several transactions. The actual test information is contained in the status records. The ISA segment, the GS segment, and the entire transaction data are only included for information or further evaluation. The status records have a CSV structure with the pipe character as the field separator. If the interchange contains more groups, the next group again starts with a copy of its GS segment, and so on.

An excerpt of the protocol, here an ERR status record.

ERR|000000602|603|0603|§1001|2|F337-1|BIA*08*DC*DAILY STATUS*20130424|mandatory field has no value

An OK status record begins with match code OK and ends with the transaction ID ( ST ID), so in front of the character § for the error code.

Parameters

Error codes