Symptom
A mapped Float value such as 1587081703043010.8 is truncated or produces a data overflow message.
An Integer near the 32-bit boundary does not fit.
The engine reports EX003016E for a numeric variable.
Cause
The variable type defines what can be represented:
Float: mantissa and exponent, with roughly 18 digits of mantissa precision.Integer: -2,147,483,648 through 2,147,483,647 (the 32-bit range).Currency: 14 places left of the decimal, 4 places right.
A 17-digit account-style number simply exceeds what Float can hold exactly, and the loss happens at mapping time.
Formatting the value with thousand separators afterwards cannot restore precision that was already gone before any formula ran.
Fix
The first question is whether the value is arithmetic at all. Long numbers that identify things (account numbers, reference numbers, transaction ids) are not calculations; map them as strings, which also preserves leading zeros.
For genuinely numeric values:
- Choose a type whose range and precision cover the source data, and validate source precision and scale before mapping.
- For currency, decide the business rule for values with more than four fractional places: round or reject, but never allow silent truncation.
- Test minimum, maximum, and boundary values through the same data-file path production uses, not through a designer preview shortcut.
When you reproduce an overflow, capture the exact EX003016E message together with the source value, so a true overflow stays distinguishable from a formatting-only defect that merely displays wrong.
Type identifiers as text before they cross the boundary
Decide whether a value is an identifier or a number in the data dictionary, not in each template. An identifier typed as numeric may work until one value crosses the precision boundary. By then the type may be embedded in formulas, sort keys, and interfaces.