Infor SyteLine5 min readNetray Engineering TeamUpdated March 4, 2025

When SyteLine MRP Is Not Generating Planned Orders

When SyteLine MRP is not generating planned orders, the cause is almost always one of five things: the item is not flagged as MRP planned, demand falls outside the planning horizon or cutoff date, existing supply already covers net requirements, the order policy suppresses small quantities, or the planning run itself failed or ran against the wrong site. Planners often escalate this as an MRP bug, but a genuine engine defect is rare. This guide walks the checks in the order that resolves the most cases fastest, using the Items form planning tab, planning parameters, and background task history.

Confirm the Item Is Actually MRP Planned in This Site

Open the Items form and review the planning tab for the specific item and site combination. SyteLine is multi-site, and an item planned correctly at one site can be inert at another because the site-level item record was copied without planning attributes. Verify the item is flagged for material planning, has a valid planner code, a non-zero lead time, and a controlling order policy. Items set to a manual or none planning method are deliberately excluded from the run. Also confirm the item is not a phantom or reference-only component, because phantoms are blown through to their parents rather than planned independently, which frequently surprises planners who expect a planned order for a subassembly.

Check the planning flags on the Items form for the exact site, not just the primary site
Confirm planner code, lead time, and order policy are populated and non-zero
Verify the item is not configured as a phantom that gets blown through to the parent
Check that the item has a current, approved BOM and routing if it is a make item

Check Planning Horizon, Cutoff Dates, and Demand Visibility

MRP only plans what it can see. If the demand date sits beyond the planning horizon configured in planning parameters, no planned order will appear regardless of item setup. Conversely, demand inside the item lead time may be treated as past due and reported as an exception rather than generating a normal planned order. Confirm the customer order lines, forecast records, and dependent demand are actually netted into the run: forecast consumption rules, blanket release schedules, and orders held in an unreleased or credit-hold status can silently remove demand. In multi-site environments verify that transfer demand from a receiving site is being pushed to the supplying site through the correct planning relationship.

Order Policy, Minimums, and Existing Supply

Net requirements have to exceed the coverage already in place before MRP will create anything. Add up on-hand quantity, open purchase orders, open jobs, in-transit transfers, and firm planned orders for the horizon in question. If safety stock is already satisfied and net requirement is negative, MRP is behaving correctly. Order policy compounds this: a period supply or days supply policy will roll several requirements into a single earlier order that a planner scanning a specific week can easily miss. Order minimums and multiples will similarly consolidate demand into fewer, larger orders. Review the planning detail for the item across the full horizon rather than one bucket before concluding nothing was generated.

Sum on-hand, open POs, open jobs, and in-transit transfers before declaring a shortage
Check whether a days-supply or period-supply order policy consolidated demand into an earlier order
Verify order minimum, multiple, and maximum values are not suppressing small net requirements
Review planning detail across the entire horizon instead of a single weekly bucket

Verify the Planning Run Itself Actually Completed

A surprising number of missing planned order tickets trace back to a planning run that never finished. Open Background Task History and confirm the most recent MRP or planning job reached a completed status rather than errored, still running, or waiting. Look for aborted runs caused by SQL timeouts, deadlocks with posting routines, or a full transaction log during a long regeneration. Confirm the run was net change versus full regeneration as expected: net change will skip items whose demand did not change since the last run, so a parameter edited outside the planning tables may not trigger replanning. Also verify the run targeted the correct site and that another scheduled run did not overwrite results afterward.

How Netray AI Agents Diagnose SyteLine Planning Gaps

Netray planning agents run a nightly reconciliation across SyteLine demand, supply, and item planning attributes, then flag every item where demand exists but no supply was generated, with the specific reason attached: not MRP planned, outside horizon, covered by existing supply, or suppressed by order policy. Instead of a planner spot-checking a few escalated part numbers, the agent evaluates the entire item master every night. Manufacturers running this typically cut planner investigation time by 60-70 percent and catch parameter drift, such as lead times left at zero after a mass item load, within a day rather than at the next shortage meeting.

Frequently Asked Questions

Why does SyteLine MRP show a shortage but no planned order?

A shortage exception with no planned order usually means the item is not flagged for material planning at that site, or the requirement falls inside the item lead time so MRP reports it as past due rather than creating a normally scheduled order. Check the planning flags on the Items form for the specific site, then compare the demand date against today plus lead time. Both conditions produce exception messages without generating supply.

Does SyteLine net change MRP miss items after a parameter change?

Yes, this is a common surprise. Net change planning only reprocesses items whose demand or supply changed since the last run. If you edit an item planning attribute such as safety stock, lead time, or order multiple, the item may not be marked for reprocessing. Run a full regeneration after any bulk parameter update, or verify your version marks item attribute changes as a planning trigger before relying on net change.

How do I confirm a SyteLine MRP run finished successfully?

Open Background Task History and locate the planning task. Confirm the status is completed rather than errored, running, or waiting, and check the start and end timestamps against your expected duration. Review the task output or log for SQL timeout, deadlock, or transaction log full messages. A run that aborts partway through can leave partial planning results that look like MRP simply skipped a subset of items.

Key Takeaways

1Confirm the Item Is Actually MRP Planned in This Site: Open the Items form and review the planning tab for the specific item and site combination. SyteLine is multi-site, and an item planned correctly at one site can be inert at another because the site-level item record was copied without planning attributes.
2Check Planning Horizon, Cutoff Dates, and Demand Visibility: MRP only plans what it can see. If the demand date sits beyond the planning horizon configured in planning parameters, no planned order will appear regardless of item setup.
3Order Policy, Minimums, and Existing Supply: Net requirements have to exceed the coverage already in place before MRP will create anything. Add up on-hand quantity, open purchase orders, open jobs, in-transit transfers, and firm planned orders for the horizon in question.