> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stateset.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Orders, Reviewed Sends, and Recovery

> Prepare 855, 856, and 810 responses from current order evidence and recover uncertain sends with their original request identity.

**Orders** joins accepted POs with source documents, quantities, transport, functional
acknowledgments, and downstream observations. Scope by **partner and PO number**: business
references can repeat. Document presence alone does not establish shipment or payment.

## Prepare the response

| Document | Review |
| - | - |
| 855 | Per-line accept, reject, and backorder commitments and quantities |
| 856 | Remaining quantities, shipment/date, carrier, cartons, and printed SSCCs |
| 810 | Invoice identity/date, quantities, decimal prices, allowances, and total |

The console supports partial quantities and split cartons. Allocate/download labels, then
use those same SSCC-18 identities in the ASN. Allocation consumes serials; downloaded ZPL
does not establish physical scanning or retailer acceptance.

The server checks product identity, order state, quantities, invoice identity, numeric
boundaries, and current policy. The configured outbound compliance mode governs blocking.
Review warnings as well as errors.

## Retain the review

Preview at `POST /v1/operations/orders/{partner_id}/{po_number}/preview/{set}` sends no EDI.
It returns the prepared document, findings, revision, and frozen date overrides. Send via
`POST /v1/orders/{po_number}/{set}/{partner_id}` with the captured overrides and:

| Header | Purpose |
| - | - |
| `Idempotency-Key` | Stable identity for this intended document |
| `If-Order-Revision` | Preview revision; atomic acceptance rejects stale order/configuration |

The [CLI](/stateset-edi/cli-and-sdk) retains these in a portable artifact:

```bash theme={null}
./stateset-edi order-preview acme PO-2026-4411 856 \
  --overrides shipment-overrides.json > reviewed-shipment.json
./stateset-edi review-inspect reviewed-shipment.json
# After reviewing destination, quantities, policy, and prepared payload:
./stateset-edi order-send reviewed-shipment.json
```

Inspect `data.passed`, `data.can_send`, and `data.send_blockers` first. Guarded sends require
PostgreSQL; file-backed gateways can preview with `can_send:false`. A review is operation
input with hashes, not a signed authorization grant. Noninteractive `order-send` executes
when invoked, without another prompt.

## Recover the original document

All direct X12/EDIFACT outbound generation routes accept `Idempotency-Key`: 1–128 ASCII
letters, digits, hyphens, underscores, dots, or colons. Malformed keys or keyed requests
without PostgreSQL return 422 before document commitment.

Receipts are scoped to tenant, partner, and transaction route. Successful replay returns
original wire/control numbers without another document, billing unit, event, acknowledgment
tracker, or delivery job. JSON whitespace and object key order do not change identity;
changed JSON with that key returns 409. Control-number gaps remain normal. Without a key,
each successful call can generate another document.

After an uncertain response:

1. Retain original key, payload/review, revision, wire, and available correlation IDs.
2. Inspect partner-scoped order, document, and delivery evidence.
3. Restore access to the same workspace when needed. A later 401/403 does not prove the
   earlier operation rolled back.
4. Explicit retries use the original operation. Do not create another key or preview to
   escape uncertainty. Reconcile first if business intent has changed.
5. Verify returned original wire, then inspect transport and acknowledgment separately.

Committed receipts remain retrievable after configuration changes or production holds,
subject to authorization; retrieval does not initiate delivery. Receipts do not expire
automatically. Retention/deletion must account for their document references and define
retry windows before removing them. External delivery remains at-least-once.

## Console recovery boundary

Source `3f6b5c0` preserves pending sends in the current tab's session storage,
scoped to workspace, partner, and PO. Overrides, key, and revision are saved before dispatch;
storage failure prevents sending. Reload restores the request. **Retry original request**
recovers it; **Refresh order evidence** reads state without generating another document.

After uncertainty or reload, a later rejection does not discard the original identity.
Evidence-refresh failure after successful sending leaves that send accepted. Recovery
requires HTTP 200, X12 content type, and an ISA-prefixed body. Redirects, 202, empty bodies,
and HTML cannot establish recovery; this check does not qualify business content.

> [!NOTE]
>
> The console fixes in `3f6b5c0` were locally qualified with synthetic identity, real
> API/PostgreSQL, and response faults. They are newer than the
> retained production dashboard record. Tab-local session storage is not a server pending-send
> registry. If the session is lost, inspect recorded evidence before preparing another
> shipment or invoice. Integrations need durable storage of their own original requests.

Use [operations](/stateset-edi/operations) for reprocessing, redelivery, queue recovery,
and exception ownership.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.