fix(underlag): a verifikat a customer invoice points at is backed by it; PS follows the invoice link (#2298) (#2347)

* fix(underlag): a verifikat a customer invoice points at is backed by it; PS follows the invoice link (#2298)

The invoice-to-verifikat link is written on the invoice side only
(invoices.journal_entry_id, invoice_payments.journal_entry_id), while the
missing-underlag predicate and the periodisk sammanstallning resolved the
invoice from the entry's own source columns. A SIE-imported sale matched to
its invoice afterwards therefore kept warning "Underlag saknas" and was left
out of the EU sales list, although the account-based momsdeklaration showed
it and the verifikat page already listed the invoice as its underlag.

- verifikat_without_documents / transactions_without_documents: customer-
  invoice hanvisning arm (BFL 5 kap 7 §), tenant-scoped on the link row;
  new migration 20260906135702, pinned by a pg-real test.
- getInvoiceReferencesForJournalEntries(): one TS mirror of that arm, used
  by the journal-list filter and bulk exempt, /api/documents/counts (new
  invoice_references map) and the transactions list; the push cron mirrors
  it with its global reads.
- Journal list: no "Underlag saknas" chip for a covered entry, matching
  the engine's own invoice rows and the verifikat detail page.
- Periodisk sammanstallning: entries fetched by their EU-revenue lines and
  attributed through every link (engine source_id, invoices.journal_entry_id,
  invoice_payments.journal_entry_id); kontantmetod invoice_cash_payment
  entries are filed too, which the old source_type filter dropped.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019SaJfqNi4VmsG8FMKq99G6

* fix(underlag): issued invoices only, blocking mixed-customer settlements in PS, chunk-level degrade (#2298 review)

- The customer-invoice hanvisning arms (RPCs, both TS resolvers, push cron)
  now require an ISSUED invoice: status not in ('draft', 'cancelled'), the
  schema's own definition (migration 20260427150000). NON_ISSUED_INVOICE_
  STATUSES in lib/invoices/matchable-statuses.ts is the shared constant; the
  pg test pins a draft-linked and a cancelled-payment entry as still missing.
- Periodisk sammanstallning: one verifikat linked to invoices of different
  customers is no longer attributed to the first invoice; it is left out of
  the accumulators and reported once as a blocking MIXED_CUSTOMER_SETTLEMENT
  naming the voucher, the customer count and the amount. Same-customer
  settlements are filed in full.
- Transactions list: a failed invoice-reference lookup leaves that chunk's
  verdict unknown (no badges) and continues with the remaining chunks instead
  of abandoning them.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

---------

Co-authored-by: Jakob Wennberg <311770904+jakobwennberg-oss@users.noreply.github.com>
Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>

extensions/general/push-notifications/notification-scheduler.ts

@@ -13,6 +13,7 @@ import type { SupabaseClient } from '@supabase/supabase-js'
 import type { NotificationType } from '@/types'
 import { fetchAllRows } from '@/lib/supabase/fetch-all'
 import { NEEDS_DOC_SOURCE_TYPES } from '@/lib/worklist/types'
+import { NON_ISSUED_INVOICE_STATUSES_FILTER } from '@/lib/invoices/matchable-statuses'
 import { sendNotificationToUser, readNotificationSettings } from './notification-sender'
 import {
   createTaxDeadlinePayload,
@@ -332,6 +333,39 @@ export async function sendMissingUnderlagNotifications(
     }
   }
 
+  // BFL 5 kap 7 § hänvisning, customer side (#2298): an entry an ISSUED
+  // register invoice points at (registration link or an invoice_payments row,
+  // e.g. a SIE-imported sale matched to its invoice afterwards) is backed by
+  // that invoice; a draft or cancelled invoice is no document
+  // (NON_ISSUED_INVOICE_STATUSES). Global reads like the ones above: this
+  // cron spans every company. Mirrors the verifikat_without_documents RPC's
+  // customer arm.
+  const invoiceLinks = await fetchAllRows<{ journal_entry_id: string | null }>(({ from, to }) =>
+    supabase
+      .from('invoices')
+      .select('journal_entry_id')
+      .not('journal_entry_id', 'is', null)
+      .not('status', 'in', NON_ISSUED_INVOICE_STATUSES_FILTER)
+      .order('id')
+      .range(from, to)
+  )
+  for (const inv of invoiceLinks) {
+    if (inv.journal_entry_id) entriesWithDocs.add(inv.journal_entry_id)
+  }
+
+  const paymentLinks = await fetchAllRows<{ journal_entry_id: string | null }>(({ from, to }) =>
+    supabase
+      .from('invoice_payments')
+      .select('journal_entry_id, invoices!inner(status)')
+      .not('journal_entry_id', 'is', null)
+      .not('invoices.status', 'in', NON_ISSUED_INVOICE_STATUSES_FILTER)
+      .order('id')
+      .range(from, to)
+  )
+  for (const payment of paymentLinks) {
+    if (payment.journal_entry_id) entriesWithDocs.add(payment.journal_entry_id)
+  }
+
   // Entries the user has explicitly flagged as "no underlag required" (bank
   // fees, interest, internal transfers, salary, tax payments). Treated as
   // satisfied so we don't nag the user about them.