Configuring Receive Settings for Inbound X12 Messages | MuleSoft Documentation
# Configuring Receive Settings for Inbound X12 Messages
Partner Manager enables you to configure the X12 acknowledegments, 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 sidebar, select **Partners**.
  2. Select the partner to associate with the settings.
  3. In the **Validation and acknowledgement settings** section’s **Receive from <partner-name>** column, click **X12**.
  4. Select a link to configure:
     * Acknowledgment settings
     * Validation settings
     * Control numbers
     * Character set and separators
  5. Click **Save**.


It can take up to about 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  
---|---|---  
Report non-fatal errors in acknowledgements | When checked, the AK3 segment of the generated 997 functional acknowledgment reports non-fatal errors. When unchecked, the AK3 segment of the generated 997 functional acknowledgment doesn’t report non-fatal errors.  
Report segment details | If selected, the details of segment errors are included in the functional acknowledgements generated (997) •  
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 from 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.  
### 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. Partner Manager logs all validation errors and reports them in the CONTRL acknowledgements.
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.

  
Truncate values exceeding the length limits | If selected and **Fail when value length outside allowed range** isn’t selected, Partner Manager truncates the data elements that exceed the maximum length limit in the generated output. | Disabled  
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.

  
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.

  
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.

  
Fail when too many repeats of segment | If selected, Partner Manager rejects transactions with segments repeated too many times.  
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  
Enforce code set validations | 
  * If selected, Partner Manager enforces X12 code set validations, as defined in the X12 schemas.

| Disabled  
Acknowledge every transaction | If selected, Partner Manager includes a separate AK2/AK5 segment for every received transaction set, even when all transactions are accepted in the 997 functional acknowledgment. | Disabled  
Include trailer segment details | If selected, Partner Manager includes elements from the Interchange Trailer (IEA) and Group Trailer (GE) segments of the X12 data payload. | Disabled  
Ignore included segments | If selected, the X12 read operation output includes segments with usage type 'Ignore', and you can use the segment s in message flow maps. | 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).  
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 acknowledgements for the receive messages.  
Character encoding |  Indicates the character encoding for messages. | `ISO8859_1`  
## See Also
  * Creating Inbound Message Flows
  *   * Modifying Partner Settings