AFRU table — AFRU Order Confirmation Table

One row in AFRU represents a single confirmation posting against a single operation of a single production, process or maintenance order, identified by confirmation number and confirmation counter. Each confirmation carries the reported yield and scrap for that operation, the actual start and finish, the posting date, the work center at which the confirmation was recorded, and a reference back to the order and the routing operation being confirmed. A single order operation can and usually does have many AFRU rows over its life: partial confirmations, final confirmation, and any reversals of earlier confirmations. The table is a log, not a current-state table, so the operation status and the accumulated confirmed quantity are calculated by summing AFRU rows, not read from a single field on one row.

AFRU is a genuinely large table on any site with real production volume, since every partial confirmation, final confirmation and reversal adds a row and history is rarely archived aggressively. Always restrict by MANDT and by a date range on BUDAT before anything else; a full scan by order number alone across years of history is the most common cause of a timeout. If the investigation is about one order, filter by AUFNR and AUFPL together, not AUFNR alone, since AUFPL is far more selective once known. Avoid filtering by ARBID as a primary key field, it is an internal surrogate and unhelpful for eyeballing results; join to CRHD for the readable work center code instead.

Symptom: an operation shows as fully confirmed in CO13 or in order status but the reported quantity in reporting looks wrong. Select AFRU where AUFNR equals the order and VORNR equals the operation, sorted by BUDAT ascending, and sum LMNGA across all non-reversed rows for that operation. Compare that sum against the order quantity from AFKO. A mismatch usually means either a reversal row was not netted out in whatever report produced the wrong figure, or a confirmation was posted against the wrong operation number.

AFRU continues to exist as a transparent table on S/4HANA and confirmation postings still write to it in the same shape as on ECC. Reporting increasingly runs through CDS views built on top of AFRU rather than direct table reads, but the underlying table structure and posting logic for confirmations has not been replaced. Consultants querying confirmation history directly, outside of Fiori apps, still land on AFRU.

Confirmation data quality is a shop floor and production planning question first, resolved by checking what was actually keyed or scanned at the work center, not a table structure question. A functional PP consultant owns discrepancies between planned and confirmed quantities; a basis or data team gets involved only if archiving or a system copy has affected ARBID consistency or historical volume.

AFVC holds the routing operation being confirmed and is the join target for operation detail. AFKO holds the order header that AUFNR points back to. CRHD resolves the work center referenced by ARBID. Confirmations are written by CO11N, CO15, CO12 for collective entry, and mass processing programs used in high-volume discrete or process manufacturing.