Skip to main content
Next section

Settings for X12 Business Services

Provides reference information for settings of an X12 business service.

Summary

X12 business services have the following settings:

Group Settings See
Basic Settings Target Config Names, Doc Schema Category, Batch Handling, Settings for Business Services” in Using Virtual Documents in Productions
Acknowledgement Reply Target Config Names (File), Validation Mode, Validation, SNIP Level, Batch Error Action, Batch Reply Type, AddNackErrText, Reply Mode sections in this topic
Connection Settings Tolerate Newlines sections in this topic
Additional Settings Search Table Class Settings for Business Services” in Using Virtual Documents in Productions
Reply Target Config Names (FTP) section in this topic
  Local Application ID, Default Char Encoding, sections in this topic

The remaining settings are either common to all business services or are determined by the type of adapter. For information, see the section “Reference for Settings” in each of the following books:

Add Nack Error Text

Add extra error-text field to TA1 & 997/999 AKx segments when generating error-status reply messages; otherwise do not embed internal error state information in the Acknowledgement messages.

Batch Error Action

Specifies what to do when a validation error is detected in a batch Interchange document. Options include:

  • Reject With All Errors — Reject the whole batch if any error is found in any document within it. Enumerate all errors found in the batch if Batch Reply Type allows for reporting them. This prevents forwarding any documents in a batch until all have been read and validated.

  • Reject On First Error — Reject the whole batch when the first error is found in any document within it. Do not bother checking for more errors or parsing any further contents of the Interchange. This prevents forwarding any documents in a batch until all have been read and validated.

  • Reject Individual Errors — Reject only those documents within the Interchange that have errors. Forward each acceptable child document to its target(s) as soon as it has been read and validated. This is the default.

  • Accept With Errors — Forward all documents, but the 999 ACK notes all the errors.

If Reply Mode is Application and Batch Error Action is not Individual, it could happen that InterSystems IRIS® forward some of the documents in a batch before rejecting the whole batch upon encountering an error.

Batch Handling

X12 Transaction Set documents are often packaged in a batch document called an Interchange, which contains nested sub-batches called Functional Groups. The Batch Handling setting specifies how InterSystems IRIS treats received document batches. The options are:

  • Whole Batch — Do not process child documents individually; accumulate and send the whole batch as one composite document.

  • Single-Session Batch — Forward all documents in the batch together in one session; the session includes objects representing the parent document header and trailer segments. This is the default.

  • Multi-Session Batch — Forward each document in the batch in its own session, including the objects representing the batch header and trailer segments.

  • Individual — Forward each child document in the batch in its own session; do not forward objects representing the parent batch document’s header and trailer segments.

Batch Reply Type

Specifies the type of batch reply to create for an Interchange batch that has been received. The following table lists the possible choices:

Value Meaning
None Do not generate a batch reply. If an error occurs, do not create any immediate notification reply to the sender.
All Generate a reply Interchange containing a reply notification for every TransactionSet received in the Interchange.
All+TA1 Generate a reply Interchange containing a TA1 segment that indicates acceptance or error status for the entire Interchange, and a reply notification for every TransactionSet received in the Interchange.
Errors
Whether or not errors are found, generate a reply Interchange. If no errors are found, generate an empty reply Interchange. If errors are found, generate an Interchange that contains reply notifications only for TransactionSets in which errors are detected.
This is the default setting if no choice is specified.
OnlyIfErrors If errors are found, generate a reply Interchange that contains reply notifications only for TransactionSets in which errors are detected.
Successes Whether or not errors are found, generate a reply Interchange. If errors are found for every TransactionSet, generate an empty reply Interchange. Otherwise, generate a reply Interchange that contains reply notifications only for TransactionSets in which no errors are detected (successes).
TA1 Generate a reply Interchange containing only a TA1 segment that indicates acceptance or error status for the whole Interchange received.
OnlyIfErrorTA1 If errors are found, generate a reply Interchange that contains only a TA1 segment that indicates error status for the whole Interchange received.
ISA14-TA1 If field ISA:14 of the incoming ISA header segment is set to 1, generate a reply Interchange containing only a TA1 segment; otherwise return nothing.
ISA14-OnlyIfErrorTA1 If errors are found and field ISA:14 of the incoming ISA header segment is set to 1, generate a reply Interchange containing only an error TA1 segment; otherwise return nothing.
Byte Generate a reply consisting of a single character code: 'A' if the entire Interchange is accepted, 'R' if it is rejected due to one or more errors.

