Post the Change data value details here (click the ID in the activity log to get it). The concomitance with the lead creation event is troubling.
The reason in the screen says that it was a manual edit, nothing automated. What's weird is that the value entered and shown in the activity is not rounded.
Can you try to enter a non rounded number again on the lead and see whether the problem remains ?
Also, also the question is simplistic, but I need to ask Are you sure that you are displaying all the activities in the log ?
In any case, it seems to be worth a ticket to the support.
Same issue. Looks like it starts rounding at the 1M mark. It also rounds down from some of the updates I've been doing. For example, 9328091 rounds to 9328090.
This is a new record that I manually created just to test this so there are no activities on it, just these CDV's that I've been doing.
As if it was only able to manage 6 digits and round the rest.
I observe exactly the same thing on my sandbox, rounded at the 6th digit:
in the log:
after refreshing the lead detail screen:
Call support in, and keep us posted, it's a bug.
You can add a link to this conversation in your ticket.
Just so you're all aware, I noticed this happening in the Amount and Expected Revenue fields in Opportunity a few months ago. I shrugged it off then as it didn't have a material impact for us.
Seems like the rounding issue only affects currency fields?
This is actually a bit more sinister (it's a definite bug) than just rounding.
It also involves floating-point approximation, and there really isn't any reason for it to be kicking in for what appear to be whole Integers of just a few million or billion.
A Currency type field, based on what we know of its upper and lower bounds, is a Float, not an exact value. But it's not just an everyday Float, since it gets rounded in 2 different ways, and potentially in 2 different directions from the original value:
By "display", I mean that the Marketo UI doesn't actually reflect the stored value. For example, 932850001 will be displayed as 932850000 in the UI but stored as 932849980 (which you can verify via the API) So the displayed and stored values diverge in different ways from the originally entered value.
In any case, the cause must be that the fields that we think are low-ish Integers are being multiplied or divided in enough separate steps that floating-point approximation kicks in. And once it kicks in, you can't reverse it to find the original value (that's a fact of Floats). In a non-buggy scenario you don't have to worry about approximation until you exceed 9,007,199,254,740,991 (that's over 9 quadrillion). Obviously the numbers that are proving the bug here are much lower than that, so some steps behind the scenes must be raising them well beyond the safe magnitude before attempting to bring them back.
It is an expected behavior and the issue is explained in the below document Currency type field is rounding off its value.
Annual revenue field is also of type "Currency"
Also, this isn't "rounding" in the generally accepted meaning of the term. It's lossy fp math.
.1 + .2 = 0.30000000000000004
we don't typically say that's "rounding" because for most people it appears to be a bizarrely failed attempt to gain accuracy, not a predictable loss of accuracy.