Configure Receive Settings for Inbound X12 Messages

Partner Manager enables you to configure the X12 acknowledgments, validation rules, character encoding, and control numbers to apply when receiving inbound X12 messages from the selected partner.

To configure X12 receive settings:

  1. In the navigation menu, select Partners.

  2. Select the partner to associate with the settings.

  3. In the Validation and acknowledgment settings section’s Receive from <partner-name> column, click X12.

  4. Select a link to configure:

  5. Click Save.

It can take up to approximately five minutes for your configuration changes to sync with Mule.

Acknowledgment Settings

Use the following settings to configure the acknowledgments to send in response to inbound X12 messages:

Setting Description Default

Send TA1 for each transmission from <recipient>.

Provides a Technical Acknowledgment (TA1) to the Interchange sender that reports the status of the processing of an interchange header and trailer by the address receiver:

  • If the ISA and IEA of a received X12 message are valid, the host sends a positive TA1 ACK, regardless of the status of the other content.

  • If the ISA and IEA of a received X12 message are not valid, the host sends a TA1 ACK with an error code.

The TA1 ACK is sent inside an ISA or IEA envelope. The ISA and IEA are no different than any other interchange.

Disabled

Send 997 functional acknowledgment when messages fail to route to a message flow

Sends a functional acknowledgment (the receipt and syntactical acceptability of a message) when there is a failure to route the message to one of the message flows.

Disabled

X12 997 Functional Acknowledgment

The X12 997 functional acknowledgment reports the status of a received interchange. It reports all of the errors encountered while processing the received document. As with all X12 transaction sets, the 997 functional acknowledgment is sent inside a GS or GE envelope.

The 997 functional acknowledgment does the following:

  • Acknowledges the receipt of an interchange or functional group

  • Accepts or rejects one or more functional groups or transactions

  • Verifies and reports compliance with the standard

If an interchange contains multiple groups, a 997 acknowledgment is returned for each group.

If a group contains multiple transaction sets, then the acknowledgment for that group contains one loop for each transaction set. This applies only if AK2 loops are generated for accepted transaction sets.

Validation Settings

Use these settings to ensure that all X12 messages received from a partner meet validation rules. Parter Manager logs all validation errors and reports them in the CONTRL acknowledgments.

Setting Description Default

Fail when value length outside allowed range

  • If selected, Partner Manager rejects transactions with data element values that are too long or too short against the definition in the EDI schema used.

  • If not selected, Partner Manager uses the values.

Enabled

Fail when invalid character in value

  • If selected, Partner Manager rejects transactions with invalid characters.

  • If not selected, the characters are either passed through or substituted.

Enabled

Fail if value is repeated too many times

  • If selected, Partner Manager rejects transactions with values that are repeated too many or too few times.

  • If not selected, Partner Manager accepts the values.

Enabled

Fail if unknown segments are used

  • If selected, the Partner Manager rejects transactions that contain unknown segments.

  • If not selected, Partner Manager ignores unused segments.

Disabled

Fail when segments are out of order

  • If selected, Partner Manager rejects transactions that have out-of-order segments.

  • If not selected, the segments are reordered.

Enabled

Fail when too many repeats of segment

If selected, Partner Manager rejects transactions with segments repeated too many times.

Enabled

Fail when unused segments are included

  • If selected, Partner Manager rejects transactions containing segments marked as unused in the schema.

  • If not selected, Partner Manager ignores unused segments.

Disabled

Enforce conditional relationship validations

  • If selected, any missing conditional data elements cause the generation of the X12 transaction to fail.

  • If not selected, Partner Manager does not enforce relationship validations.

Disabled

Control Numbers

Use these settings to apply validations related to the use of control numbers within inbound X12 messages:

Setting Description Default

Requires unique interchange control number (ISA13)

If selected, the host records the interchange numbers previously processed and rejects duplicate interchange numbers from the same partner (as determined by the interchange sender and receiver identification).

Enabled

Requires unique group control number (GS06)

If selected, the host enforces globally unique Group Control Numbers (GS06) for received functional groups.

This configuration requires group numbers to be unique across all interchanges received from the same partner and application, as determined by the interchange sender and receiver identification, combined with the functional group sender and receiver application codes.

Disabled

Require unique transaction set control number (ST02)

If selected, the host enforces globally unique Transaction Set Control Numbers (ST02) for received transaction sets.

This configuration requires transaction set numbers to be unique across all functional groups received from the same partner and application, as determined by the interchange sender and receiver identification, combined with the functional group sender and receiver application codes.

Disabled

Character Set and Encoding

Use these settings to apply character set and encoding options for received X12 message:

Setting Description Default

Character set

Defines the characters allowed in string data. When set, invalid characters are replaced by the substitution character. If no substitution character is enabled for receive messages in the parser options, Partner Manager rejects the messages. Either way, the invalid characters are logged and are reported in the 997 functional acknowledgments for the receive messages.

EXTENDED

Character encoding

Indicates the character encoding for messages.

ISO8859_1

Was this article helpful?

💙 Thanks for your feedback!

Edit on GitHub