AFVC table — Order Operation Table AFVC

One row in AFVC represents a single operation, or a sub-operation under a parent operation, belonging to the routing that was copied into a specific production or process order at order creation. It carries the control key that governs whether the operation is relevant for scheduling, costing, confirmation or capacity planning, the work center it is assigned to, and a short descriptive text. AFVC is order-specific: it is the result of the standard routing (held in PLPO) being copied and possibly modified for that one order, so two orders built from the same routing group will have two independent sets of AFVC rows, not shared ones. Planned times, quantities and cost-relevant values for the operation are not stored here; they live in the companion table AFVV, keyed the same way.

Always restrict by MANDT and, if reading directly, by plant (WERKS) or order number range through AFKO first, since AFVC has no order number field of its own and is only reachable via AUFPL. Never select on VORNR alone across orders, it repeats endlessly (every order tends to have a 0010, 0020...) and carries no uniqueness across the table. The practical entry point is almost always AFKO for the order, then AFVC filtered on the resulting AUFPL, then AFVV or AFRU joined on AUFPL and APLZL. Check the deletion indicator before trusting a row; cancelled or replaced operations are not always physically removed.

To confirm which control key governs confirmation behaviour for a stuck order, pull AFKO for the order number to get AUFPL, then read AFVC for that AUFPL and inspect STEUS and the deletion flag on the operation in question. If STEUS points to a control key that suppresses confirmation or backflushing, that explains why the operation never shows up in AFRU regardless of what the shop floor reports.

AFVC continues to exist as a transparent table in S/4HANA and is still the primary store for order operation data; there is no widely known compatibility view replacing it at the operation level in the way some financial or material tables were replaced. The routing and order data model around it (AFKO, AFVV, AFVU, AFRU) is unchanged in structure, so existing joins and reports built against AFVC on ECC generally continue to work on S/4HANA without redesign.

Production planning consultants own the interpretation of control keys, work center assignment and operation sequencing questions raised against AFVC. Routing and master data teams own why a given operation was copied into the order the way it was; a wrong answer here is rarely a Basis or data-quality problem, it is a routing or order-type configuration problem.

AFKO holds the order header and the AUFPL that anchors every AFVC read. AFVV and AFVU carry the quantity, time and user-field data for each AFVC operation. AFRU records actual confirmations against those same operations. RESB ties component reservations to a specific operation. CRHD supplies the readable work center behind ARBID. Transactions that write AFVC include order creation and change (production and process order transactions) and mass processing of operations.