CALL_FUNCTION_NOT_FOUND — CALL_FUNCTION_NOT_FOUND Runtime Error

CALL_FUNCTION_NOT_FOUND is raised when the ABAP runtime cannot locate the function module named in a CALL FUNCTION statement, either because no TFDIR entry exists for that name in the system being addressed, or an entry exists but has no active generated load, or the call is remote and the target system reports the same failure back. This resolution happens before parameter interface checking, so it fires earlier in the call sequence than errors like CALL_FUNCTION_PARM_MISSING or CALL_FUNCTION_CONFLICT_TYPE, which assume the function module was at least found. For a literal, statically coded function name this is a build or transport defect, not a runtime data condition. For a dynamic call, where the name is built from a variable, the runtime performs a genuine lookup at execution time and the ABAP exception class CX_SY_DYN_CALL_ILLEGAL_FUNC exists specifically to let that case be caught; an uncaught dynamic lookup failure still produces this dump.

If the cause is a transport gap, release and import the function module's transport into the affected system before re-testing; this needs a change request through the normal transport path, not a manual object creation. If it is a typo or stale reference in custom code, correct the literal name in the source and transport the fix, which requires a development change request. If the RFC destination is wrong, correct the target system or client in SM59; this is a Basis-side configuration fix and usually does not need a change request unless the destination is centrally managed. If the function group failed to generate, fix the syntax error and reactivate it, then re-import any pending transport that depends on it. If the cause is a release mismatch across systems in a hub scenario, the fix is coordination of the upgrade or release-dependent logic in the interface, which is a project-level change request, not a quick patch. If SAP removed the function module, replace the call with the successor API or a supported alternative rather than trying to restore the old one.

The reflex is to add or extend the EXCEPTIONS list on the CALL FUNCTION statement, expecting system_failure or communication_failure to trap it. For a static literal call this does nothing, because the runtime never reaches exception dispatch; it dumps before the interface is even checked. For a dynamic call, wrapping the statement in a blanket TRY CATCH cx_root and swallowing the exception does stop the dump, but it also silently skips whatever business step that function module was supposed to perform. The dump disappears and the process appears to succeed, while the actual defect, a missing or mis-referenced function module, is now hidden until someone notices the downstream data gap.

Enforce transport sequencing so a function module and its callers travel together or the FM lands first; a pre-go-live consistency check that verifies every function module referenced in transported objects is active in the target system catches this before cutover. Disallow direct object creation in QA or production. For dynamic calls built from configuration or customizing tables, validate the resolved name against SE37's function module directory at runtime and raise a controlled, catchable exception rather than letting the raw dynamic call fail unguarded.

Development or ABAP owns typo fixes, dynamic name construction logic, and adapting to a removed or renamed SAP function module. Basis owns RFC destination configuration and transport import sequencing across the landscape. Functional consultants own it when a configuration table or exit determines the function module name and that entry is wrong. The handover note should state the exact function module name from the dump, whether the call was static or dynamic, the destination if RFC, and confirmation of the FM's transport and activation status in each affected system.

Closely related runtime errors include CALL_FUNCTION_CONFLICT_TYPE and CALL_FUNCTION_PARM_MISSING, which occur after the function module has been found, and CALL_FUNCTION_REMOTE_ERROR and CALL_FUNCTION_SEND_ERROR, which cover failures further along in an RFC call. Relevant repository objects are the function module directory entries and the function group's generated program; relevant transactions are SE37 for the function builder, SE80 for the function group, SM59 for RFC destination testing, and SE01/SE09/SE10 for transport status.