KO02 — Change Internal Order Master Data

KO02 opens an existing internal order in change mode and lets a user update assignment data (company code, business area, cost center, profit center, functional area), control indicators, the settlement rule, and the order's system or user status. The one fact that explains most confusion is that field availability is not static: it is governed jointly by the order type's field control settings and the order's current status. An order in status CRTD allows broad changes; once it is REL (released) many fields lock; once TECO (technically complete) or CLSD (closed), almost everything except the status itself is frozen. Consultants who expect KO02 to behave like a plain master data screen are repeatedly surprised by fields that simply will not accept input, and the reflex of blaming authorization wastes time that a two-second status check would save.

KO02 is reached for during the operational life of an internal order: correcting the responsible cost center after an org change, reassigning the settlement receiver before month-end settlement, adjusting a description, or moving the order through its status sequence (release, technically complete, close) to control what postings are still allowed against it. It is distinct from KO01, which creates a new order, and KO03, which is read-only and used for verification without risk of an accidental save. A consultant reaches for KO02 rather than a Fiori app when full access to all order fields, tabs, and the status button is needed; Fiori equivalents for internal order maintenance exist but tend to expose a narrower field set aimed at casual users, so the classic transaction remains the tool of choice for anything beyond a simple text change.

Start in SE16 on AUFK filtered by AUFNR to confirm the order type, controlling area, and header data currently stored. Take the OBJNR from that record and query JEST filtered on that OBJNR with the inactive indicator blank to see the live status stack (CRTD, REL, TECO, CLSD as applicable); this tells whether a reported field lock is status-driven. To check a settlement dispute, query COBRB on the same OBJNR and confirm the receivers and percentages sum correctly. If a change appears to have vanished, pull CDHDR and CDPOS for the object to see whether it was saved at all or rolled back.

KO02 continues to work unchanged on S/4HANA; the underlying order master structure in AUFK and the status logic in JEST are the same as in ECC. Fiori apps for internal order processing exist and cover common changes for casual users, but they expose a reduced field set compared to the full classic transaction, so consultants doing anything beyond a routine update still fall back to KO02. No functional replacement has removed this transaction from active use.

This is a CO functional problem in nearly all cases: cost center accounting or overhead order configuration owns the order type settings, status profile, and settlement rule structure. ABAP involvement is limited to custom validations or BAdI implementations attached to order changes. Basis is relevant only for stuck enqueue locks. A good handover includes the order number, its current status stack from JEST, and the exact field or tab the user cannot change.

Read KO01 next to understand how the fields being changed in KO02 were first set at creation, since field control behaves symmetrically between the two. KO03 is worth knowing as the safe read-only counterpart for verifying a change without risk. KOB1 shows the actual line items that explain why certain fields have frozen. OKB9 is relevant when a settlement rule keeps reverting to a default account assignment that was configured centrally rather than on the order itself.