Transforming and generating EDI - AWS B2B Data Interchange
EDI acknowledgementsControl numbers

Transforming and generating EDI

There are multiple ways to transform or generate EDI in AWS B2B Data Interchange. This topic describes the various ways you can create and configure inbound and outbound transformations.

  • Inbound EDI: you receive an EDI file from your trading partner. AWS B2B Data Interchange converts this EDI file into a JSON or XML file with a service-defined structure. A mapping template that you provide—in JSONata or XSLT format—is optionally applied to this file to produce a JSON or XML file with the structure that you require.

  • Outbound EDI: you have a JSON or XML file containing data that you wish to use in an EDI file. A mapping template that you provide— in either JSONata or XSLT format—is applied to this file to generate a JSON or XML file in the service-defined structure. This file is then converted to an EDI file.

Topics

EDI acknowledgements

B2Bi automatically generates acknowledgement files that you can use to send to your trading partner to communicate that the file was received and to report errors. The generated acknowledgement is stored in your Amazon S3 bucket alongside the transformed EDI, and an event is emitted by the B2Bi service to Amazon EventBridge.

The service generates the following types of acknowledgements:

  • 997 functional acknowledgements: the 997 is a functional acknowledgement used to confirm receipt of X12 EDI transactions and to report transactional errors. A 997 acknowledgement serves as a response to an individual EDI message or group of messages. It contains information about the receipt of the upstream transaction, such as whether it has been accepted, accepted with errors or rejected.

  • TA1 interchange acknowledgements: A TA1 is an interchange acknowledgement used to confirm the receipt of X12 EDI interchanges and to report syntactical errors. It reports the status of the processing of an interchange header and trailer by the addressed receiver or the non-delivery by a network provider.

  • 999 functional acknowledgements: there are two types of 999 functional acknowledgement, as follows:

    • 999 functional acknowledgement for HIPAA transactions: the service generates 999 X231 acknowledgements for all X12 version 5010 HIPAA transactions.

    • 999 functional acknowledgement for non-HIPAA transactions: the service generates 999 acknowledgements for all other healthcare-related X12 transactions.

All inbound X12 transactions receive a TA1, while only certain transactions receive a 997. Finance, transportation, supply chain, and communication & control transactions typically receive a 997. These acknowledgements are created by default, and are not configurable.

Note

The service generates either a 999 or 997 acknowledgement: not both.

For details of the generated events, see Details fields for acknowledgement events.

One example use case is as follows: Retailer B responds with an EDI 997 Functional Acknowledgement, which communicates to Vendor A that their EDI 810 Invoice was received and is syntactically valid.

  1. Vendor A sends Retailer B an EDI 810 Invoice.

  2. Retailer B responds with an EDI 997 Functional Acknowledgement, which communicates to Vendor A that their EDI 810 Invoice was received and is syntactically valid.

B2Bi creates events when generating acknowledgements (for both successful and failed scenarios). The primary value of generating these events is for returning the acknowledgement to the trading partner. You can use AWS Transfer Family (or any other data transfer service) to send these acknowledgements to your trading partner.

For details on the output paths for acknowledgement files saved to your Amazon S3 buckets, see

File output paths

This section describes the output paths for acknowledgement files saved to Amazon S3.

Let's assume that a customer configures their EDI trading capability to have the following input and output directories.

  • Input: s3://amzn-s3-demo-bucket/IN/

  • Output: s3://amzn-s3-demo-bucket/OUT/

For this configuration, the following are the paths for the input and corresponding transformed output directories:

  • Inbound EDI: s3://amzn-s3-demo-bucket/IN/TP_ID/edi214xml-test83.txt

  • Transformed output: s3://amzn-s3-demo-bucket/OUT/TP_ID/edi214xml-test83.txt.2023-11-21T19:26:49.774Z.xml

The format for the acknowledgement filename depends on whether the incoming EDI document uses a trading capability or is called by the StartTransformerJob API.

When using a trading capability, the format for the acknowledgement files is s3://amzn-s3-demo-bucket/OUT/TP_ID/ACK/filename.timestamp.997 (.TA1 for TA1 acknowledgements).

The following are examples for the acknowledgement output filenames:

  • 997 acknowledgement: s3://amzn-s3-demo-bucket/OUT/TP_ID/ACK/edi214xml-test83.txt.2023-11-21T19:26:49.774Z.997

  • 999 X231 acknowledgement: s3://amzn-s3-demo-bucket/OUT/TP_ID/ACK/edi835x221.xml-test83.txt.2023-11-21T19:26:49.774Z.999x231

  • TA1 acknowledgement: s3://amzn-s3-demo-bucket/OUT/TP_ID/ACK/edi214xml-test83.txt.2023-11-21T19:26:49.774Z.TA1

For direct transformer API calls, the format is s3://amzn-s3-demo-bucket/OUT/ACK/filename.timestamp.997 (.TA1 for TA1 acknowledgements).

Control numbers

This section describes how AWS B2B Data Interchange generates interchange control numbers. An interchange control number is an integer that uniquely identifies an interchange when it's sent to a trading partner. It's used to track each acknowledgement or EDI document sent to a particular partner. The control number increases by one each time an interchange is sent to that partner.

  • The outermost envelope is the Interchange control envelope: begins with an ISA segment and ends with an IEA segment.

  • The mid-level envelope is the functional group: begins with a GS segment and ends with a GE segment

  • The innermost envelope is the transaction set: begins with an ST segment and ends with an SE segment.

In AWS B2B Data Interchange, we use control numbers when generating EDI acknowledgements (inbound EDI process), and when generating EDI documents from JSON or XML source files (outbound EDI process).

  • For generating the EDI acknowledgements, the control number information is taken directly from the incoming EDI document.

  • In the case of outbound EDI, when you create a partnership, you provide Outbound EDI configuration details. These details are then used to populate the control numbers for the generated EDI document.

The following sample EDI document shows the relationship of the three envelopes (indenting added for readability).

ISA*01*0000000000*01*0000000000*ZZ*ABCDEFGHIJKLMNO*ZZ*123456789012345*101127*1719*U*00400*000003438*0*P*>
    GS*FA*999999999*4405197800*20111206*1100*1*X*004010VICS
        ST*997*0001
            AK1*PO*1421
            AK9*A*1*1*1
        SE*4*0001
    GE*1*1
IEA*1*000000001

We generate control numbers for each of the X12 envelopes. All of these numbers are unique for the specific sender/receiver ID combination.

Note

The control numbers that we generate are also unique across AWS account and AWS Region.

  • Interchange Control Number. For the ISA envelope, we generate an interchange control number that is unique for the sender and receiver ID. For example, the first acknowledgement sent between sender SEND01 and RECV01 has an ICN of 001. The next interchange between this sender and receiver gets an ICN of 002, and so on.

    Note

    Specifically, this number is unique for the ISA05 and ISA06 (sender) & ISA07 and ISA08 (receiver) combination.

  • Functional Group Control Number. For the GS (functional group) envelope, we generate a functional group control number that is unique for the receiver and the group. The GS01 element is the functional identifier code, which is often a reference to a particular department or division within a company.

    Note

    Specifically, the functional group control number is unique for the GS01 (functional identifier code) & GS02 (sender) & GS03 (receiver) combination.

  • Transaction Set Control Number. For ST (transactional level) envelope, the transaction set control number is unique to the functional group in which the transaction is contained.