COR1 — Create Process Order

COR1 creates a process order for a material and plant, either from scratch or with reference to an existing order or planned order. On save it determines the master recipe (the process-industry equivalent of a routing) and the BOM, explodes both into operations/phases and components, and assigns a resource (the process-industry equivalent of a work center) to each operation. The structural fact that causes most confusion: process orders are recipe-and-resource driven, not routing-and-work-center driven, and the two worlds look almost identical on screen but resolve master data through different tables and different assignment logic. Consultants coming from discrete manufacturing frequently troubleshoot a process order as if it were a CO01 production order and check the wrong master data entirely.

COR1 is reached for when a process order needs to be created outside the normal planning run, for example a one-off batch, a rework order, or a test order for a new recipe before it goes live in MRP. In steady-state operation, most process orders are not created manually at all; they come from converting a planned order generated by MRP, visible in the stock/requirements list, or from a mass-conversion step in production scheduling. A consultant reaches for COR1 specifically when there is no planned order to convert, when the planning run has not yet picked up a new recipe, or when reproducing an issue interactively to see exactly which recipe and BOM alternative the system selects.

Start from AUFK filtered on the order number and plant to confirm order type and status. Cross-reference AFKO on the same order number to see which material and production version the recipe/BOM explosion actually used, and compare that against the production version master data the planner expected. Pull AFVC for the order to see whether phases and resources came through; an empty or partial AFVC for an order that should have several phases points straight at a recipe assignment problem, not a COR1 usage error. Check RESB against the BOM to confirm every component line exploded.

COR1 still exists as the classic transaction on S/4HANA and remains in day-to-day use; the underlying order header and item tables carry the same core structure. A Fiori app for managing process orders exists as a newer interface option for creation and monitoring, but it does not replace COR1's field-level control over recipe and BOM selection, so consultants still drop back to COR1 for anything requiring manual override of the proposed master data.

Primarily a PP-PI functional problem: recipe assignment, production version, and BOM alternative logic. MM gets involved when component availability or batch determination is the blocker. A clean handover states the order number, the order type, whether creation was manual or by conversion, and which specific screen (recipe selection, component overview, incompletion log) showed the anomaly.

Read CO01 alongside COR1 to understand the discrete-order equivalent and where the two diverge on master data resolution. COR2 and COR3 cover changing and displaying the same order once created, including where the incompletion log and status changes actually get fixed. MD04 is the first stop for confirming whether a planned order already exists before creating one manually, and COOIS is the standard tool for monitoring a population of process orders once several have been created, useful for spotting the same master-data gap recurring across multiple orders.