CX_SY_CONVERSION_NO_NUMBER — CX_SY_CONVERSION_NO_NUMBER dump analysis
CX_SY_CONVERSION_NO_NUMBER is the class-based runtime exception raised when ABAP tries to convert a character string into a numeric type and the string does not represent a valid number. It surfaces in ST22 as an uncaught exception, usually triggered by a MOVE, computation, or CONV expression acting on dirty interface data, bad user input, or a dynamically typed field that was never validated before the conversion.
This page covers what triggers CX_SY_CONVERSION_NO_NUMBER, ranked by real-world frequency, and how to read the specific ST22 fields that point at the offending statement and value. It also covers the branching resolution path by root cause, the reflex fix that hides bad data instead of fixing it, and who owns the follow-up.
Published 16 Sept 2026· 1,222 words
What the dump means
This is the class-based equivalent of the old CONVT_NO_NUMBER runtime error. It fires whenever ABAP's implicit or explicit type conversion tries to interpret a character-type value as a number and fails because the string contains something that is not a digit, sign, or decimal separator in the position the kernel expects. It happens on MOVE, on arithmetic between a character field and a numeric field, on CONV or EXACT expressions, and on CONVERT statements. Unlike the classic runtime error, this exception is catchable with TRY...CATCH, so its appearance in ST22 as an unhandled dump means nobody in the call stack put a handler around the conversion, not that the language forced an abrupt stop the way the old-style error did. The dump itself is filed under UNCAUGHT_EXCEPTION with this class named in the error analysis.
Root causes that actually produce it
- Dirty interface data: a field arriving through an IDoc segment, a flat file upload, a BAPI table parameter, or a REST/OData payload contains letters, embedded spaces, or stray punctuation in a position mapped to a numeric internal table field. This is the single most common cause and almost always traces back to source data quality, not ABAP logic.
- User input on a selection screen or dynpro field typed as character but expected to hold a number, submitted with trailing text, a currency symbol, or a decimal separator that does not match the user's decimal notation setting.
- Thousand-separator or decimal-notation mismatch between the string format the program assumes and the actual user master decimal notation, so a value like one comma five hundred is parsed as garbage rather than as fifteen hundred.
- Dynamic programming without validation: field symbols assigned via ASSIGN COMPONENT, generic RTTI-based reports, or table-driven frameworks that move a value into a dynamically typed target without a prior check, so the static type checker never gets a chance to catch it.
- Blank or empty string treated as numeric: a field that is entirely spaces or an empty string is moved into a packed or integer field without a CONDENSE or IS INITIAL check first.
- Legacy custom code doing string concatenation to build a number before conversion, for example building a date or amount string manually and then converting it, where an off-by-one substring slices the wrong characters.
- Batch input or call transaction sessions replaying old data against a program whose field lengths or formats have since changed, so previously valid values no longer parse.
What to inspect in ST22
- Runtime error name at the top: confirms UNCAUGHT_EXCEPTION with CX_SY_CONVERSION_NO_NUMBER as the exception class, which tells you no TRY block in the call stack caught this specific type.
- Information on where terminated: gives the exact program, include, and line number of the failing statement, usually a MOVE, COMPUTE, or CONV expression.
- Source code extract: shows the statement in context, which usually names the source variable and target field directly, telling you the field's type and origin without further digging.
- Active calls and local data in the call stack: expand the frame at the point of failure and inspect the actual content of the offending variable, this is the fastest way to see the literal bad string that caused the failure.
- Container information if the exception carries structured data, some system exceptions expose the offending value directly as an attribute of the exception object.
- Trace the caller upward through the call stack to identify whether the value came from a batch job, an RFC call, a web service, or a dialog transaction, since that determines who owns the fix.
Resolution path
If the cause is inbound interface data, correct the value at the source system if possible, and add a validation or cleansing step in the mapping layer so malformed values are rejected or defaulted before they reach the conversion statement; this requires a change request in the interface program or middleware mapping. If the cause is user input, add a regex or CL_ABAP_MATCHER check on the screen field before the program attempts conversion, and give the user a proper error message instead of letting the runtime fail; this is a code change to the dynpro or selection screen logic. If the cause is dynamic programming, wrap the conversion in TRY...CATCH INTO a variable typed as CX_SY_CONVERSION_NO_NUMBER or its superclass CX_SY_CONVERSION_ERROR, and decide a defined fallback rather than letting the exception propagate; this is a mandatory code change, not a workaround. If the cause is a decimal notation mismatch, check the user's master record decimal notation setting first, since this can sometimes be fixed without any code change at all, but if the program hardcodes a format assumption, the parsing logic needs to respect the user's setting explicitly.
The fix people try first (and why it fails)
The reflex is to slap a blanket TRY...CATCH INTO cx_root or cx_sy_conversion_no_number around the failing line and do nothing in the CATCH block, or to default the target field to zero and move on. This makes the dump disappear but silently drops or corrupts the record instead of fixing the data quality problem. In a batch job this means some line items are posted with a zero value nobody notices until reconciliation, and in an interface it means the sending system's bad data keeps flowing in unflagged, so the same defect resurfaces downstream as a wrong balance or missing document rather than a clean, traceable dump.
Prevention
Require explicit validation before any conversion of externally sourced character data into numeric fields, using a regex check or CL_ABAP_MATCHER, as a coding standard for interface and batch input programs. Where TRY...CATCH is used, catch the specific exception class rather than CX_ROOT, and log the rejected value with enough context to trace it back to the source record. Add boundary-value unit tests for any custom conversion routine that handles user-entered or externally sourced strings, covering blanks, embedded text, and both decimal notations.
Whose problem this is
Primarily an ABAP development issue, since the fix is almost always a code change adding validation or exception handling. Functional involvement is needed to identify why the source data is malformed, particularly for interface and IDoc scenarios. Basis is rarely involved unless the failure is inside a mass batch job affecting system throughput. The handover note should include the program, include, and line from ST22, the literal offending value, and the calling transaction, job, or interface that supplied it.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-abap-dumps/cx-sy-conversion-no-numberERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.