finance-duck

25 Commits 1 Branch 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
Lars Nolden	762ad3fae5	Import Trade Republic exports, whose conventions invert Scalable's A second broker export is recognized locally, by its full column set, and read through the same pipeline: detection and parsing now dispatch on the format, so the upload path, the review dialog, deduplication, the journal and the Wealth report are unchanged. Its nine row types cover cash transfers, interest, dividends, tax settlements and trades in funds, shares and crypto; none of them moves a position without moving cash, so the cash-neutral class that Scalable's corporate actions belong to does not arise here. Three of its conventions are the opposite of the export already supported, and reading any of them the other way round moves money. Fee and tax are the signed adjustments it made to the cash rather than deductions from a gross, so a one euro order fee arrives as -1.00 and is negated at import; the journal keeps one convention and the domain never learns that two exist. A cash row's amount is the gross, not the net, so interest of 16.46 with -4.33 of tax credits 12.13 - where the other export states its cash already net and its tax is recorded and never applied. Whether a cash row carries a gross now decides which of those it was, which also makes the first kind's settlement checkable and stops the Wealth report from claiming a figure was left unapplied when it was not. And a TAX_OPTIMIZATION row puts zero in the amount column and its money in the tax column, signed both ways: read as cash, all six in a real export move nothing. Two more rows lie about their own columns. A dividend fills the share column with the holding the dividend was paid on, not with a position change, so adding it would double the holding. Crypto carries a bare ticker in the symbol column and its ISIN-shaped identifier only in the description, so the identifier is taken from the symbol when that is an ISIN and otherwise from the one the description names; a position row resolving to neither is refused rather than attached to a guess. The shares-times-price check now holds a gross to the precision the export stated it at rather than to four places. This export prints the notional rounded to cents, and 29 of 59 real trades do not land on a whole cent: demanding exactness rejected half a portfolio. One unit of the stated precision is still four orders of magnitude tighter than the misplaced separator the check exists to catch, and where an export prints the full product the check stays exact. A unit price moves from money to the eight-place quantity type, because a crypto price is quoted to six and rounding it would break the check the amount is verified against. Trailing zeros are dropped before any precision test: this export pads a six-place price to ten, and the padding would otherwise exhaust the precision the value needs. A transfer's counterparty comes from the export's own IBAN column when it has one, from the IBAN the description names in parentheses when it does not, and from the account's configured settlement IBAN when neither names anything. Free text contributes only a value shaped like an IBAN. Without this, 108 transfers stay unpaired and their bank-side counterparts read as spending and income. Verified end to end against a real export: 26 rows import to a cash balance of 32187.02 matching the figure computed by hand from the source rows, all four positions close at exactly zero, and every trade satisfies its own arithmetic.	2026-09-11 23:04:22 +02:00
Lars Nolden	cc43a2f9a7	Read broker amounts at the precision the export actually uses 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.	2026-09-11 22:29:47 +02:00
Lars Nolden	922ae507bd	Track investments as broker facts with a position leg An account now has a kind, and an investment account holds positions as well as cash. A broker row is not a new entity: it is a bank fact with an optional position leg, so deduplication, the journal, fact immutability, the DuckDB projection and the transactions view carry it unchanged. Facts.Amount stays the cash leg and is zero on the rows that move only a position. Scalable Capital exports are recognized locally as a fourth format, read by their own parser because a column mapping cannot describe them: the amount column is settled cash on a cash row, a gross to be netted on a trade, and a position valuation that must never touch cash on a corporate action or a depot transfer. A cash amount is already net of the tax the broker withheld or refunded, so that tax is recorded on the fact and never subtracted a second time; treating a corporate action's valuation as money conjures cash, and a depot switch would do it once per instrument. The share column is signed only for those two types, so buys and sells take their direction from the type. Every security row is checked against shares times price at 128-bit width, because a lost decimal separator survives every other check. An unknown status, type or assetType, a foreign currency, a missing ISIN, or one failed check rejects the whole file with the record number. Instruments live in instruments.finance, keyed by ISIN with an ID derived from it, so re-importing never registers a security twice. One ISIN appears under several broker descriptions over the years and sometimes under the ISIN itself: the most recent real description names it, and an import never renames one that already exists. A broker also reuses a single reference across every leg of one event, so transaction identity includes the event and its instrument. domain.Fallback returns kind "investment" for any fact carrying a position leg, so no broker row reaches the sign-based branch. That single rule is what stops an unmatched deposit from counting as income and a broker fee from counting as household spending; the monthly PRIME fee and its matching credit now cancel in clearing:investments with no configuration at all. Investment rows are excluded from spending analytics, from bulk reclassification and from the model, exactly as transfers are. Equal competing transfers are paired instead of skipped. Every connected component of the candidate graph is a complete bipartite graph between two fixed accounts at one amount and currency, so every pairing produces the same accounts, kinds and postings and only the displayed counterpart differs. Refusing to choose was the expensive option: both legs fell through to the sign-based fallback and appeared as spending and income that never happened. Pairing follows the nearest booking date, then the transaction ID, so iteration order decides nothing. POST /api/transactions/{id}/transfer rewrites the old and the new pair in one commit, because reciprocity is validated and a half-applied link is an invalid dataset, and the matcher now skips any record classified manually so a hand-made link or unlink outlives the next import. Wealth reports each account's cash and positions from the journal rather than the index, with named checks - row arithmetic, cash never negative, holdings never negative - because it exists to be compared against the figures a broker shows on its own screen. A negative holding means the imported history is partial. Share counts are exact to eight places; a reinvested distribution quoted to six is rounded to money's four and the residue is reported rather than hidden. Market prices, market value, net worth over time, FIFO lot accounting, realised gains and currency conversion are deliberately absent.	2026-09-11 21:58:47 +02:00

