Work the exceptions inbox

A planning run across a few hundred items can hand back a few thousand planned orders. Every one of them is correct, and reading every one of them is not a way to spend a morning. A plan is only useful if it tells you what to do.

Exception Messages is that list. It's the planner's inbox: the handful of things in this run that the engine could not resolve on its own — supply that can no longer arrive in time, a period the plan leaves short, an item it couldn't explode — with the worst at the top and a decision attached to each one.

Nothing on this page changes an order. Accepting and dismissing are how you record what you've dealt with, so the list shrinks to the work that's left. The orders themselves are firmed, edited and carried out on the Workbench.

Before you begin

• A finished run. The inbox reads one run at a time, and its messages are written when that run finishes. See Run a planning cycle.
• Access to the Planning pages. Accepting or dismissing needs permission to change the plan as well — both live under MRP Planning in Roles & Permissions.
• Worth knowing first: every run rebuilds its own messages from scratch. A message belongs to the run that raised it, and re-running the plan produces a fresh set.

Steps

1. Go to Manufacturing → Planning, then click Exceptions in the button bar that runs across the Planning pages.

2. Check the run header. The MRP Run selector names the run you're reading, alongside its Status, its Planned orders count and its Horizon. Switching runs reloads everything below it.

3. Read the counts across the top before touching the list. Emergency is the figure that decides whether this is a five-minute pass or an afternoon.

4. Work down the table. It opens worst-first, so the fires are already at the top — you don't have to sort anything to find them.

5. On a row you want to look into, right-click it for View Product and, where the message is about a planned order, View Planned Order — which opens that order on the Workbench.

6. Decide, one row at a time or in bulk:

   • Accept (the tick) — you've dealt with it, or you're about to.
   • Dismiss (the cross) — you've looked and you're choosing to live with it.

   To act on several at once, tick the rows and use Accept or Dismiss in the bar that appears above the table.

What the default view is showing

The page deliberately opens narrowed, with two filter chips already applied: Status: is Open and Class: is Exception.

That second one is doing most of the work. Every planned order in the run raises a Release action — a 4,000-order plan raises 4,000 of them — and each duplicates a row the Workbench already shows. Left unfiltered, the few rows that need a decision would be buried in them. The Class filter hides them, and because it's an ordinary chip you can remove, the releases are one click away whenever you want the full list.

The count chips

Four cards summarise the run by severity — Total, Emergency, Exception, Attention — with a row of type chips underneath, such as "Release: 27" or "Compression: 7". Only types that actually occur in the run get a chip, so the row is a quick census of what this plan went wrong on.

Every figure is clickable and filters the list below it.

note

The figures count every message in the run, including the Release action raised for each planned order and anything already accepted or dismissed. The table below them is filtered. The note under the chips says so on screen: "Counts cover every message in this run — including the Release action raised for each planned order, and messages already accepted or dismissed. Click any figure to filter the list below."

So an Attention card reading 4,000 above a table showing 6 rows is not a fault — it's the whole-run figure above your filtered working set.

Clicking a card or a chip drops the Class: Exception default, because the Attention and Release figures count nothing but action-class rows and would otherwise land you on an empty grid. The Status: Open default is kept — that's your working set, and accepted or dismissed rows reappearing underneath you would undo the triage you have done.

The messages table

Ten columns show by default, and Columns offers three more (ID, Class and Raised, the timestamp of the run that wrote the message).

Column	What it tells you
Type	What the run is asking for or warning about. The six types are in Action and exception messages.
Severity	Emergency, Exception or Attention
Status	Open, Accepted or Dismissed
Product	The item the message is about, linked to it
Warehouse	The location it was raised against. Blank when the message is about the item everywhere, such as a missing recipe
Current Qty	The quantity as the plan stands today — the order quantity, or the projected balance for a shortage
Current Due	The date as the plan stands today: the order's due date, or the period a shortage falls in
Recommended Qty	The quantity the run suggests instead
Recommended Due	The date the run suggests instead
Days Late	How many days late the supply is, or how many days of lead time the plan has had to make up

