AFIH table — AFIH Maintenance Order Header Data (PM/CS)

Each row in AFIH represents the PM/CS extension of a single maintenance order header, keyed by order number (AUFNR). Where AUFK holds the order's generic attributes (type, status, company code, cost object), AFIH holds the fields specific to plant maintenance and customer service: which equipment or functional location the order was raised against, the responsible work center and planner group, priority, and the malfunction data used for breakdown analysis (start, end, duration, breakdown indicator). It also carries the link back to the notification the order was created from, if any, and to the maintenance plan that generated it, if the order is plan-driven. There is normally exactly one AFIH row per PM/CS order; the table does not exist for orders created outside plant maintenance.

AFIH is client-dependent and keyed on AUFNR, so a lookup by order number returns a single row and is always cheap. It stops being cheap the moment the selection runs the other direction, from equipment or date range back to orders, because there is no guarantee of an efficient secondary index on EQUNR or on the malfunction date fields in every system. For breakdown or downtime reporting, restrict first by plant and by a realistic date window on AUSVN before adding EQUNR, and expect to join through AUFK if order type or status also needs to be checked, since neither lives in AFIH itself.

To confirm reported downtime for a piece of equipment: select AFIH where EQUNR equals the equipment number and AUSVN falls in the reporting period, then sum AUSZT across the returned rows. If the sum does not match what the business expects, check whether MSAUS was actually set on those orders and whether AUSVN/AUSBS were filled in at all, since both are manually entered by the planner or technician and are not derived automatically by the system.

AFIH is retained in S/4HANA as a transparent table; the PM/CS order header data model was not restructured the way the finance and material document tables were. Reporting on top of it increasingly goes through CDS views rather than direct table access, but the underlying table and its field layout are essentially unchanged from ECC. Custom reports and interfaces built directly against AFIH generally continue to work without remapping.

Data questions on AFIH sit with the PM or CS functional consultant, since the fields reflect process decisions (how the order was created, whether breakdown data was logged) rather than a technical fault in the table. Missing or wrong malfunction dates are a planner or technician data-entry problem to raise with the maintenance team, not a table structure issue for the basis or ABAP team to fix.

Written when a maintenance order is created or changed through the standard order transactions, and read by any downtime, breakdown, or MTBF/MTTR reporting built on PM data. Sits alongside AUFK (order master), the equipment and functional location masters, the notification header, and the maintenance plan tables; joins to those are how most PM reporting is actually built rather than reading AFIH in isolation.