CO02 — Change Production Order
CO02 changes an existing discrete production order created in CO01 - header dates, quantities, operations, components, and status (release, hold, technical completion). The key structural fact is that editability is status-dependent: once an order carries a system status like released, partially confirmed, or delivered, large parts of the order lock, and changes made at header level do not automatically retro-adjust operations or reservations that were already fixed.
This page covers CO02, the transaction used to change discrete production orders after creation, including release, rescheduling, component and operation edits, and status changes. It focuses on the status and posting-dependent restrictions that cause most change failures and how to trace the resulting order state in the underlying tables.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,134 words
Purpose
CO02 opens an existing production order for editing. It covers the same header, component, and operation views available in CO01 at creation, but now working against an order that may already carry postings - goods issues, confirmations, or settlements. Typical actions are releasing the order, changing planned dates or quantities, adding or removing components, changing a work center or control key on an operation, putting the order on hold, or technically completing it. The structural fact that drives most confusion is that the order's system status (and any user status) gates what can actually be changed - a field that was freely editable before release can become read-only or trigger a warning once confirmation or delivery has occurred, and the transaction will not always make this obvious until save.
When it is used
CO02 sits between order creation (CO01) and shop floor execution (CO11N for confirmations, CO15 for collective confirmation). It is reached for whenever a planned order already converted to a production order needs adjustment - a rescheduled due date, a component substitution, a quantity change from a sales order update, or a manual release because automatic release did not fire. It is also the standard path to put an order on hold or technically complete it outside the standard confirmation flow. MD04 and MD05 are read-only views used to spot the need for a change; CO02 is where the change is actually executed. On S/4HANA, some of this is offered through Fiori manufacturing apps, but CO02 remains the fallback for detailed multi-field edits.
How to use it in practice
- Call CO02 and enter the order number directly, or use the order list search if only the material or sales order is known
- Press enter to load the order overview screen showing header data, status, and dates
- Switch to the component overview to add, delete, or change quantities of materials in the reservation
- Switch to the operation overview to change work center, control key, or activity times on the routing
- Use the release function if the order status is still created and the change requires the order to be released
- Save; this triggers scheduling recalculation, availability check, and cost update depending on order type configuration
Key data objects
- AUFK - order master header: order number, order type, plant, object number linking to status
- AFKO - PP-specific header data: scheduling dates, BOM explosion number, order finish rule
- AFPO - order item: material, order quantity, delivered quantity, batch
- AFVC - order operations: work center, control key, activity durations
- RESB - component reservations: required quantity, withdrawn quantity, movement allowed indicator
- JEST - active status records linked to the order's object number
- AFFL and AFFH - sequence and network header for orders with multiple sequences
How to prove it in the data
Start in AUFK for the order number to get the object number (OBJNR) and confirm plant and order type. Join OBJNR against JEST filtering on INACT blank to list all currently active statuses - this tells whether the order is released, partially confirmed, or technically complete, which explains most field lockouts. Cross-check AFKO for the current scheduled dates against AFPO for order quantity versus delivered quantity, and RESB for the same order to see whether required components already show a withdrawn quantity greater than zero, which blocks simple quantity reductions.
ECC vs S/4HANA
CO02 still exists and functions the same way on S/4HANA; the underlying tables AUFK, AFKO, AFPO, and AFVC are unchanged for classic discrete production orders, unlike the finance documents that moved to the universal journal. S/4HANA offers Fiori apps for order release and schedule changes aimed at shop floor users, but these cover a narrower set of fields than CO02 and do not replace it for detailed component or operation edits.
Common pitfalls and how to diagnose them
- Status lock: the order already carries a system status such as partially confirmed, delivered, or technically complete that silently restricts editable fields. Check JEST via the order's object number before assuming a field should be open; do not force a status change to get around this without understanding what it will do to open reservations.
- Post-goods-issue component edits: changing a component quantity in CO02 after goods issue has already posted does not reverse the movement. RESB will show a withdrawn quantity that no longer matches the new required quantity; the actual stock correction has to happen through a separate goods movement reversal.
- Rescheduling that does not propagate: changing the header basic dates updates AFKO but does not automatically recalculate operation-level dates in AFVC unless the explicit reschedule function is run. Symptom is a header date that looks right but a capacity load or confirmation date that still reflects the old schedule.
- Release blocked by availability check: the order cannot be released because a component fails the ATP check configured for the order type. The error points to a material shortage, not a transaction fault; check the availability control settings on the order type and the actual stock situation via MD04 before retrying.
- Locked by another session: a second user has the order open, producing a foreign lock message. Check SM12 for the order's lock entry before assuming a data problem.
- Missing authorization for order type or plant with change activity, producing a silent failure to save rather than a clear error - check the user's authorization trace if the save appears to do nothing.
Whose problem this is
Functional ownership sits with production planning or shop floor control. A good handover includes the order number, the current system status list from JEST, the exact field the user tried to change, and the error or silent-failure behavior observed. Escalate to ABAP only if a user-exit or BAdI is suspected of altering standard field behavior; escalate to Basis only for lock table or authorization trace issues.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/co02ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.