COMPUTE_BCD_ZERODIVIDE — Division by Zero on Packed Decimal Fields

The dump means an ABAP statement attempted to divide a packed decimal number by zero, or ran a MOD operation with a zero right-hand side, and the kernel could not represent the result. Packed decimal arithmetic in ABAP does not silently return a sentinel value the way some floating point implementations do; it terminates the program with an uncaught runtime exception of class CX_SY_ZERODIVIDE. This is a catchable exception, which is exactly why the dump usually indicates a coding gap rather than a kernel defect: somewhere between the point the divisor was read and the point it was used in a division, nobody checked whether it was zero, and nobody wrapped the operation in a TRY block.

If the divisor is a legitimate business value that can be zero (empty quantity, cancelled line, zero-based group), the fix is functional: the calculation logic needs a business rule for what to do when the divisor is zero, typically skip the calculation, default the result to zero, or exclude the record, and this normally requires a change request through custom code review since it changes program behavior. If the divisor is missing or incomplete master data (unmaintained conversion factor, blank exchange rate), the immediate fix is a data correction in the source table, no code change needed, followed by a data quality check across the object type to find other incomplete records before they cause the same dump elsewhere. If the divisor comes from a copied exit or routine where a guard was dropped, the fix is a code correction restoring the check, released through the normal transport process. In all cases, wrap the division in a TRY/CATCH on CX_SY_ZERODIVIDE only as a safety net after the business rule is decided; catching without deciding what value to substitute just moves the failure downstream.

The reflex fix is to wrap the division in TRY ... CATCH cx_sy_zerodivide ... ENDTRY and let the program continue with whatever value the field held before the failed statement, usually zero or the previous loop iteration's result. This stops the dump but produces silently wrong output: a zero price, a zero cost, a skipped allocation, that nobody notices until finance or the business questions a number weeks later. It also removes the diagnostic signal, so the next time the same missing master data record causes a problem elsewhere, there is no dump to point at it.

Any division on a field sourced from configuration, master data, or an interface should be preceded by an explicit zero check with a defined fallback, not a blanket exception handler. Code review checklists for custom pricing routines, exits, and interface mapping programs should flag unguarded division operators as a mandatory finding. Where the divisor is a master data field, a data consistency report run periodically against the relevant table catches zero or blank conversion factors before they reach a live transaction.

This is an ABAP development problem when the code lacks a zero check, and a functional or master data problem when the underlying record is genuinely incomplete. Basis has no role beyond running ST22. The handover note should carry the program, include, and line number from the dump, the document or master data key that triggered it, and whether the zero divisor is expected business data or a data entry gap, since that determines whether development or the functional team owns the fix.

COMPUTE_INT_ZERODIVIDE is the equivalent dump for integer division and division by zero on non-packed numeric types; it appears alongside this dump in the same custom routines when both integer and currency fields are involved. COMPUTE_BCD_OVERFLOW arises from the same class of unguarded packed decimal arithmetic but on the overflow side rather than division. Pricing condition tables, unit-of-measure conversion tables, and any custom Z-configuration table feeding a rate or factor into a calculation are the usual data-side culprits behind the zero divisor.