AFVU table — Order Operation User Fields Table

One row in AFVU represents the set of customer-defined additional fields attached to one specific order operation (occasionally a routing operation, depending on how the enhancement was activated). It does not carry any SAP-delivered business content of its own beyond the key. The table exists because SAP provides an append or include mechanism so implementations can add fields to the operation screen (confirmation, operation detail) without modifying AFVC directly. Whether a given order operation has a populated AFVU row at all depends entirely on whether the implementation activated and filled that customer extension. A production order with thousands of operations can have an AFVU table that is mostly empty, and that is normal, not a data error.

AFVU is client-dependent and keyed exactly like AFVC, so it should never be queried alone. Selectivity is entirely inherited from AFVC: restrict on AUFPL first, derived from AFKO for a specific order number, then narrow by APLZL if a specific operation is needed. Because the table can be sparsely populated, a missing row for a given AUFPL/APLZL is not proof of a data problem; it may simply mean the enhancement was never triggered for that operation. Full table scans are rarely useful and rarely fast, since there is no secondary index worth relying on beyond the primary key.

Symptom: a custom field entered on the operation confirmation screen does not appear to save. Get the order's AUFPL from AFKO using AUFNR, get APLZL for the operation in question from AFVC, then select AFVU on that exact AUFPL and APLZL. If no row exists, the enhancement never wrote to the table for that operation and the problem is upstream (screen exit, user-exit logic, or activation), not the table itself. If a row exists but the value is wrong, the problem is in the update logic feeding AFVU.

AFVU continues to exist as a physical table in S/4HANA; migrated orders and routings that used the operation user-field enhancement keep their AFVU rows. There is no indication this table has been folded into a CDS compatibility view the way many classic PP header tables have, since its content is customer-specific by design rather than a standard SAP data structure that lends itself to a generic reporting view. Any reporting built on AFVU in an S/4 conversion should be re-validated rather than assumed to still function, particularly if the underlying enhancement was reworked during the move to Fiori confirmation apps.

The functional PP consultant confirms what the enhancement fields are supposed to mean and when they should be populated. Whether the data is actually landing correctly in AFVU, and why, is an ABAP development question, since the fields and the logic that fills them were built as a custom or partner enhancement, not delivered SAP standard behavior.

AFVC is the operation control table this table extends and must always be joined through. AFVV carries the standard quantity, date, and control data for the same operation key. AFKO is the order header table that supplies the AUFPL needed to reach both. Transactions CO01, CO02, and CO03 (order create/change/display) and the confirmation transactions are what actually write to AFVU when the enhancement is active.