Trace why an order exists

A planning run proposes an order for 1,656 of a component nobody has ordered. Before you buy it, you want to know who asked for it.

That's the question pegging answers. It takes one suggestion and walks back down the chain of demand that produced it, until it reaches the thing a person actually committed to — a customer order, a forecast, a line on the master production schedule, or a build one level up that consumes this item.

It's the fastest way to sanity-check a suggestion, and the first place to look when a number seems too large, too early, or unexplained.

Before you begin

• A completed planning run with planned orders in it. Pegging is recorded while the run calculates, so it belongs to the run you have selected — see Run a planning cycle.
• Permission to view planning — the MRP Planning group in Roles & Permissions.
• Tracing changes nothing. It reads the run and opens documents.

Steps

1. Go to Manufacturing → Planning → Workbench and select the run you want to question in MRP Run.

2. Find the planned order. The search box matches SKU, product name and id, and the Supply Type, State, Warehouse and Date filters narrow the table — see Read the time-phased plan.

3. In the Actions column at the end of the row, click the branch icon — Why this order? (Pegging).

   You can also reach it from the time-phased view: open a bucket's detail and use the Trace button on any row of Supplies in this bucket. The drawer closes and the trace opens on that order.

4. Wait for the trace to resolve.

   note

   The first trace you open in a session can take several seconds, and shows only a spinner while it works. That's the plan walking the chain and resolving each reference into a document you can open — not a screen that has hung.

5. Read the trace. The dialog is headed with the order you asked about — its SKU, product name, quantity and due date — and the table under it holds one row per demand, with Level, Demand Type, Demand Product, Reference and Quantity.

6. Follow a Reference to open the document behind it. The dialog closes when you do, so reopen it from the Workbench if you want to keep going up the chain.

How to read the chain

The trace is bottom-up. The first rows are the demands sitting directly on the order you asked about. The rows after them are the demands on the orders above it, step by step, until the chain reaches demand that nothing else caused.

Level is how deep in your product structures each demand landed — the same number as the LLC column on the Workbench. L0 is a finished item that somebody ordered or forecast; a higher number is a component that far down a recipe. In a multi-level trace the levels count down as you read, which is the chain climbing from your component toward the finished product that needs it.

Demand Product is the item the demand landed on. On a dependent row that's the component itself, because the parent build is what put the demand there.

Quantity is the demand, not a share of the order. The quantities can total less than the planned order's Qty, because lot sizing rounds an order up past what the demand asked for. That gap is the rule, and the Planned Orders table shows it directly.

The four kinds of demand

Demand Type	What caused the order	What the reference opens
Sales Order	A customer ordered the item.	The sales order.
Forecast	Forecast demand, included because the run was started with Include forecast demand switched on.	Nothing — a forecast has no document.
MPS	A line on the master production schedule: something you committed to building that no customer order carries yet.	The master production schedule.
Dependent Demand	A build one level up consumes this item.	The parent planned order, back on the Workbench.

note

A forecast row has no source document, so its reference is informational rather than a link. When a trace contains rows like that, a line under the table says how many, and why. Nothing is missing — there's no record to open.

Dependent demand, and why components almost always show it

For a finished product, the trace usually ends immediately: a customer ordered it, and that's the whole answer.

Components behave differently. Nobody orders a component — a run plans it because it planned a build of something else first, and that build consumes it. That's Dependent Demand, and it's the common case for anything below the top level.

A dependent row names its cause as a planned order. Following it returns you to the Workbench with that order found for you, its run already selected and the table searched down to its id. Clear the search when you want the full plan back.

From there, open Why this order? (Pegging) on the parent and the trace continues one level higher. Repeating that walks the chain to the customer order, forecast or schedule entry at the top of it.

This is also how you answer the awkward version of the question: if this customer order goes away, what stops being needed? Walk down from the order instead, using the time-phased plan for each level.

When the trace is capped

A wide plan can hang a great many demands off a single order. Rather than listing all of them, the trace lists what's readable and then says what it left out — "and 12 more demands not shown" at the foot of the table.

Treat that as a complete answer to "what kind of demand caused this?" and an incomplete one to "which specific documents?". For the full picture, open the time-phased plan for the item and drill into the bucket, where the demands are listed alongside the supplies that cover them.

When there is nothing to trace

The trace can come back with No pegging data, and the message "No upstream demand could be traced for this planned order."

The usual reasons:

• The order carries no demand of its own because a later run replaced the chain around it. Traces belong to the run that produced them, so check you have the right run selected.
• The order was firmed in an earlier run and carried forward into this one. A firm order survives a re-run by design — that's the point of firming — but the trace belongs to the run that first worked it out. See Planned, firm and released.
• No demand caused it. An order raised to bring stock back up to its Safety Stock floor, or to its Reorder Point, is covering a level you set rather than a document somebody raised, so there's nothing on the other end to name.

An order you can't explain and don't want is safe to discard: dismissing it deletes the suggestion and nothing else, and it comes back on the next run if the demand underneath it is real.

Next steps

• Read the time-phased plan — the period-by-period view behind the same order
• How a planning run works — where dependent demand comes from, and why components are planned last
• Work the exceptions inbox — the run's own list of what needs a decision
• Carry out planned orders — releasing the suggestions you've satisfied yourself about