CALL_FUNCTION_PARM_MISSING — CALL_FUNCTION_PARM_MISSING Dump Analysis

CALL_FUNCTION_PARM_MISSING is a runtime termination raised when the kernel binds the actual parameters of a CALL FUNCTION statement to the current formal interface of the target function module and finds a mandatory parameter with no value supplied, or finds the caller referencing a parameter that no longer exists on the target side. This binding check runs before the function module's own code executes, so nothing inside the function body is at fault; the mismatch is purely between what the caller passes and what the callee's interface, as currently defined in the system being called, requires. For local calls this means the interface changed since the caller was compiled or generated. For remote calls through an RFC destination it means the two systems hold different versions of the same function module. The dump is not catchable through the normal EXCEPTIONS addition because the violation is detected outside the function module's execution.

In descending order of how often each actually turns up in a live system.

Read the dump top to bottom before touching any code.

If a custom function module gained a new mandatory parameter, the cleanest fix is to make it optional with a sensible default at the interface level, or adjust every caller found in the where-used list to supply it, and transport the function module and its callers in the same request; this requires a change request and a coordinated transport. If the mismatch is an RFC call between systems on different releases, align the destination's target version with the calling program's expectation, or make the newer parameter optional so older callers keep working; this needs changes on both systems, not a workaround on one side alone. If a dynamically built parameter table is the cause, fix the generation logic to always populate mandatory entries, defaulting the value when the caller has nothing meaningful to send, and retest every caller of the dynamic builder. If transport sequencing is the cause, re-import in the correct order or, going forward, bundle the interface change and every caller adjustment into a single transport request so they cannot land out of order again.

The reflex is to wrap the CALL FUNCTION statement in EXCEPTIONS OTHERS = 1 or in a TRY and CATCH block, expecting the dump to become a handled exception. It does not. The interface binding check happens before the function module's own body, and before any catchable exception logic inside it, is reached, so PARM_MISSING is not one of the system exceptions listed in the EXCEPTIONS addition and not a class-based exception raised from within the function. The program terminates at the exact same line as before, the added handling code is dead weight, and the actual mismatch between what the caller sends and what the interface now requires is never touched.

Treat every function module interface, and especially remote-enabled ones, as a contract: never add a mandatory parameter to an existing signature, always add new parameters as optional with a default value so existing callers keep working unchanged. Before changing an interface, run the where-used list and update every caller in the same transport request. For cross-system RFC scenarios, document each destination with the release of the target system and retest the call after any support package upgrade on either side of the connection.

ABAP development owns the fix, since the root cause is a mismatch between caller code and callee interface, both under development control. Basis involvement is limited to confirming the RFC destination's target system and release when the call crosses systems. The handover note should state the function module name, the exact missing parameter, the calling program and line number, whether the call is local or remote with the destination name, and the release of both systems if remote.

Sits alongside the other members of the call-function interface-mismatch family: CALL_FUNCTION_NOT_FOUND when the target module does not exist at all on the callee, CALL_FUNCTION_CONFLICT_TYPE and CALL_FUNCTION_CONFLICT_LENG when a parameter exists but its type or length disagrees, and CALL_FUNCTION_REMOTE_ERROR and CALL_FUNCTION_SEND_ERROR for failures in the communication layer of the same RFC call. All are detected during the same interface-binding step before the target function module's own logic runs.