Working the exceptions queue

Operations → Exceptions is the one list of every order blocked on a human decision. Nothing is hidden to look tidy: if an order can't move forward, an exception says so, with the stage and the reason.

This article covers what to do when an order stops. For the ordinary path through review, follow review an order and send it.

What lands here

Exceptions are generated automatically from order state:

Needs a supplier code (unresolved_mapping) — lines that couldn't be matched to the supplier's item codes. This includes every line from a scanned PDF: with no text layer to verify the numbers against, scanned-PDF orders are always routed to human review rather than delivered blind.
Parse failed — the source file couldn't be read into an order.
Transform failed — generating the supplier's output failed.
Delivery failed — sending to the supplier failed; the attempt's error is captured.
Rejected by supplier — the supplier's system returned the order after delivery.
Dead-lettered (critical) — automatic delivery retries are exhausted.

Resolve vs Ignore — what they really do

The exception list mirrors reality; it doesn't replace it:

The real fix is fixing the order. Open the blocked order, resolve the cause (enter the code, correct the mapping, set up delivery), and the exception clears itself on the next pipeline touch.
Resolve marks the row done — but if the underlying problem still exists, a fresh exception reopens so the problem stays visible. You can't make a broken order look healthy by clicking Resolve.
Ignore is a deliberate dismissal: an ignored exception is never reopened and never nags again for the same cause. Use it for things you've decided not to act on.

Delivery failures, retries, and dead-letter

A failed delivery is retried automatically — 3 attempts in total — and then the order moves to Dead-lettered, with each attempt's error and response code kept in the audit trail.

Dead-lettered orders can't be retried from the order screen (that path is deliberately closed once retries are exhausted). Instead, go to Operations → Health, find the order in the dead-letter table, fix the cause (usually the delivery config or the supplier endpoint), and Requeue. Requeue re-sends the order's latest generated output.

One caveat to keep front of mind: a successful delivery means the supplier's endpoint answered — HTTP 200 is not business acceptance. A delivered order can still come back as Rejected by supplier; that creates its own exception.

When we don't know whether it arrived

On some delivery channels — email and the ERP integrations — there's no reliable way to tell a repeat delivery apart from a first one. If we lose the connection partway through sending, before hearing back from the other side, we genuinely don't know whether the order got there.

We could just retry, the way a failed delivery does. We don't, on purpose: on those channels a retry can land as a second, genuine purchase order, and a supplier who acts on a duplicate is worse than an order that waits an extra few minutes for a person to look at it. So instead of guessing, the order goes to Delivery unknown and stops there for you to decide.

From the order page you get two ways to resolve it:

Send again — use this once you've confirmed with the supplier that they never received it (or you've decided the duplicate risk is acceptable). It delivers the order exactly as before.
Mark as delivered — use this once you've confirmed the supplier already has it. This closes the order out without sending anything further.

Checking with the supplier first is the fastest way to know which one is right — that's the whole reason we ask instead of picking for you.

SFTP, FTPS, and HTTP deliveries don't have this problem the same way: an SFTP/FTPS retry overwrites the same file rather than creating a second one, and HTTP deliveries carry a marker a well-built endpoint can use to recognize a repeat — so those channels retry automatically and never wait on you like this.

"Is it slow, or is it dead?"

When an order sits in Parsing or Sending longer than feels right, check Operations → Health before re-uploading:

the worker banner shows whether the background worker is alive — an offline worker stalls every upload in the workspace, and no amount of re-uploading helps;
the count tiles show orders stuck past the threshold, failed transforms/deliveries, and dead-letters, and link to the affected orders;
counts refresh automatically every 45 seconds.

Escalating to support

If the cause isn't visible from the order page or Health, email support@proculink.eu with the PO number, the order's status, and roughly when it got stuck — that's enough for us to trace it in the audit trail.