Blank cells are meaningful: a message that isn't about a quantity leaves the quantity columns empty rather than inventing a zero.

Above the table sit the usual controls — search by SKU, product, warehouse or ID, filter chips for Type, Severity, Status, Class, Warehouse and a date range, advanced filters, and saved views for a combination you come back to.

Severity ordering

With nobody asking for a particular order, the list sorts by severity, worst first, so the fires float to the top: Emergency, then Exception, then Attention.

That order is also what the Severity column sorts by when you click it — urgency, never alphabetical. Sorted by name, "Attention" would outrank "Emergency" on the one column the page exists to triage by.

Accepting a message

Accept is you taking responsibility for the message: you've placed the order, adjusted the date, or decided the shortage is already being handled elsewhere.

It applies straight away and confirms what happened — "1 action message accepted". There's no second step, because accepting is reversible in the only sense that matters: nothing was changed, and the next run raises the message again if the underlying problem is still there.

Accepting also clears any standing dismissal you'd previously recorded for the same problem. You acted on it rather than choosing to live with it, so a recurrence is news again.

Dismissing a message

Dismiss is the opposite decision: you've looked, and this one isn't worth acting on. A discontinued item below its safety stock, a component you know a supplier is already expediting.

Dismissing asks you to confirm first, in a Dismiss Message dialog, because it's the one action here that outlives the run:

Are you sure you want to dismiss this exception message?

The same exception stays dismissed on future MRP runs until it gets materially worse, or for 90 days.

caution

A dismissal is a standing decision, not a one-off. The same problem — that exception type, on that item, at that location — opens as Dismissed in every later run for 90 days, so it never reaches your open list again in that window.

Two things keep that from becoming a blind spot. The suppression expires, so a decision taken once can be reconsidered. And it's measured as well as remembered: a recurrence that's materially worse than the version you waved through is raised as Open again, so a shortage of 40 you dismissed does not silently hide a shortage of 400 next month.

Release actions carry no such suppression and are never silenced across runs — they're work you still have to do, not noise.

An accepted message leaves the view

This surprises people the first time, so it's worth saying plainly: the inbox opens on Status: Open. Accept a message and the row disappears from the list.

Nothing was deleted. The message is still on the run with its status changed, and the count chips — which cover the whole run — don't move. That's the point of the default: the list is the work that's left, and clearing a row is what progress looks like.

To find it again, change the Status filter to Accepted (or Dismissed, or All). The row is there with its new status chip, and you can accept or dismiss it the other way if you changed your mind.

If a filter combination returns nothing, the empty state names the filters back to you — "Nothing in this run matches Status: Dismissed · Class: Exception" — with a Clear filters button, so an empty grid is never ambiguous about why.

Exporting the list

Export hands the inbox to someone who doesn't work in SKU.io — a supplier chasing list, a production meeting, a record of what the plan looked like on the day.

Choose the file format (XLSX (Excel) or CSV) and what to include: all records, the filtered results, the current page, or the rows you've selected. Everything except "all records" carries the filters, sort and columns you have on screen, so the file matches what you were looking at.

The export needs a run selected — the button says so in a tooltip when it's unavailable. Columns are Type, Severity, Status, Product, SKU, Warehouse, Current Qty, Current Due Date, Recommended Qty, Recommended Due Date and Days Late.

note

A very large spreadsheet is refused rather than half-built, with a message pointing you at CSV, which has no size limit. That's the export protecting you from a truncated file, not an error to work around.

Next steps

• Action and exception messages — the six types, what raises each one, and what to do about it
• How a planning run works — why a start date can land in the past in the first place
• Carry out planned orders — turning the suggestions you accepted into real orders
• Firm and pin a planned order — holding a quantity or date the engine shouldn't move