Working with documents

How EDI documents look and behave inside EDISQ: the transaction list, the document detail view, error flagging that names the exact segment, and reprocessing.

Everything you trade lives under Transactions in the app — one list, both directions, filterable by partner, document type, and status.

The transaction list

Each row is one document: its type (850, 855, 856, 810, and the rest), the partner, direction, status, and the PO number it belongs to. Test documents are badged so sandbox traffic never blends into production. Filters get you from "everything" to "unacknowledged invoices for one retailer" in two clicks.

The document detail

Open any document and you get the full picture:

• The business view — PO number, partner, direction, status, and the document's place in its order's story.
• The raw X12 — every segment, downloadable as a .edi file when a partner's support team asks for "the actual file."
• Errors that point at the line. When a document fails validation, the error names the segment it's about — a bad MAN barcode, a totals mismatch in TDS, a broken line item in PO1 — and the raw view flags that exact line. No decoding an error code against a PDF.

Fixing and reprocessing

A document that fails or needs attention keeps its place in the list with a status badge and a one-line summary of what's wrong. Fix the cause — a missing item cross-reference, a corrected quantity — and hit Reprocess. The document runs the full pipeline again; nothing is retransmitted until it validates.

The sandbox is the same screens

Sandbox documents flow through the identical list and detail views — the only difference is the test badge and that nothing leaves the building. You can generate inbound test documents (an 850 order, an 860 change, an 852 sell-through, and more) on demand from the Sandbox page, then practice the whole respond–ship–invoice cycle before a real retailer is on the other end.