COR2 — Change Process Order

COR2 opens an existing process order for change. It is the process-industry counterpart to CO02 for discrete production orders, sharing much of the same underlying order object model but built around phases and PI sheets rather than operations and routing confirmations. A process order carries a header (dates, order quantity, status), a material list (components with reservations), and phase data (control recipe destinations, resource assignments). All three are edited from the same transaction but governed by separate status objects. The one fact that explains most confusion: passing status checks on the header does not mean the component or phase data is still editable, and vice versa. Partial goods movements, partial confirmations, or a control recipe already sent to a process control system each lock a different part of the order independently.

COR2 is reached for during execution, after the order has been created (COR1) and usually released, when something on the shop floor floor diverges from the plan: a batch size correction, a date shift because upstream material is late, a component substitution, adding a phase, or setting a status like technically complete. It is not used for mass changes across many orders, where a background job, BAPI-driven interface, or a mass processing transaction is the right tool, and it is not used just to look at an order, where COR3 is enough and avoids accidentally locking the order. COOIS is typically used first to find the order number by material, plant, or status before jumping into COR2.

Pull AFKO by AUFNR to compare the order quantity and dates currently stored against what the user reports seeing on screen. Build the object number as the order type prefix concatenated with the padded order number and check JEST for that object number to see every active status code, which explains most 'field is not changeable' complaints. Cross-check RESB by AUFNR to see whether component quantities have already moved (movement indicator) before assuming a quantity change is safe. Compare AFPO item quantity against RESB reservation quantity to spot a mismatch left by an incomplete change.

COR1, COR2, and COR3 remain the standard GUI transactions for process orders on S/4HANA; there is no wholesale replacement of the change transaction itself. Some newer monitoring and overview Fiori apps exist for process order visibility and status tracking, but the detailed change of components, phases, and dates is still typically done through COR2 rather than a Fiori edit screen. Treat any Fiori app name here as something to verify against the actual system rather than assumed.

This is a PP-PI functional problem in the overwhelming majority of cases: status configuration, costing variant setup, or scheduling parameters. ABAP involvement is only needed if a custom user exit or BAdI is blocking a specific field. A good handover includes the order number, its current system and user statuses, the exact field the user tried to change, the error or warning text verbatim, and whether any goods movement, confirmation, or settlement has already posted against the order.

Read COR1 first to understand how the order and its component list and phases are created, since most COR2 problems trace back to a creation-time decision. COR3 is the safe display-only counterpart, useful for checking an order without risking a lock. COOIS is the entry point for finding orders by material, plant, or status before opening one in COR2. CO02 is worth comparing side by side, since it is the discrete-manufacturing equivalent and shares much of the same status and table logic. MD04 is useful for seeing the stock and requirements impact before committing a quantity or date change.