COR3 — Display Process Order

COR3 opens a process order in display mode: header (order type, dates, quantities, status), the phase list (the PP-PI equivalent of operations), the component list drawn from the order's bill of material, and cost data if costing has run. The structural fact that causes most confusion is that COR3 is not a stripped-down COR2 with fewer permissions - it is a separate transaction pointed at the same underlying order object, and every screen in it is genuinely non-editable regardless of authorization. Users who expect a 'switch to change mode' button inside COR3 will not find one; changing anything requires exiting and calling COR2 with the same order number.

COR3 is the first stop when checking why an order has not confirmed, why a component is missing from the pick list, or why a cost variance appeared, because it lets a consultant or planner look at the order without any risk of triggering a status change or a recalculation. It sits between order creation (COR1) and confirmation (CO11N) in the daily workflow: production supervisors use it to verify what was released before confirming, and support consultants use it to reproduce a reported issue exactly as the order stands. COOIS or a manufacturing cockpit app is preferred when scanning many orders at once; COR3 is for one order at a time, in depth.

In SE16 or SE16N, pull AFKO filtered on the order number to confirm basic dates, quantity, and order type match what COR3 shows. Join to AFPO on the same order number for the material and batch. To confirm a missing component, filter RESB on the order number and compare the line count and quantities against what the component overview in COR3 displays; a component present in RESB but not shown in COR3 usually points to a deleted or reversed reservation flag on that line rather than a display bug. Cross-check AFVC for the phase list if a phase visible in the master recipe is missing from the order.

COR3 continues to work in S/4HANA without functional change; the underlying order tables and phase logic in PP-PI are unchanged. S/4HANA adds Fiori apps for monitoring and managing process orders that overlay the same data with a worklist and status-driven view, and many shop floor users now reach the order through one of those apps instead of typing COR3 directly. The GUI transaction remains valid for consultants who need the full detail screens, particularly cost analysis and long text, which the Fiori equivalents do not always expose in the same depth.

This is functional PP-PI territory. A clean handover to Basis or ABAP only happens if the display itself throws a dump or a performance timeout on a large order; otherwise the fix, if any, lives in COR2, the master recipe, or the BOM, and the handover should include the order number, the specific screen where the discrepancy appears, and the expected values from the master data.

COR1 and COR2 are the create and change transactions for the same order object and are the natural next stop once a discrepancy seen in COR3 needs correcting. CO03 is the equivalent display transaction for discrete production orders, useful for comparison when a plant runs both order types. COOIS gives the list view across many orders at once, which is where a COR3-level investigation usually starts before narrowing to one order. CS03 and CR03 are worth checking alongside COR3 when the component or resource shown on the order does not match current master data.