CO03 — Display Production Order

CO03 opens a production order strictly for viewing. It reuses the identical screen structure as CO02 - header, operation overview, component list, costs, confirmations, goods movements - but every field is protected against input, and the toolbar drops functions like release, technical completion, or order change. The one structural fact that explains most confusion: CO03 is not a separate data model, it is CO02 rendered in a locked mode. Anything wrong in CO03 - a missing component, an odd status, a quantity that does not add up - is not a display defect, it is the actual state of the order. Consultants sometimes toggle between CO02 and CO03 in the same session and get thrown when a menu path that worked a minute ago disappears; that is authorization or lock behavior, not a bug in CO03 itself.

CO03 is reached for whenever someone needs to inspect an order without touching it: verifying scheduled dates before a planner escalates a delay, checking whether a confirmation posted before opening a ticket, confirming released quantity against goods receipt, or auditing an order that belongs to another plant or shift and where the user has no change authorization. It sits downstream of MD04 stock/requirements list and COOIS order list - those tools tell which order to look at, CO03 is where the order's own detail is examined. For monitoring many orders at once, COOIS or a Fiori order worklist app is the better entry point; CO03 is for one order, opened by number, when the detail behind the summary line is needed.

In SE16 on AUFK, filter by order number to get the internal order number, then read AFKO for basic dates and quantity and AFPO for delivered versus target quantity. To check the status a user is disputing, look at the object status table joined on the order's object number (the same object number stored on AUFK) rather than trusting only the header text in CO03, since combined statuses (partially confirmed plus technically complete) can look ambiguous on screen but are unambiguous as discrete entries in the status table.

CO03 exists unchanged on S/4HANA as the GUI display transaction for production orders, and the underlying header, operation and component data it reads is unaffected by the S/4HANA data model simplification in this area. A Fiori app for monitoring and displaying production orders is available for browser-based or list-oriented work, but CO03 remains the direct route to the full classic detail screen and is still commonly used by consultants for troubleshooting.

This is functional PP territory first: a PP consultant reads the order status, quantities and confirmations to establish what actually happened. Escalate to ABAP only if a custom field or user exit is not rendering on the screen. Escalate to Basis only for an authorization object missing from a role or a stuck lock entry that will not clear. A good handover states the order number, the exact tab and field in question, and the status line as read directly from CO03.

CO02 is the change-mode twin of CO03 and the natural next stop once the display confirms something needs correcting. CO01 is where the order this screen shows was originally created, useful context when a header field looks unexpected. COOIS is the list transaction to reach for when the question is which orders, not this one order. CO11n and CO15 handle the confirmations whose results appear read-only on the CO03 confirmations tab, and are where a missing or incorrect confirmation actually gets fixed.