# 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 any part of a sender or receiver ID, so `LOGIST` finds `ACME-LOGISTICS`. It matches the start of a transaction ID, trace ID, interchange control number, or reference: the eight characters in the ID column find that transaction, and `3218` finds purchase order `32185544`. A whole interchange control number also matches without its leading zeros, so `123` finds `000000123`. Reference matching is case-sensitive. Type a value and press Enter or click **Search**. The filters beside it narrow the list further: - **Partner**: documents exchanged with one trading partner - **Trans set**: the transaction set code (e.g., 810, 204) - **Direction**: Inbound or Outbound Click **More** for the rest: - **Status**: Processing, Delivered or Errored - **Warnings**: documents whose processing raised at least one warning, or documents with none - **Prod/test**: Production or Test, from the interchange's usage indicator (ISA15) - **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. The chart above the list counts the matching transactions per day in your organization's time zone. It leaves out 997s and 999s, since each one answers a document going the other way; turn on **997s** to count them, or filter **Trans set** to 997 or 999. The **Date** filter fades the days before its window rather than removing them. Results are paginated. Use the navigation controls at the bottom of the page to move between pages. ## Transaction List The transaction list shows one line per document, with these columns: - **ID**: a truncated identifier. Click it to open the transaction's page. - **Set**: the X12 transaction set identifier (e.g., 810, 204), after an arrow for the direction (inbound or outbound) and with a **T** badge on a test document - **Partner**: the trading partner, linked to its page - **Reference**: the document's business reference, such as the purchase order number on an 850 or the invoice number on an 810 (see References below) - **Route**: your interchange ID on the left and the partner's on the right, with an arrow showing which way the document went - **ICN**: the Interchange Control Number - **Flow**: the flow that processed the document, if any - **Status**: an icon for Processing, Delivered or Errored, with a **997** badge for outbound documents (see below), a warning count when processing raised any (see Warnings below), and a **Resent** or **Redelivered** badge - **Created**: when the transaction was recorded On smaller screens, each transaction shows as a card instead. ## References Tediware records one business reference per document, read from its beginning segment: ``` 850, 855, 860, 865, 875 purchase order number 810, 880, 210 invoice number 856 shipment identification 204, 214, 990 shipment identification number 812 credit/debit adjustment number 846 reference identification 820 payment trace number 940, 945 depositor order number ``` Other transaction sets show no reference. Healthcare sets are left out on purpose, since their references identify claims and members. An outbound document gets its reference once its EDI is written, and documents processed before references were recorded have none. ## 997 Acknowledgments When a partner has 997 tracking turned on, a **997** badge in the Status 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 badge 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 follow the link beside **Ack** to see the returned 997. No badge appears when no acknowledgment is expected: 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 its page. The heading names the transaction set, and the line under it shows the direction and the status: Delivered, Processing, or Errored with the step that failed. The **Details** section shows: - **Partner** and **Flow**: the partner the document belongs to and the flow that processed it - **Reference**: the document's business reference, when it has one - **Sender** and **Receiver**: qualifier and identifier - **Ack**: on an outbound document, its 997 state with a link to the 997 that answered it. On an inbound document Tediware acknowledged, a link to the 997 it sent. On a 997, a link to the document it acknowledges. - **Created**: timestamp - **ID**: the full transaction identifier - **Interchange Control #**, **Group Control #** and **Trans Set Control #**: from the ISA, GS and ST headers - **Usage indicator**: Production (P) or Test (T), from the ISA15 of the interchange (see Test and Production on the Partners page) - **Trace**: the processing trace GUID, with a **Trace Viewer** link - **Duplicate of**: on an inbound transaction whose sender, interchange control number and usage indicator match one already received, a link to that earlier transaction. The repeat is still processed and acknowledged. ### Payloads The **Payloads** 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. On an errored document, an **At failure** card takes the place of the output. The cards belong to this document. When one processing run produces several documents (an inbound file that carries more than one transaction set, or an inbound document and the 997 Tediware sent back for it), each transaction shows its own payloads rather than everything the run touched. On an automatic 997's page, an extra **Acknowledged document** card shows the partner document the acknowledgment answers. When another document from the same processing run errored, a line under the status says so and links to the Trace Viewer. The document you are looking at keeps its own status, error card, and logs. ### Warnings A warning is something worth reviewing that did not stop delivery. A warning never changes the status. Tediware raises six today: - **Mapping failed**: an inbound mapping failed on the document. It was delivered, so the transaction reads Delivered and any webhook fired, but its output may not be the canonical shape. - **Sender mismatch**: the interchange sender in the ISA is not the interchange id configured on the partner's external envelope. The document was still processed under that partner. Not raised when the partner has no external interchange id configured. - **Usage indicator mismatch**: the interchange's ISA15 is not the usage indicator on the partner's inbound transaction setting for that set, such as a test document for a set that is live. The document was still processed. - **Structural error**: the envelope arithmetic was off, such as an SE segment count that does not match, ST and SE control numbers that differ, or a missing trailer. This is what a 997 reports as accepted with errors noted. The document was still delivered. A group-level problem is carried once, on the group's first document. - **Invalid date**: a date element inside a transaction set that the parser could not read as a date, such as month 13. The element was left out of the translation. Dates in the ISA and GS envelope segments are not checked. - **Non-UTF-8 encoding**: part of the document was not valid UTF-8, so Tediware read those bytes as Windows-1252 (which covers Latin-1) and processed the document as usual. If accented characters come out wrong, ask the partner which character encoding they send. When processing raised any, the transaction shows a count badge beside its status, in the list and on its page. On the page the badge links to the Trace Viewer, which lists each warning on the result that raised it, with a stable code and a sentence saying what happened. The **Warnings** filter on the transactions list finds every document that has one. ### Logs The **Logs** section lists every log from this transaction's processing run, oldest first. The run can include related documents, so a purchase order's page also shows the logs for its 997, and a document that arrived with others in one interchange shows theirs too. Level tabs filter the list, and each log's structured data opens in place. ### 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 transaction page 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. - It does not create a separate record to look at. The new delivery, its logs, and the resend count all land on this same transaction. ### 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 a 997 sent before Tediware started keeping a copy of each acknowledgment it generates. Acknowledgments sent since then can be resent like any other outbound document. After you confirm, Tediware starts the resend in the background and shows "Resend started". The page then updates on its own, usually within a few seconds, so there is nothing to refresh. The **Resend** button stays disabled until it does. ### How to tell a transaction was resent Once the resend finishes, the transaction reads "Resent once, on Aug 19, 2026 at 3:04 PM" (or "Resent 3 times, last on ...") beneath its status, followed by whether anything has errored since that resend. The status reports the latest attempt, so a transaction whose failed delivery you resend successfully reads Delivered, and one whose resend fails again stays Errored. A **Resent** badge also appears with the transaction's status in the transactions list, so you can see at a glance which ones have been resent. Hover it for the count and the time of the last resend. The **Logs** section gains a "Resend of ... requested by ..." line naming whoever triggered it. If the resend could not run (the stored document was cleaned up, or the connection was removed, between your click and the delivery), a warning line there says so. ## Redelivering an Inbound Transaction For inbound transactions, the transaction page header includes a **Redeliver** button. Redeliver delivers the same document to its destination again (your webhook, or a connection), on the same trace. Nothing is re-parsed, so the JSON is unchanged, and no new transaction is created, so nothing is billed again. ### When to use it Redeliver is available whether or not the original delivery failed, since a receiver can lose a document after already accepting it. Common cases: - The original delivery failed, and the retries described under [Webhooks](webhooks.md) did not recover it. - Your endpoint accepted the document but something went wrong on your side afterward. Because a redelivered document carries the same `resultId` as the original, your system can recognize it as a repeat and skip it. A 997 Tediware generated for the document is not re-sent by Redeliver. Resend it from its own transaction page. ### When Redeliver is unavailable The **Redeliver** button is hidden, or the action refused, when: - The transaction is outbound. Use Resend instead. - The original content is no longer stored. Tediware keeps delivered documents for 45 days. - The delivery node, or its target (the webhook or connection), no longer exists. - The document failed before it reached delivery, for example on a mapping. Fix the cause and submit the document again. - The partner is set to polling. There is no delivery to repeat; the result is already on the feed. Once it lands, a redelivered transaction reads "Redelivered once, on ..." (or "Redelivered N times, last on ...") the same way a resent transaction does, and the transactions list shows a **Redelivered** badge in place of **Resent**. The **Logs** section gains a "Redelivery of ... requested by ..." line naming whoever triggered it. ## 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 **Trace Viewer** in the transaction's Details section to see the full trace, including every node the document passed through and the result at each step.