Author

SHA1

Message

Date

Lars Nolden

762ad3fae5

Import Trade Republic exports, whose conventions invert Scalable's

A second broker export is recognized locally, by its full column set, and read
through the same pipeline: detection and parsing now dispatch on the format, so
the upload path, the review dialog, deduplication, the journal and the Wealth
report are unchanged. Its nine row types cover cash transfers, interest,
dividends, tax settlements and trades in funds, shares and crypto; none of them
moves a position without moving cash, so the cash-neutral class that Scalable's
corporate actions belong to does not arise here.

Three of its conventions are the opposite of the export already supported, and
reading any of them the other way round moves money. Fee and tax are the signed
adjustments it made to the cash rather than deductions from a gross, so a one
euro order fee arrives as -1.00 and is negated at import; the journal keeps one
convention and the domain never learns that two exist. A cash row's amount is
the gross, not the net, so interest of 16.46 with -4.33 of tax credits 12.13 -
where the other export states its cash already net and its tax is recorded and
never applied. Whether a cash row carries a gross now decides which of those it
was, which also makes the first kind's settlement checkable and stops the Wealth
report from claiming a figure was left unapplied when it was not. And a
TAX_OPTIMIZATION row puts zero in the amount column and its money in the tax
column, signed both ways: read as cash, all six in a real export move nothing.

Two more rows lie about their own columns. A dividend fills the share column
with the holding the dividend was paid on, not with a position change, so adding
it would double the holding. Crypto carries a bare ticker in the symbol column
and its ISIN-shaped identifier only in the description, so the identifier is
taken from the symbol when that is an ISIN and otherwise from the one the
description names; a position row resolving to neither is refused rather than
attached to a guess.

The shares-times-price check now holds a gross to the precision the export
stated it at rather than to four places. This export prints the notional rounded
to cents, and 29 of 59 real trades do not land on a whole cent: demanding
exactness rejected half a portfolio. One unit of the stated precision is still
four orders of magnitude tighter than the misplaced separator the check exists
to catch, and where an export prints the full product the check stays exact.