All of the options that relate to TA1 segments are used to force a TA1 segment to be generated, often as the only body segment of the reply interchange. This convention is used to represent the presence or absence of errors in the entire inbound Interchange. However, if an error is found in the incoming ISA or IEA that can only be reported in a TA1 segment, then a TA1 is generated even if the configured setting does not force a TA1 to appear.

Default Char Encoding

Specifies the character set of the input data. InterSystems IRIS automatically translates the characters from this character encoding. Supported values are UTF-8 or any member of the Latinn family. The value Native means to use the native encoding of the InterSystems IRIS server.

Placing a @ (at sign) character at the beginning of this field means that the field identifies an internal NLS Translation Table instead of a logical character encoding.

The default depends on the adapter.

For background information on character translation in InterSystems IRIS, see “Localization Support” in the Orientation Guide for Server-Side Programming.

Local Application ID

Colon-separated LocalID:Qualifier code that represents the facility and application that receive X12 documents via this business service. These are used to create reply document headers. The @ (at sign) character represents using the corresponding field from the incoming document. If your ID must contain a literal @ symbol, escape it with back slash: \@

The default value is:

EnsembleX12Service:03

Reply Mode

Specifies how to issue X12 reply documents (such as TA1 and 997). Options include:

  • Never — Do not send back any reply.

  • Immediate — Send a reply from the business service immediately upon receipt of an Interchange. This is the default.

  • Application — Wait for a response from the target configuration item. When it arrives, relay the reply back to the sender. If validation fails or some other error occurs, generate an immediate reply according to the option selected for BatchReplyType.

Reply Target Config Names

(File and FTP only) Specifies where the reply that the Business Service constructs, based on the validation that it performs, is to be sent. Usually the list contains one item, but it can be longer. The list can include business processes or business operations, or a combination of both.

Compare to Target Config Names.

SNIP Level

Relevant only when Validation Mode is SNIP.

  • SNIP level 1 — segments are valid , segment order is valid, element attributes are valid, numeric data elements have numeric values, and message conforms to X12 rules.

  • SNIP level 2 — meets HIPAA requirements, such as presence of required elements, non-use of elements marked as not used, and values conforming to the code tables.

Tolerate Newlines

True or False. If True, the business service processes an incoming X12 file without error, even if new lines have been inserted into the file after (or in place of) segment terminators to enhance readability. If False, these extra new lines trigger an error in parsing the file. The default is True.

Validation Mode

Two kinds of X12 validation are available:

  • SNIP level validation — validates the X12 message according to the standards developed by the Workgroup for Electronic Data Exchange (WEDI) Strategic National Implementation Process (SNIP).

  • Flag-based validation.

SNIP validation enables you to validate that:

  • SNIP level 1 — segments are valid , segment order is valid, element attributes are valid, numeric data elements have numeric values, and message conforms to X12 rules.

  • SNIP level 2 — meets HIPAA requirements, such as presence of required elements, non-use of elements marked as not used, and values conforming to the code tables.

Flag-based validation enables you to validate that:

  • Required fields are present and that all fields are allowed by the schema.

  • Number of fields within a segment and whether they are repeated as allowed by the schema.

  • Data types for fields and components are correct.

  • Field values conform to the code tables specified.

  • Field and components conform to length restrictions.