# EDI Transactions EDI Transactions is a searchable log of every X12 interchange processed by Tediware -- both inbound and outbound. Use it to look up specific transmissions, verify delivery, or troubleshoot processing issues. ## What are EDI Transactions? Each time Tediware processes an EDI interchange, a transaction record is created automatically. Records capture key details from the ISA, GS, and ST headers: the sender and receiver identifiers, control numbers, transaction set type (e.g., 810, 856, 204), and whether the document was inbound or outbound. Transaction records are created for both directions: - **Inbound** -- EDI files received from a trading partner via SFTP, AS2, or sandbox - **Outbound** -- EDI files generated by Tediware and delivered to a trading partner ## Searching Transactions The filter bar at the top of the page combines a free-text search with a row of filters. The search box matches partial text against the sender ID, receiver ID, interchange control number, trace ID, and transaction ID. Type a value and press Enter or click **Search**. The filters beside it narrow the list further: - **Direction** -- Inbound or Outbound - **Trans set** -- the transaction set code (e.g., 810, 204) - **Status** -- Delivered or Errored - **997** -- the acknowledgment state (see the 997 Acknowledgments section below) - **Flow** -- documents processed by a given flow, including its earlier versions - **Date** -- a recency window, from the last hour to the last 45 days Filters apply as soon as you pick them. Active filters appear as badges below the bar; click the X on a badge to remove that filter. Results are paginated. Use the navigation controls at the bottom of the page to move between pages. ## Transaction List The transaction list displays the following columns: - **ID** -- a truncated identifier. Click it to open the transaction detail panel. - **Direction** -- Inbound or Outbound - **Transaction Set** -- the X12 transaction set identifier (e.g., 810, 204) - **Sender** -- the sender's interchange ID, prefixed with its qualifier - **Receiver** -- the receiver's interchange ID, prefixed with its qualifier - **ICN** -- the Interchange Control Number - **Flow** -- the flow that processed the document, if any - **Status** -- Delivered or Errored - **997** -- the 997 acknowledgment state for outbound documents (see below) - **Created At** -- when the transaction was recorded On smaller screens, some columns collapse into an expanded row below each entry. ## 997 Acknowledgments When a partner has 997 tracking turned on, the **997** column shows where each outbound document stands with that partner. You turn tracking on or off per partner with **Track 997 acknowledgments for outbound** on the partner's Configuration card (see [Partners](partners.md)). The column shows one of: - **Awaiting 997** -- you sent the document and the partner has not answered with a 997 yet. - **Accepted** -- the partner's 997 accepted the document. - **Rejected** -- the partner's 997 reported a problem with it. Open the transaction and its trace to see the returned 997. - **-** -- no acknowledgment is expected. This is the case for inbound documents, for 997s and 999s themselves, for documents sent to partners with tracking turned off, and for documents sent before 997 tracking existed. Use the **997** filter to narrow the list to one state: **Awaiting 997**, **Acknowledged** (accepted or rejected), **997 accepted**, or **997 rejected**. A 997 is an envelope-layer acknowledgment: it tells you the partner received your interchange and it parsed. It does not confirm that your partner's business system acted on the document. ## Transaction Details Click a transaction ID to open the detail panel. The panel shows: - **ID** -- the full transaction identifier - **Trace ID** -- the processing trace GUID, with a link to the trace view - **Created** -- timestamp - **Direction** -- Inbound or Outbound - **Interchange Control Number** -- from the ISA header - **Group Control Number** -- from the GS header - **Transaction Set Control Number** -- from the ST header - **Transaction Set Identifier** -- the document type code - **Sender** -- qualifier and identifier - **Receiver** -- qualifier and identifier ### Artifacts The **Artifacts** section shows the data that came in and what we sent out -- the input payload from the trading partner (or the source flow) and the output payload that was actually delivered. Each card is format-aware: X12 envelopes render as raw text, JSON renders as pretty-printed JSON. Use the Trace Viewer link on a card to open the full trace at the producing node, where you can also see intermediate-stage payloads and node-by-node logs. ### Associated Logs Log entries generated during the processing of this transaction appear in the **Associated Logs** section. These are useful for diagnosing errors or understanding what happened during processing. ### AS2 Delivery If the transaction was sent or received via AS2, an **AS2 Delivery** section lists the underlying AS2 message(s). For each message you can see the direction, current status, filename and size, and (for inbound) the MDN disposition that Tediware sent back, or (for outbound) the MDN your partner returned. When the signed MDN envelope is still on file, a **Download MDN** button is shown. The MDN is the cryptographic proof of delivery; download and archive it if your compliance process requires it. The download remains available for the AS2 message's full retention window (see [Data Retention](data-retention.md) for details). ## Resending an Outbound Transaction For outbound transactions, the detail panel header includes a **Resend** button. Resend delivers the same document to your partner again, exactly as it was originally sent. It re-uploads the stored EDI byte for byte, keeping the original control numbers from the ISA, GS, and ST headers. Tediware does not rebuild the document, so what your partner receives is identical to the first delivery, down to the control numbers. ### When to use it Resend a transaction when the original delivery did not reach your partner. Common cases: - You did not receive an acknowledgment (997, 999, etc.) for the document. - Your partner says they never received the document. - The original delivery failed, for example because the partner's server was unreachable at the time. Because the resend carries the original control numbers, a partner that never received the first copy processes it as the document they were expecting. ### What Resend does not do - It does not create a new transaction, so you are not billed again. The resend is the same transaction. - It does not change or regenerate the EDI. Even if the mapping or implementation has changed since the original send, Resend delivers the original bytes. - The new delivery and its logs land on this same transaction's history. Confirm the outcome in the **Associated Logs** section and the trace, rather than looking for a separate record. ### Duplicate handling Because the resent document carries the same control numbers as the original, a partner that already received the first copy will usually recognize the resend as a duplicate and ignore it. This is how most partners avoid processing the same document twice. Some partners instead reject a repeated or out-of-order control number, so whether a resend is accepted depends on the partner. If you are unsure, check with your partner before resending. ### When Resend is unavailable The **Resend** button appears only when the transaction can be resent. It is hidden when: - The transaction is inbound. Only outbound transactions you sent can be resent. - The original content is no longer stored. Tediware keeps the delivered document for 45 days (see [Data Retention](data-retention.md)). After that the transaction record remains, but the exact bytes are gone, so there is nothing to resend. - The transaction is an acknowledgment, such as a 997. Acknowledgments are generated and sent automatically as part of inbound processing, so they are not resent from here. After you confirm, Tediware starts the resend in the background and shows "Resend started". The delivery finishes a moment later; refresh the transaction to see the new delivery in its logs and trace. ## Tracing a Transaction Every transaction is linked to a trace GUID that follows the document through the entire processing pipeline -- from ingestion through transformation to delivery. Click **View Trace** in the transaction detail panel to see the full trace, including every node the document passed through and the result at each step.