A unit price moves from money to the eight-place quantity type, because a crypto
price is quoted to six and rounding it would break the check the amount is
verified against. Trailing zeros are dropped before any precision test: this
export pads a six-place price to ten, and the padding would otherwise exhaust
the precision the value needs.

A transfer's counterparty comes from the export's own IBAN column when it has
one, from the IBAN the description names in parentheses when it does not, and
from the account's configured settlement IBAN when neither names anything. Free
text contributes only a value shaped like an IBAN. Without this, 108 transfers
stay unpaired and their bank-side counterparts read as spending and income.

Verified end to end against a real export: 26 rows import to a cash balance of
32187.02 matching the figure computed by hand from the source rows, all four
positions close at exactly zero, and every trade satisfies its own arithmetic.

2026-09-11 23:04:22 +02:00

Lars Nolden

cc43a2f9a7

Read broker amounts at the precision the export actually uses

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.

2026-09-11 22:29:47 +02:00

Lars Nolden

922ae507bd

Track investments as broker facts with a position leg

An account now has a kind, and an investment account holds positions as well as
cash. A broker row is not a new entity: it is a bank fact with an optional
position leg, so deduplication, the journal, fact immutability, the DuckDB
projection and the transactions view carry it unchanged. Facts.Amount stays the
cash leg and is zero on the rows that move only a position.

Scalable Capital exports are recognized locally as a fourth format, read by
their own parser because a column mapping cannot describe them: the amount
column is settled cash on a cash row, a gross to be netted on a trade, and a
position valuation that must never touch cash on a corporate action or a depot
transfer. A cash amount is already net of the tax the broker withheld or
refunded, so that tax is recorded on the fact and never subtracted a second
time; treating a corporate action's valuation as money conjures cash, and a
depot switch would do it once per instrument. The share column is signed only
for those two types, so buys and sells take their direction from the type. Every
security row is checked against shares times price at 128-bit width, because a
lost decimal separator survives every other check. An unknown status, type or
assetType, a foreign currency, a missing ISIN, or one failed check rejects the
whole file with the record number.

Instruments live in instruments.finance, keyed by ISIN with an ID derived from
it, so re-importing never registers a security twice. One ISIN appears under
several broker descriptions over the years and sometimes under the ISIN itself:
the most recent real description names it, and an import never renames one that
already exists. A broker also reuses a single reference across every leg of one
event, so transaction identity includes the event and its instrument.

domain.Fallback returns kind "investment" for any fact carrying a position leg,
so no broker row reaches the sign-based branch. That single rule is what stops
an unmatched deposit from counting as income and a broker fee from counting as
household spending; the monthly PRIME fee and its matching credit now cancel in
clearing:investments with no configuration at all. Investment rows are excluded
from spending analytics, from bulk reclassification and from the model, exactly
as transfers are.

Equal competing transfers are paired instead of skipped. Every connected
component of the candidate graph is a complete bipartite graph between two fixed
accounts at one amount and currency, so every pairing produces the same
accounts, kinds and postings and only the displayed counterpart differs.
Refusing to choose was the expensive option: both legs fell through to the
sign-based fallback and appeared as spending and income that never happened.
Pairing follows the nearest booking date, then the transaction ID, so iteration
order decides nothing. POST /api/transactions/{id}/transfer rewrites the old and
the new pair in one commit, because reciprocity is validated and a half-applied
link is an invalid dataset, and the matcher now skips any record classified
manually so a hand-made link or unlink outlives the next import.

Wealth reports each account's cash and positions from the journal rather than
the index, with named checks - row arithmetic, cash never negative, holdings
never negative - because it exists to be compared against the figures a broker
shows on its own screen. A negative holding means the imported history is
partial. Share counts are exact to eight places; a reinvested distribution
quoted to six is rounded to money's four and the residue is reported rather than
hidden. Market prices, market value, net worth over time, FIFO lot accounting,
realised gains and currency conversion are deliberately absent.

2026-09-11 21:58:47 +02:00