* feat(invoices): cross-currency settlement + payment-status card
Two changes both surfaced by user feedback after PR #614:
# 1. Invoice detail page: Betalningsstatus card
The customer-invoice detail page now shows paid_amount + remaining_amount
+ the individual payment events whenever an invoice is partially_paid or
paid (was previously only a single "Paid" line on fully-paid invoices,
and nothing at all on partially_paid). Mirrors the supplier-invoice
page's payment section. Each payment row links to its verifikat.
# 2. Cross-currency match-invoice settlement
Replaces the PR #614 round-9 block (MATCH_INVOICE_CURRENCY_MISMATCH)
with proper FX-aware settlement. Flow:
1. Preview route detects tx.currency !== invoice.currency, fetches the
Riksbanken spot rate for invoice.currency on tx.date (ML 8 kap 21–23§),
and returns fx_conversion = { rate, rate_date, paid_in_invoice_currency }.
When the lookup fails it returns fx_conversion.error = 'rate_unavailable'.
2. InvoiceMatchDialog renders a new Valutaomräkning card showing the rate
+ invoice-currency-equivalent + projected post-payment state + a one-
line kursvinst/kursförlust note. When the lookup failed it swaps in
a manual-rate input the user fills from their bank statement; the
Confirm button blocks until a positive rate is supplied.
3. POST route does the same lookup (or accepts manual_exchange_rate from
the request body), then:
- paidInInvoiceCurrency = bankSek / rate (4dp precision)
- invoice.paid_amount/remaining_amount accumulate in invoice currency
- invoice_payments row records amount + currency = invoice.currency,
exchange_rate = the rate actually used (not invoice.exchange_rate)
- buildInvoicePaymentClearingLines gets paidInInvoiceCurrency so it
credits 1510 by that × invoice.exchange_rate (booking rate) and
posts the FX-diff line on 3960 (gain) or 7960 (loss)
4. buildInvoicePaymentClearingLines gains an optional fourth param. When
supplied: proportional FX-aware AR-leg + balanced FX-diff. When omitted:
pre-existing fallback (full-clear gets FX, partials defer).
The change fixes the invoice.paid_amount accumulator bug that PR #614
round-9 worked around by blocking the case entirely. Now SEK→USD
settlements actually work, with the verifikat balanced to the öre and
the GL+sub-ledger in sync per BFL 5 kap 4–5§.
Tests:
- 3 new helper tests (paidInInvoiceCurrency happy path + edge cases)
- 3 new route tests (Riksbanken happy path, lookup failure, manual rate)
- All 4321 tests pass
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(invoices): align cross-currency match preview with commit + review cleanups
Addresses PR #615 review feedback.
Preview/commit divergence (Greptile P1): preview/route.ts computed
paidAmount / isFullyPaid / useCashEntry from the raw SEK transaction.amount
before the FX conversion ran. A 1 000 SEK payment against a 140 USD invoice
made max(0, 140 − 1000) = 0 → is_fully_paid=true, so a cash-method unbooked
invoice previewed a cash entry (Dr 1930 / Cr 30xx) while the POST handler —
which converts first — commits the clearing entry (Dr 1930 / Cr 1510). The
user approved one verifikat and a different one was booked. Move the FX
lookup above the paid/remaining math so paidAmount derives from the
invoice-currency conversion, mirroring the POST handler. Rate-unavailable
stays non-fully-paid so the cash shape is never previewed on a guess.
Add a preview-route regression test (cross-currency → clearing + not
fully paid; same-currency cash path still previews the cash entry).
Cleanups:
- Bound manual_exchange_rate with .max(100000) as a sanity ceiling against
pasted/garbage input corrupting the FX-diff posting (swarm V2.3).
- Remove the invisible disabled placeholder retry button and its unused
fx_manual_rate_retry i18n keys (Greptile P2).
- Remove the now-unreachable MATCH_INVOICE_CURRENCY_MISMATCH error code
(Greptile P2 dead code; confirmed zero references).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* fix(invoices): record FX rate provenance + cover kursförlust path
Follow-up to the PR #615 review (compliance swarm V16 / SOC 2 CC6.1 /
GDPR Art.5(1)(f); Swedish accounting review).
A manually-supplied cross-currency rate is a user-controlled money-path
override of the ML 8 kap 21–23§ obligation and was indistinguishable from
an automatic Riksbanken lookup in the audit trail. Tag the resolved rate
with source: 'manual' | 'riksbanken' and:
- write a "Manuell valutakurs <rate> <ccy>/SEK (betalningsdatum …)" note
onto the existing invoice_payments.notes column when manual (BFL 5 kap
6–7§ — the verifikation must reflect the actual affärshändelse);
- record rate_source + exchange_rate in payment_match_log.new_state.
No schema change — both are existing columns/JSON.
Tests:
- cover the kursförlust (7960 Dr) branch of the cross-currency
paidInInvoiceCurrency path — previously only the 3960 gain was asserted;
- assert rate_source provenance ('manual' and 'riksbanken') reaches the
match-log new_state on both FX paths.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Jakob Wennberg
2c59c3633f