CONVT_OVERFLOW — CONVT_OVERFLOW runtime error diagnosis

CONVT_OVERFLOW fires when the ABAP runtime attempts a type conversion or an assignment and the target field cannot physically hold the result. This covers two distinct situations that both surface as the same dump: a character or string value longer than the receiving field's length, and a numeric value with more significant digits than the receiving numeric type supports. The exception behind it is the conversion overflow exception raised by the kernel's conversion routines during a MOVE, WRITE TO, CONCATENATE INTO, or an implicit assignment such as passing an actual parameter to a formal parameter of a shorter type. It is a hard runtime error, not a warning, so the statement terminates the program unless it sits inside a TRY block that explicitly catches the conversion exception class. The dump itself never explains why the source value got that long; that has to be reconstructed from the variable content shown in ST22.

If the target is a Z program's local field declared with a hardcoded length shorter than the source, correct the local declaration to reference the dictionary data element directly, or widen it to match; this is a code change and needs a transport through the normal change request process. If the cause is a domain or data element length extension that custom code never picked up, the fix is the same but should be checked across all callers of that structure, not just the one that dumped, since the same shortened copy is often reused elsewhere. If the numeric field is genuinely undersized for current business volume, for example a counter that has run out of digits, that is a design decision requiring functional and technical sign-off before changing the type, because it can affect number ranges, interfaces and archived data. If the root cause is bad input data feeding a standard SAP conversion routine, correct the master data or the upstream calculation and leave the standard code untouched; do not modify SAP standard objects to accommodate bad data. Interface and RFC mismatches require coordinated changes to both sides of the interface, not just the receiving program.

The reflex is to wrap the failing statement in a TRY block catching the conversion overflow exception class and doing nothing more than logging it or ignoring it. This stops the dump but does not stop the truncation: the value still does not fit, so it gets cut off or the record gets skipped, and the program continues with silently wrong or missing data. The business only discovers the damage later, often in a reconciliation report or a customer complaint, by which point the original failing input is no longer easy to trace back.

Declare local structures and work areas by referencing dictionary data elements or the original table type instead of hardcoding lengths, so a future extension of the source field propagates automatically. Run a static code check across custom programs after any field-length extension project, such as an S/4HANA conversion, specifically searching for MOVE, CONCATENATE and WRITE TO statements against fixed-length local fields. Where a TRY/CATCH around a conversion is genuinely needed, log the actual oversized value and raise a functional alert rather than swallowing the exception silently.

ABAP development owns this in the large majority of cases, since the fix is almost always a code or data element correction. Functional involvement is needed only to confirm the correct target length or number range design when a field is genuinely too small for the business volume. The handover note should state the program, include, line number, the source field's actual length and content at failure, the target field's declared length, and the master data record or transaction that triggered it.

CONVT_NO_NUMBER is the sibling dump for a value that cannot be converted to a number at all rather than one that overflows a numeric field. CONVT_CODEPAGE covers character encoding conversion failures rather than length. COMPUTE_BCD_OVERFLOW and COMPUTE_INT_PLUS_OVERFLOW cover arithmetic results too large for a numeric type, which is a closely related but distinct failure mode. ASSIGN_LENGTH_0 and DATA_OFFSET_LENGTH_TOO_LARGE both involve field-symbol or offset length mismatches and are worth checking when CONVT_OVERFLOW appears inside dynamically assigned field symbols.