CO15 — Production Order Confirmation Transaction CO15

CO15 records that some or all of the operations on a production order have been performed, capturing actual yield, scrap, rework quantity and the durations or activity quantities consumed. The structural fact that explains most of the confusion around it is that a single CO15 posting can carry three different postings inside it: the confirmation itself (AFRU), an automatic goods receipt of the header material if the order is backflush-relevant, and an automatic goods issue of the components marked for backflush. A user who only intended to log labor time can therefore trigger a stock movement, and a movement error will abort or partially abort the confirmation even though nothing about the time entry itself was wrong.

CO15 is used on the shop floor side of discrete manufacturing, once an order has been released and work has actually started or finished. It is reached for when someone needs to confirm the order as a whole, or several operations in one session, rather than one operation at a time - that use case is normally handled with CO11N. Planners and production supervisors use CO15 at shift end or job completion to close out yield and scrap; it sits between order release (CO01/CO02) and settlement, and feeds directly into the order's cost and status picture visible in COOIS.

Start in AFRU filtered on the order number and operation to see whether a confirmation record exists, its posting date, and its yield/scrap split. Cross-check MSEG for movement types typically used for backflush issue and automatic receipt, filtering on the material document's reference to the order number, to confirm whether the goods movement side actually posted or failed. If costs look missing, check COEP for the order's CO object number and compare activity quantities there against AFRU; a confirmation with no matching COEP line usually means the cost postings were suppressed by a status or costing error, not that the confirmation itself is missing.

CO15 exists unchanged in S/4HANA as the order-level confirmation transaction; the underlying confirmation logic and the coupling with automatic goods movement have not been restructured. Fiori-based confirmation apps for shop floor users cover the same function for simpler, single-operation confirmations, but CO15 remains the transaction of choice for confirming an entire order or multiple operations in one session, and it is still the fallback when a Fiori confirmation app cannot resolve a backflush or status error.

This is a PP functional problem in the first instance, since the confirmation logic, order status and operation setup belong to production planning configuration. Backflush and goods movement failures cross into MM and should be handed to whoever owns storage location and batch determination. A good handover states the order number, operation, the exact error or missing posting, whether AFRU shows a record, and whether MSEG shows the expected movement - that split tells the next owner immediately whether it is a PP status issue or an MM movement issue.

CO11N is the natural comparison point for understanding when single-operation confirmation is preferable to CO15's order-level approach. COOIS is the first place to check the aggregate confirmation and goods movement status of an order before diving into CO15 itself. CO02 and CO03 are used to inspect or change the order status and component list that CO15 depends on. Reading those four alongside CO15 gives a working picture of the full confirm-and-consume cycle for discrete production orders.