Production Order Created Without a Routing

Planning or shop floor reports that a production order 'has no steps' or 'nobody knows what work centre to confirm against'. Sometimes it surfaces as costing complaining there is no operation to cost, or as capacity planning showing the order simply does not appear in the work centre load, because there is no operation to load it against. Confirmation staff say the order will not let them post a yield because there is nothing in the operation overview to confirm. Occasionally the order does get created but with a single generic operation that clearly does not match what is actually done on the shop floor, and the team assumes 'the system picked the wrong routing' when in fact it picked none and defaulted.

Pull an order list report filtered by material and plant for a date range spanning the suspected break, and check the operation count column; orders with zero operations or a single generic operation cluster tightly around the date a routing status or validity change went live, which points straight at the change rather than a random data quality issue. Cross-checking that date against the routing's change history in CA03 usually confirms the exact transport or manual edit responsible.

If no routing exists, this is a master data gap, not a config problem: create and release the routing in CA01, or extend an existing one to the missing plant, and reprocess or manually reassign the routing to the stuck order. If the routing exists but is unreleased, unauthorized for production usage, or outside its validity window, correcting the status, usage indicator, or dates in CA02 is a data fix and does not require transport, though it should still go through whatever change control the site uses for master data. If the production version points to a stale or deleted routing group and counter, correct the production version's routing reference; this is also a data fix. If the real cause is selection logic, an ambiguous priority between overlapping routings, or a mismatched task list type sequence, that lives in the order type dependent parameters and is genuine customizing, which needs to move through a transport and cannot be corrected order by order. Orders already created without a routing before the fix need their operations rebuilt or the order deleted and recreated once the routing is fixed, since simply changing the routing afterward does not retroactively populate operations on an order that already exists.

The reflex fix is to open the stuck order in CO02 and manually type in operations, work centre, and standard values by hand to get the shop floor moving. This clears the immediate blockage but leaves the routing selection problem untouched, so every subsequent order for that material fails the same way. It also breaks the link between the order and the released routing used for standard cost estimates, so cost comparison and variance analysis on that order will not reconcile against the plan, and nobody remembers six months later why that one order's costing looks wrong.

Routing master data and its usage, status, and validity settings belong to production planning master data maintenance; the order type dependent parameters and selection ID logic belong to PP configuration. The handover note should name the material, plant, routing group and counter, the order numbers affected, the exact date orders started failing, and whether the fix requires a data correction only or a transported configuration change.