AUFK table — Order Master Data (AUFK)

One row in AUFK represents a single internal order (or another CO order type such as a maintenance or investment order) at header level. It captures who created the order and when, which company code and controlling area it belongs to, its order type, its responsible and requesting cost centers, its short text, and the object number (OBJNR) that ties it into the general status management framework shared by orders, WBS elements, and networks. AUFK does not carry planned or actual values, budget figures, or settlement history - those are recorded elsewhere and referenced back to the order through AUFNR or OBJNR. Deleted orders are usually just flagged, not removed, so AUFK also accumulates a long tail of closed and technically completed orders that never get physically purged.

AUFK is client-dependent, so always restrict on MANDT implicitly through the client connection, and never select across clients in a cross-client tool without realizing it. AUFNR is the natural key and highly selective; a lookup by order number returns exactly one row. Selecting by BUKRS or KOKRS alone on a mature system can return hundreds of thousands of rows because orders are rarely archived, so add AUART or a creation date range before running an ad hoc query. Avoid selecting on KTEXT with wildcards as a primary filter; it is unindexed free text and will force a full table scan on large installations.

To confirm an order exists and is still open, select AUFK by AUFNR and check PHAS0 through PHAS4 alongside the object number; then use that OBJNR to check the status table for the current user status rather than assuming from AUFK's phase fields alone. To confirm whether an order has been posted to, do not stop at AUFK - join OBJNR into the CO line item table or AUFNR into the FI line item table and check for at least one row; an order with no matching rows there is financially inert regardless of what AUFK's dates suggest.

AUFK still exists as a transparent table in S/4HANA and continues to be the master data source for orders; it has not been replaced by a CDS compatibility view the way many FI totals tables have. What changed underneath it is where the values live: actual and commitment postings against the order now flow into the universal journal and CO line item tables directly, rather than through the older separate CO totals tables, so join targets for cost reporting shift even though AUFK's own structure is largely unchanged.

Order type configuration, number ranges, and settlement rules belong to the controlling (CO) team. Whether a specific order should exist, who it is assigned to, and whether it should be closed or settled is a decision for the cost center owner or project lead, not something to resolve by editing AUFK data directly. FI involvement is usually limited to confirming which company code and account assignment a posting against the order actually hit.

Order creation and change run through the standard order maintenance transactions, which write AUFK and its associated status and classification tables together; direct table edits to AUFK are not supported and break the consistency with status management. Cost center master data referenced by KOSTV and KOSTL is maintained separately and owned by CO master data administration. FI line items posted against an order are visible through standard FI line item display transactions filtered by order number, and in an S/4HANA system the same postings are visible directly in the universal journal.