* fix(transactions): stop defaulting supplier-invoice payment account to a stale private-funds setting
match-supplier-invoice (POST + preview) defaulted the credited cash account
from company_settings.last_supplier_payment_account, a sticky setting written
by the manual mark-paid "betald med privata medel" flow. Once that setting
held 2893 (skuld till aktieägare) from an unrelated private payment, every
later match against a real bank transaction reused it instead of the
transaction's actual bank account, silently booking genuine bank payments as
shareholder-loan repayments.
Resolve the credit account from the matched transaction's own
cash_account_id -> cash_accounts.ledger_account instead (falling back to 1930
when unlinked), mirroring the existing settlement-account lookup in
transactions/[id]/categorize/route.ts. last_supplier_payment_account is no
longer read by either route.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: Jonas Flodén <jonas@floden.nu>
* refactor(transactions): extract shared settlement-account resolution helper
Dedupe the identical cash_account_id -> ledger_account lookup across
match-supplier-invoice (POST + preview) and categorize into
resolveSettlementAccount, per CodeRabbit's nitpick on PR #985. Pure
extraction, no behavior change.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: Jonas Flodén <jonas@floden.nu>
* test(transactions): cover settlement-account lookup-error and preview parity gaps
Adds the two test cases CodeRabbit flagged as missing on PR #985:
- POST match-supplier-invoice: cash_accounts lookup errors, falls back to
1930 and warns (previously unexercised).
- preview match-supplier-invoice: linked cash account other than 1930
(parity with the equivalent POST-route test).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: Jonas Flodén <jonas@floden.nu>
* fix(transactions): thread resolved settlement account into FX/cash-method supplier-payment branches
Closes the remaining items from the Swedish-accounting-compliance bot
review on PR #985:
- match-supplier-invoice/route.ts computed paymentAccount via
resolveSettlementAccount but only passed it into the pure-SEK clearing
branch; the FX branch (createSupplierInvoicePaymentEntry) and
cash-method branch (createSupplierInvoiceCashEntry) still defaulted to
1930 internally even though both already accepted the parameter.
- resolveSettlementAccount now also warns (and falls back to 1930) when
cash_account_id resolves to a row with no ledger_account, not just on
a hard query error.
- Documents company_settings.last_supplier_payment_account's scope via
a column comment: it must never be read to resolve a matched
transaction's settlement account.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: Jonas Flodén <jonas@floden.nu>
* fix(bookkeeping): abort instead of silently defaulting to 1930 when settlement-account lookup errors
Compliance-bot finding on PR #987 (applies equally to #985/#986, shared
helper): resolveSettlementAccount treated "no cash_account_id" and "lookup
threw a real DB error" the same way -- warn and fall back to 1930. An
explicit cash_account_id almost certainly resolves to a non-1930 account,
so a transient failure masking it risked the exact class of misbooking
this whole PR series exists to fix, just triggered by infra flakiness
instead of a stale setting.
Now throws BookkeepingDatabaseError on a genuine query error; every
caller already runs under withRouteContext/withApiV1 (or the pending-
operations dispatcher), whose existing catch-all already converts any
isBookkeepingError() throw into the correct structured 500 -- no caller
changes needed. The "row found but ledger_account empty" case stays
warn+fallback (data-integrity gap, not a query failure).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: Jonas Flodén <jonas@floden.nu>
* test(bookkeeping): use rejects.toBeInstanceOf for settlement-account error assertion
Addresses CodeRabbit nitpick from the 2026-07-12 review round: matching
BookkeepingDatabaseError via a `constructor` key in toMatchObject is
non-idiomatic; toBeInstanceOf is the standard vitest assertion for this.
Signed-off-by: Jonas Flodén <jonas@floden.nu>
* docs: scope FX/cash-method paymentAccount gap note to /api/v1 and MCP routes
CodeRabbit flagged the #1000 reference on PR #985 as ambiguous — the main
match-supplier-invoice route's FX/cash-method branches already thread
paymentAccount (per the prior entry), so the still-open gap only applies
to the /api/v1 and MCP-facing route.
Signed-off-by: Jonas Flodén <jonas@floden.nu>
---------
Signed-off-by: Jonas Flodén <jonas@floden.nu>
Co-authored-by: Jakob Wennberg <jakob.wennberg@gmail.com>
Jonas Flodén
528c53ffe7