AFVV table — Order Operation Quantities and Dates

One row in AFVV represents the quantity and date information for a single operation belonging to a production order, process order, or the routing used during order creation. When an order is created from a routing, each operation gets a combined AFVC/AFVV pair identified by AUFPL and APLZL. AFVC carries the descriptive, largely static fields for the operation (control key, work center, standard value fields). AFVV carries the fields that change constantly during the life of the order: scheduled start and finish, actual start and finish once confirmations post, and the operation quantity to be produced or confirmed. The split exists for performance reasons, since dates and quantities are rewritten far more often than the descriptive data, and SAP wanted the frequently updated fields isolated in their own table rather than causing lock contention or unnecessary buffering invalidation on AFVC.

AFVV is client-dependent and has no natural high-selectivity field of its own outside its key, so it is never queried standalone. The only sane entry point is AUFPL, obtained first from AFKO by order number, or from AFVC when the operation number or work center is known. Selecting on AFVV without a bound AUFPL, or scanning date ranges directly on this table across all orders, will hit an enormous, largely unindexed scan on most systems since there is no secondary index built for arbitrary date filtering. Always resolve the order first, get its AUFPL, then read AFVC/AFVV for that AUFPL and filter operations client-side or by APLZL range.

Symptom: an operation shows no actual dates even though the order status says partially confirmed. Look up AFKO for the order number to get AUFPL. Read AFVC for that AUFPL to find the APLZL of the suspect operation and confirm its control key allows confirmation. Then read AFVV for the same AUFPL/APLZL and check whether the actual start/finish fields are still blank while the scheduled fields are populated. Blank actual dates with populated scheduled dates confirms the confirmation never posted against that specific operation, even if the order header shows movement elsewhere.

AFVV continues to exist as a transparent table in S/4HANA and is still populated by order creation, scheduling, and confirmation the same way it was in ECC. Reporting is increasingly built on CDS views that expose order operations at a higher level of abstraction, but the underlying quantity and date storage for operations has not been restructured away from the AFVC/AFVV split. Consultants working directly in SE16N or building custom reports still read AFVV the same way they did in ECC.

Scheduling and date discrepancies on AFVV are a PP consultant question, tied to the scheduling parameters on the order type and routing. Quantity discrepancies that trace back to confirmations are shared with production execution or shop floor teams who own the confirmation transactions. A functional consultant should own the diagnosis before anyone touches the table directly.

AFVC is the mandatory pairing table holding the descriptive side of the same operation key. AFVU carries split-off user fields for the operation under the same AUFPL/APLZL. AFKO is the order header table that supplies AUFPL. AFRU records individual confirmations posted against the operation and is the place to look for confirmation history rather than a single current-state row. Order creation transactions and the scheduling and confirmation transactions in production order processing are what write to AFVV; it is not maintained directly by any master data transaction.