IFLOT table — Functional Location Master Table

One row in IFLOT represents a single functional location, identified by the technical key TPLNR, regardless of where that location sits in the plant hierarchy. A functional location is a fixed structural element in the plant, a building, a production line, a work center, a section of pipework, distinct from the physical equipment installed on it. IFLOT carries the header-level master attributes of that location: its category, the hierarchy structure it belongs to, the plants responsible for maintaining and planning it, the cost center it reports to, and technical attributes like manufacturer and model. It is the direct structural equivalent of EQUI for equipment, and the two share a large amount of common field structure inherited from the shared technical object data model.

Always restrict on MANDT first, then on IWERK or SWERK before touching the full table, since a plant with a deep technical hierarchy can hold tens of thousands of functional locations. TPLNR is not a free-text code, it is a fixed-length internal string whose displayed form depends on STRNO; comparing or truncating it outside the standard hierarchy logic produces false negatives. Avoid open pattern searches like LIKE with leading wildcards on TPLNR across the whole table. To walk the hierarchy, follow TPLMA level by level rather than trying to infer parent-child relationships from the string shape of TPLNR alone, since the edit mask can visually suggest a hierarchy that the data does not confirm.

Symptom: a functional location cannot be deleted or archived. Select AFIH and VIQMEL where TPLNR equals the location key; any row returned means open or historical orders and notifications still reference it, which blocks deletion regardless of what IFLOT itself shows. Symptom: equipment history at a location looks wrong. Select EQUZ where TPLNR equals the location and inspect the install and removal date range, since IFLOT carries no installation history of its own.

IFLOT continues to exist as the underlying table in S/4HANA and the table shape has not materially changed. Newer Fiori applications and PM/EAM analytics typically read functional location data through CDS compatibility views built on top of IFLOT rather than selecting the table directly, but classic transactions and custom ABAP still access it the same way as on ECC.

The PM or EAM functional consultant owns the interpretation of IFLOT data, usually alongside a plant engineering or asset management team that defines and governs the technical hierarchy. Despite carrying BUKRS and KOSTL, it is not an FI or CO owned table; cost assignment disputes route back to the PM configuration and the account assignment rules on the order or location.

EQUI and EQUZ hold the equipment master and its installation history at the location; IFLOTX carries the description texts; ILOA carries location and account assignment shared across objects; AFIH and VIQMEL carry the orders and notifications that reference the location; IHPA carries partner assignments. IFLOT is maintained through the standard functional location create, change and display transactions.