* fix(reports): a transfer out is not a sale
A negative quantity is all it took to be counted as a sale. So moving an
asset to another account you own — a transfer, a sweep, an exchange —
was listed among the period's sales, and its cost basis was compared
against that day's price to book a gain nobody made. Nothing was sold and
nothing was realised.
The labels for this already exist and are already trusted elsewhere:
Transaction::INTERNAL_MOVEMENT_LABELS keeps the same four out of the
income statement, for the same reason. The investment report just never
consulted them.
Two places learn to ask. Trade#realized_gain_loss returns nil for an
internal movement, so no caller can book the gain; and the report's query
leaves those trades out, so the movement is no longer counted or listed
as a sale it never was.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013nN1GZi7Dv3d7yZUozw3Yo
* fix(reports): keep a security exchange out of the internal-movement list
Review on this PR. `Trade::INTERNAL_MOVEMENT_LABELS` aliased Transaction's,
which holds "Exchange". On cash that means a currency exchange and really is
internal. On a security the label covers "currency **or** security
exchanges" — the repo's own guide says so — and a security-for-security
exchange can dispose of an appreciated asset.
So a labelled exchange dropped out of the sales report *and*
`realized_gain_loss` returned nil for it. The gain did not move; it stopped
existing.
The two errors are not symmetrical, which is what decided this. Listing a
movement that was not a sale is visible and correctable. Erasing a realized
gain is neither — nothing on the page says a figure is missing. So the trade
list keeps only the labels that unambiguously preserve ownership, and leaves
the ambiguous one where the user can see it.
Also from review: the test asked for `period: "last_30_days"`, but the
controller reads `period_type`, so the request silently fell back to the
current month and the trades dated three days earlier dropped out of range
on the 1st to the 3rd. Confirmed with `travel_to Date.new(2026, 9, 2)`:
fails on the old parameter, passes on the new one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016GTNba5qE5NwzaHzbp27ye
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
