Working the issues queue

Operations → Issues 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 issue says so, with the step it stopped at and the reason. (The API calls these rows exceptions; the screen calls them issues.)

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

Issues are generated automatically from order state. Each one is named here exactly as the order screen and the inbox name it, so the word you read in this list is the word you look for on the order:

Needs supplier — the file was read, but we can't tell which supplier the order is for. Assign one and it carries on. Nothing else can be fixed until this is.
Needs review — one or more lines have no supplier item code yet. This includes every line from a scanned PDF: with no text layer to verify the numbers against, scanned-PDF orders always go to a human rather than being delivered blind.
Couldn't read file — the source file couldn't be turned into an order at all. There is nothing to correct in place; upload a corrected file as a new order.
Couldn't build output — the supplier's file couldn't be produced, so nothing was sent. Several different things land here: the output settings or field mapping, a line still missing its supplier item code, an acceptance profile of your own turning the order down (setting one up is Enterprise plan and up; ProcuLink's built-in checks need no profile and run on every plan), or something going wrong at our end. Open the order — where we can tell which one it was, the panel names it and what fixes it. Where we can't, it says so and shows you the message we got back rather than guessing.
Couldn't send — the order and its output file are both fine; the send itself didn't get through. The attempt's error and response code are kept on the order.
Delivery unknown — we sent it, then lost the connection before hearing back, so we can't say whether it arrived. Not a failure: it waits for you (see below).
Supplier rejected — the supplier's system read the order and refused it, after delivery.
Out of retries (critical) — the automatic delivery attempts are spent and nothing more happens on its own.

Resolve vs Ignore — what they really do

The issues 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 issue clears itself the next time the order moves.
Resolve marks the row done — but if the underlying problem still exists, a fresh issue 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 issue is never reopened and never nags again for the same cause. Use it for things you've decided not to act on.

Delivery failures and retries

A Couldn't send order is retried automatically — 3 attempts in total — and then it moves to Out of retries, with each attempt's error and response code kept in the audit trail for that order.

Once retries are exhausted, nothing more happens on its own. Open the order: the panel there explains what happened and carries Start sending again, which puts the order back in the sending queue. Check the supplier's delivery settings first — if nothing has changed at their end, it will fail the same way. The same action is available in bulk from Operations → System status, in the table of orders we couldn't deliver.

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 Supplier rejected; that opens an issue of its own.

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.

The order page asks you one question first — what did the supplier say? — and only then offers the matching action. There is deliberately no one-click re-send here:

They don't have it → Send it to them again, which delivers the order exactly as before. Use this once you've confirmed nothing arrived (or you've decided the duplicate risk is acceptable).
They have it already → Mark it as delivered, which closes the order out without sending anything further.
I haven't been able to reach them yet → no send is offered at all. The order stays exactly where it is until you know.

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 Extracting 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 orders we've stopped retrying, and each tile links to exactly those 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 for that order.