The page lists documents, so a purchase with no document at all could not
appear on it. That is precisely the gap the receipt hunt exists to close,
and the half a user can do something about: fetch the invoice from the
supplier's portal, or ask whoever made the purchase.
GET /purchases supplies it, read-only, with the portal link attached when
the directory knows where that supplier keeps its invoices. Salary and tax
get no link: they have no invoice to fetch, and a link there implies
somewhere to go.
The predicate moves into lib/transactions/purchases-without-underlag.ts,
and it is not the hunt's filter copied across. `journal_entry_id IS NULL`
is not the same as "not booked": bulk-booking many transactions onto one
verifikat records it in transaction_voucher_links, and a payment split
across invoices records it in the payment tables, and both leave that
column null. The hunt tolerates the false candidate because the worst case
is a proposal nobody accepts. A list shown to a person does not: those
rows would sit under "saknar underlag" forever, already booked, with
nothing the user could do to clear them.
So the column filter stays as the cheap indexed first pass and
isTransactionBooked settles it afterwards. That predicate is canonical and
nothing here re-implements it.
The hunt is deliberately not rewired in this change: its query is
identical apart from that check, but moving a nightly cron onto new code
belongs in its own PR. The thresholds are kept equal to the hunt's so the
two cannot drift meanwhile.
Removing the booked filter fails five of the seven predicate tests.
Co-authored-by: Jakob Wennberg <311770904+jakobwennberg-oss@users.noreply.github.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Jakob Wennberg
a004990041