DYNPRO_NOT_FOUND — DYNPRO_NOT_FOUND runtime error

DYNPRO_NOT_FOUND fires when a CALL SCREEN, SET SCREEN, or implicit screen navigation (menu exit, LEAVE TO SCREEN, table control paging) resolves to a program and screen number pair that the runtime cannot locate in the client the user is working in. A dynpro is a generated object with its own load, separate from the ABAP source; the source can compile and the transaction can start, and the error only appears the moment that specific screen number is actually requested. This is why it often surfaces only for one menu path, one batch input recording, or one specific customer/company code combination that drives a dynamic screen number, while the rest of the transaction works normally.

If the screen is genuinely missing from the target client because of an incomplete transport, identify the source system where the screen exists, add the screen object explicitly to a new transport request, and release and import it; this requires a change request through the normal transport process, it is not something fixed by a config change. If the screen was deleted or renumbered on purpose and the call site is stale, correct the CALL SCREEN or SET SCREEN statement, or the transaction's screen assignment in SE93, to point at the current number; this is an ABAP code correction and needs its own transport. If a dynamically built screen number is wrong, trace the customizing or exit logic that constructs it, fix the source data or the case logic, and add a defensive check so an unresolved value never reaches CALL SCREEN. If the cause is a batch input session built against an old screen sequence, the session itself is unusable and must be recreated against the current transaction flow rather than repaired.

The common first move is to re-run the transaction, or ask the user to log off and log back in, on the theory that it is a buffer glitch. It sometimes appears to work if the screen was present in a buffer from another client or an earlier session, which just delays the recurrence. The other frequent reflex is to open SE51 and hit activate on the program's screens without first confirming which screen number is actually missing; if the real gap is in the transport, activating locally fixes the one system being looked at and leaves every other system in the landscape with the same defect.

Always transport the full object list for a program change, including all screens, and use the transport organizer's object list check rather than manually picking objects. Avoid building screen numbers from customizing tables or string concatenation without a validation step that confirms the resulting number exists before CALL SCREEN is issued; a static lookup table with only known-valid numbers is safer than free construction. Run a consistency check between development and production screen objects as part of release testing, not just the program source.

ABAP development owns this dump in nearly all cases, since the fix is either a code correction or a transport correction tied to development objects. Basis is only involved if the transport itself fails to import or the client is not properly set up. The handover note should state the exact program and screen number from the dump, whether the screen exists in the source system, and which transport request last touched that program's screens.

DYNPRO_NOT_FOUND sits in the same family of missing-object runtime errors as CALL_FUNCTION_NOT_FOUND, which fires for a missing function module the same way this fires for a missing screen, and both are usually transport or renumbering problems rather than data problems. It is frequently the underlying cause behind a generic UNCAUGHT_EXCEPTION or a custom RAISE_EXCEPTION wrapper if the calling program catches dialog errors and re-raises them without preserving the original screen detail, which is why the raw dump should always be read before trusting a wrapped error message.