AFKO table — Order Header Data for PP Orders
AFKO holds the operational header data for a production or process order: basic and scheduled start/finish dates, the MRP controller and production scheduler, the reservation number for components, and the pointers into the BOM (STLNR/STLAL) and routing (PLNNR/PLNAL) that were exploded when the order was created. One row per order number, keyed on AUFNR.
This page covers what AFKO actually stores versus what people assume it stores, the joins into AFVC, RESB, STKO and PLKO that consultants write daily, and the recurring mistake of treating AFKO dates as authoritative without checking whether scheduling ever ran. It also flags the split between AFKO and AUFK that trips up anyone writing their first order query.
Published 16 Sept 2026· 1,073 words
What it stores
One row in AFKO represents the operational planning data of a single production or process order, keyed by order number (AUFNR). AFKO is not the order master record itself, that is AUFK, which carries order type, status and the order's business context. AFKO is the extension SAP splits off to hold the fields that describe how the order was planned and scheduled: basic dates, scheduled dates, the reservation number covering the order's component requirements, and the links to the exploded bill of material and routing. Every order created through CO01/CO40/COR1 or similar gets exactly one AFKO row the moment the order is opened, and that row is updated by every subsequent scheduling run, rescheduling, or BOM/routing change made to the order header.
Key fields
- MANDT - client
- AUFNR - order number, primary key, links to AUFK and AFPO
- AUFPL - routing/operation network number generated for the order, links to AFVC operations
- GSTRP - basic start date of the order
- GLTRP - basic finish date of the order
- GSTRS - scheduled start date after the last scheduling run
- GLTRS - scheduled finish date after the last scheduling run
- DISPO - MRP controller responsible for the order
- FEVOR - production scheduler/production supervisor
- RSNUM - reservation number for the order's dependent requirements, links to RESB
- STLTY - BOM category used for the order's component explosion
- STLNR - BOM number exploded into the order, links to STKO
- STLAL - BOM alternative used
- STLAN - BOM usage
- PLNTY - task list (routing) type
- PLNNR - task list group/routing number, links to PLKO
- PLNAL - task list group counter/alternative used
How it joins the data model
- AFKO-AUFNR = AFPO-AUFNR to get the order's material, quantity and item-level data
- AFKO-AUFPL = AFVC-AUFPL to pull the order's individual operations, work centers and durations
- AFKO-RSNUM = RESB-RSNUM to get the components reserved against the order, quantities and withdrawal status
- AFKO-STLNR = STKO-STLNR (with STLAL/STLAN) to reach the BOM header actually exploded into the order
- AFKO-PLNNR = PLKO-PLNNR (with PLNTY/PLNAL) to reach the routing header the order operations were copied from
How to read it safely
Client-dependent, keyed on AUFNR, which gives good selectivity if the order number or a range of order numbers is known. AFKO carries no plant field of its own, so any selection that needs plant, order type or status has to go through AUFK first and then join into AFKO on AUFNR, not the other way round. In discrete or repetitive manufacturing with high order volumes this table can hold millions of rows, so a scan on DISPO or FEVOR without first narrowing by order number range or by joining to AUFK on plant and order type will run long. Never select on GSTRP/GLTRP alone as a date filter across the whole table without a plant restriction first.
How to prove it in the data
Symptom: an order's dates look wrong after a rescheduling run. Pull AFKO for the order number and compare GSTRP/GLTRP against GSTRS/GLTRS. If the scheduled dates are identical to the basic dates and the user insists a reschedule was executed, the scheduling function did not actually recalculate the order, so check whether AUFPL points to a valid AFVC operation set and whether the operations themselves carry updated dates before assuming the order header is corrupt.
ECC vs S/4HANA
AFKO still exists as a database table in S/4HANA and is still populated and read by the classic production order transactions (CO02, CO03 and equivalents). Newer Fiori-based production order apps and APIs sit on top of CDS-based views rather than reading AFKO directly, but the underlying persistence and field shape of AFKO itself has not been restructured. Consultants troubleshooting from the classic transactions or writing custom ABAP against order data still land on AFKO exactly as before.
Common pitfalls
- Treating AFKO as the order master: order type, status (system and user status), and business area sit in AUFK, not here; a query built only against AFKO cannot filter by order status or type without joining to AUFK first.
- Assuming GSTRS/GLTRS are always populated: on an order that has never been scheduled, these fields can mirror the basic dates or sit blank depending on order type configuration, which is easy to misread as a scheduling failure.
- Reading STLNR/PLNNR as live links to the current BOM or routing: these are the BOM and routing that were exploded at order creation or the last BOM/routing update; changing the material's BOM afterward does not retroactively update AFKO unless the order is explicitly re-exploded.
- Forgetting that AUFPL is not the routing number: it is the order-specific operation network number generated for this one order, distinct from PLNNR which points back to the routing group the operations were copied from. Joining AFVC on PLNNR instead of AUFPL returns nothing or the wrong operations.
- Assuming RSNUM always exists: orders without component requirements, or orders using stock transfer/collective requirements logic differently, may leave RSNUM blank, which then breaks a blind join to RESB expecting rows.
- Pulling AFKO alone to judge order completion: confirmation quantities and status live in AFPO/AFVC/AFRU, not in AFKO; the header dates do not tell you whether the order has actually been produced against.
Whose problem this is
Production planning (PP) functional consultants own questions about AFKO content, since order scheduling, BOM/routing explosion and reservation generation are PP configuration and master data outcomes. Basis/technical teams get pulled in only when the concern is table growth, archiving of closed orders, or performance of joins against AFVC/RESB at volume.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/afkoERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.