TFDIR table — Function Module Directory Table TFDIR
TFDIR is the cross-client repository table listing every function module known to the system: its name, the main program of its function group, the include holding its actual code, and flags for global visibility, RFC-enabling and update-task capability. It is consulted when a BAPI or RFC call fails, when tracing which function group owns a module, or when checking whether a module is remote-enabled.
This page covers what one row in TFDIR represents, the fields worth trusting, how it joins to program and transport data, and the mistakes made when reading its flags as guarantees rather than declarations. It also covers ownership and its status in S/4HANA.
Published 15 Sept 2026· 1,076 words
What it stores
One row in TFDIR represents a single function module registered in the ABAP repository. The row records which function group's main program contains it, which include holds the actual source code, and a set of technical flags describing how the module may be called: whether it is global, whether it is RFC-enabled, whether it may run inside an update task. TFDIR is a repository directory table, not application data, and it is cross-client: a function module exists once for the whole system, regardless of how many clients are logged into. Every ABAP program that issues a CALL FUNCTION statement is, at generation time, resolved against an entry in this table. Absence of a row for a given name normally means the function module does not exist, is misspelled, or has not yet been transported into the system.
Key fields
- FUNCNAME - name of the function module, primary key of the table
- PNAME - name of the main program of the function group that owns the module, typically following the pattern SAPL followed by the function group name
- INCLUDE - name of the include program that actually contains the ABAP source of the module
- RFCFLAG - flag indicating the module is remote-enabled and can be called via RFC
- GLOBFLAG - flag indicating the module is global, callable from outside the internal session of its own function group
- UTCFLAG - flag indicating the module may be called within an update task using CALL FUNCTION IN UPDATE TASK
How it joins the data model
- TFDIR-PNAME = TRDIR-NAME - pull program-level attributes of the function group's main program, such as program type, fixed point arithmetic setting, or unicode status
- TFDIR-FUNCNAME = ENLFDIR-FUNCNAME - pull additional function module attributes such as application component and exception handling details not stored in TFDIR itself
- E071-OBJ_NAME = TFDIR-FUNCNAME, filtered to object type LIMU FUNC - trace which transport request carried a given function module and when
- TADIR-OBJ_NAME = function group derived from PNAME (strip the leading SAPL), TADIR-OBJECT = FUGR - confirm the function group is a registered repository object and check its package and original system
How to read it safely
TFDIR is client-independent, there is no MANDT field to restrict on, and a row read in one client is the same row seen in every client. The table is large, running into tens of thousands of entries on a fully loaded system, so an unrestricted select is wasteful even though technically permitted. FUNCNAME is the primary key, so a direct lookup by exact name is fast and the correct approach when the function module name is known. When the name is not known precisely, restrict by PNAME using a pattern such as the function group's main program name rather than scanning FUNCNAME with a leading wildcard, since PNAME groups modules by function group and narrows the search meaningfully.
How to prove it in the data
Symptom: an RFC call to a custom function module fails with an error stating the module is not remote-enabled. Select TFDIR where FUNCNAME equals the module name and inspect RFCFLAG. If the flag is not set, the module was never marked remote-enabled in the function builder, and the fix is a development change to the module's processing type, not a configuration or Basis setting, followed by transport and activation.
ECC vs S/4HANA
TFDIR still exists in S/4HANA in the same shape and role. Function modules remain a first-class ABAP artifact alongside classes, and the directory table backing them has not been replaced by a CDS compatibility view or restructured. It is still populated and maintained through the function builder, still cross-client, and still the authoritative place to check whether a module is remote-enabled or callable in an update task.
Common pitfalls
- RFCFLAG being set does not guarantee the module actually works correctly over RFC. A module can be flagged remote-enabled and still fail at runtime if it references screen state, memory IDs, or other session-bound constructs that do not survive a remote call.
- INCLUDE is not a standalone executable program. It is a fragment of source that only compiles and runs as part of the function group's main program, so trying to treat it like an independent report is a mistake.
- GLOBFLAG describes technical visibility outside the function group's local call scope, not release status or supportability as a stable API. A module can be global and still be an unreleased internal helper never meant for external use.
- Assuming a missing row means the module was deleted everywhere. It may simply not yet be transported into the system being checked, or the name may be misspelled in the calling program, which is a far more common cause than actual deletion.
- Changing a flag directly in the table via generic table maintenance, rather than through the function builder, is not how these attributes are meant to be set. Direct changes bypass generation and versioning and will not take effect the way expected, and they affect every client at once because the table is cross-client.
- Believing that updating RFCFLAG on the source system alone propagates to a calling system immediately. Interfaces cached on the calling side, including generated proxy stubs, need to be regenerated or reactivated after the module's remote-enabled status changes.
Whose problem this is
A question about TFDIR belongs to the ABAP development or Basis team, not to a functional module consultant. Functional consultants encounter it only indirectly, typically while diagnosing why a BAPI or RFC-based integration is failing, and the resolution beyond confirming the flag values sits with development and transport management.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/tfdirERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.