nikolaandClaude Opus 5
ebf7770569
The boolean transfer flag went two commits ago because a one-sided verdict let half a movement vanish and left the report unbalanced. This is what replaces it: a [[transfer]] block names both legs, and only a matched pair is dropped from the report -- both legs together, never one. Legs pair within five days, nearest date first, and a transaction belongs to at most one transfer, so the first definition to claim a leg keeps it, exactly as the first matching rule keeps a tag. The pairing is derived state like the tags: Engine.Link rewrites the whole transfers table from rules.toml, which is why retag re-derives both halves of what that file decides, and why it runs over the whole index rather than a filtered view -- pairing inside one would let a movement count as a transfer in one report and not in another. An unmatched leg is not a transfer and keeps counting, surfaced as a warning instead. Within one currency the amount is the evidence and must be the exact opposite. Across currencies it is not checked at all: there are no rates here, so the two numbers are unrelated and the dates carry the pairing alone. tolerance_pct is the one exception, per definition, for a route where the bank takes a fee and the two statements genuinely disagree. It defaults to zero and belongs on the one definition that charges; a global or default tolerance would loosen every route that does not. The difference it admits is not forgiven -- the pair leaves the report entirely, so a fee hidden inside one would be spending that appears nowhere. Pair.Fee is what left less what arrived, and report.Excluded carries it out per currency alongside the legs. It counts only pairs whose legs are both in view, for the same reason it counts legs and not transfers: half a pair cannot say what the other half received. The screens: - 6 builds a definition against the index as you type, showing the pairs it would form and the legs it would catch but leave unpaired. Six fields need more room than the rule builder's four, so the form sheds its spacing, then its hints, then the borders on unfocused fields. - 7 lists every definition with what it pairs. Two counts, because they mean different things: an unpaired leg is a definition doing something and not finishing it, no pairs at all is dead weight. Tol names the tolerance, blank where amounts must agree. - 3 grows a (transfers) row under TOTAL, and a fees row beneath it, or the report silently disagrees with the account balances. Two things that are not part of transfers but are the same day's work: - ls --uniq lists each account and description once, normalised the way a glob sees them, which is the shape of "what still needs a rule?" -- fifty visits to one shop are one pattern to write, not fifty rows to read. - The rule builder's preview now filters to what the glob matches instead of marking matches in a full list. The count carries the context the rows no longer can: 2 of 7, measured against everything still in view. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
82 lines
2.5 KiB
Go
82 lines
2.5 KiB
Go
package main
|
|
|
|
import (
|
|
"strings"
|
|
"testing"
|
|
|
|
"git.petrovv.com/nikola/money/internal/model"
|
|
)
|
|
|
|
func txn(account, desc string) model.Transaction {
|
|
return model.Transaction{AccountSlug: account, Description: desc}
|
|
}
|
|
|
|
func uniqOutput(t *testing.T, limit int, txns ...model.Transaction) string {
|
|
t.Helper()
|
|
var b strings.Builder
|
|
if err := printUniq(&b, txns, limit); err != nil {
|
|
t.Fatal(err)
|
|
}
|
|
return b.String()
|
|
}
|
|
|
|
// The point of the listing is one row per pattern still to write, so fifty
|
|
// visits to one shop must not be fifty rows.
|
|
func TestUniqCollapsesRepeats(t *testing.T) {
|
|
out := uniqOutput(t, 0,
|
|
txn("checking", "LIDL SOFIA 4412"),
|
|
txn("checking", "LIDL SOFIA 4412"),
|
|
txn("checking", "ZARA"),
|
|
)
|
|
if n := strings.Count(out, "LIDL SOFIA 4412"); n != 1 {
|
|
t.Errorf("the shop appears %d times, want once:\n%s", n, out)
|
|
}
|
|
if !strings.Contains(out, "2 distinct descriptions") {
|
|
t.Errorf("count is wrong:\n%s", out)
|
|
}
|
|
}
|
|
|
|
// Descriptions are printed as a glob sees them, so two statements differing
|
|
// only in spacing or case are the one pattern they really are -- and what is
|
|
// printed is exactly what a rule written from it will match.
|
|
func TestUniqNormalisesLikeAGlob(t *testing.T) {
|
|
out := uniqOutput(t, 0,
|
|
txn("checking", "Lidl Sofia 4412"),
|
|
txn("checking", "LIDL SOFIA 4412"),
|
|
)
|
|
if !strings.Contains(out, "LIDL SOFIA 4412") {
|
|
t.Errorf("want the normalised description:\n%s", out)
|
|
}
|
|
if !strings.Contains(out, "1 distinct descriptions") {
|
|
t.Errorf("spacing and case should not make a second row:\n%s", out)
|
|
}
|
|
}
|
|
|
|
// The same description on two accounts is two rows: a rule can be scoped to an
|
|
// account, and the two may well want different tags.
|
|
func TestUniqKeepsAccountsApart(t *testing.T) {
|
|
out := uniqOutput(t, 0,
|
|
txn("checking", "TRANSFER"),
|
|
txn("savings", "TRANSFER"),
|
|
)
|
|
if !strings.Contains(out, "2 distinct descriptions") {
|
|
t.Errorf("want a row per account:\n%s", out)
|
|
}
|
|
}
|
|
|
|
// The limit caps the rows printed, and says so, rather than silently cutting
|
|
// the list down to a number that looks complete.
|
|
func TestUniqLimitReportsWhatItHeldBack(t *testing.T) {
|
|
out := uniqOutput(t, 1,
|
|
txn("checking", "ZARA"),
|
|
txn("checking", "LIDL"),
|
|
)
|
|
if !strings.Contains(out, "1 of 2 distinct descriptions") {
|
|
t.Errorf("want the total alongside the limit:\n%s", out)
|
|
}
|
|
// Alphabetical within an account, so near-identical wordings land together.
|
|
if !strings.Contains(out, "LIDL") || strings.Contains(out, "ZARA") {
|
|
t.Errorf("want the first row alphabetically:\n%s", out)
|
|
}
|
|
}
|