A real Scalable export reinvests a distribution as -29,579989728, and the
import refused the whole file: "broker record 14 has an invalid amount, require
signed 64-bit value with at most eight fractional digits". An amount is the
row's share count times its price, so it carries as many decimal places as the
two columns together need - nine here, from six places of shares and three of
price - and scalableMoney was computing its discarded remainder by parsing the
cell through the share-count parser, whose ceiling is eight. The leaked wording
"invalid quantity" for an amount cell was the tell.
Money cells are now read at arbitrary precision, rounded to money's four places
half away from zero, and the residue is accumulated exactly and reported as a
trimmed decimal. ScalableImport.Rounding stops being a domain.Quantity, which
carried the same eight-place ceiling, and becomes the exact decimal string it
always claimed to be; the JSON shape and the review copy are unchanged.
Share counts and prices are still refused beyond their own precision instead of
rounded. Rounding a share count misstates a holding, and rounding a price would
break the shares-times-price identity that every security row's amount is
checked against.
The reported row is now covered end to end: both legs of that distribution, the
single reference the broker reuses across them surviving deduplication, the
exact 0.000010272 residue, and the dividend paid in cancelling to the cent
against the units bought with it.
Lars Nolden
cc43a2f9a7