Skip to content

BCD_OVERFLOW

A packed decimal value exceeded the capacity of the receiving field.

The result of an arithmetic operation or an assignment produced a packed number too large to fit in the target TYPE P field. Binary Coded Decimal (BCD) is the internal representation of packed types in ABAP.

Symptom

ST22 shows:

Runtime Errors         BCD_OVERFLOW
Exception              CX_SY_ARITHMETIC_OVERFLOW
Short text             Overflow in packed number arithmetic.

The dump line is the arithmetic statement or assignment that produced the overflow.

Cause

TYPE P fields have a fixed maximum value determined by their byte length and decimal places. A field declared as TYPE P LENGTH 8 DECIMALS 2 can hold at most 15 digits before the decimal point. Common triggers:

  • Multiplying two P fields whose result exceeds the target field's capacity.
  • Assigning a large TYPE I or TYPE INT8 value to a small TYPE P field.
  • Accumulating a sum in a loop where the total grows beyond the field definition.
  • A BAPI or FM returning a value larger than expected.

Reproduce

DATA lv_amount TYPE p LENGTH 4 DECIMALS 2.  " max 7 digits: 99999.99

lv_amount = '9999999.99'.   " <-- BCD_OVERFLOW

Arithmetic variant:

DATA: lv_a TYPE p LENGTH 8 DECIMALS 2 VALUE '9999999999999.99',
      lv_b TYPE p LENGTH 8 DECIMALS 2 VALUE '2',
      lv_result TYPE p LENGTH 8 DECIMALS 2.

lv_result = lv_a * lv_b.   " result requires 16 digits — overflow

Fix

" Before — overflow with large values
DATA lv_total TYPE p LENGTH 4 DECIMALS 2.

" After — increase length
DATA lv_total TYPE p LENGTH 16 DECIMALS 2.

" DECFLOAT34 supports up to 34 significant digits
DATA lv_total TYPE decfloat34.

lv_total = lv_a * lv_b.   " no overflow for typical financial values

DATA lv_result TYPE p LENGTH 8 DECIMALS 2.

TRY.
    lv_result = lv_a * lv_b.
  CATCH cx_sy_arithmetic_overflow INTO DATA(lx).
    MESSAGE lx->get_text( ) TYPE 'E'.
ENDTRY.

Check the DDIC type definition first

Before increasing the field length in your program, check whether the field is tied to a DDIC data element. If so, change the domain length in SE11 so all programs using that element benefit from the fix consistently.

Prevention

  • Define TYPE P fields with generous length from the start — storage overhead is minimal.
  • For financial totals that accumulate over many records, use DECFLOAT34 or verify the maximum possible sum against the field definition.
  • Add unit tests with boundary values (maximum expected amount) to catch overflow before production.

See also

Comments