fix(invoices): guard cash-method partial payments across every payment path (#1413)

* fix(invoices): guard cash-method partial payments across every payment path

A never-booked kontantmetoden invoice can only be settled by the generated
cash entry (createInvoiceCashEntry / createSupplierInvoiceCashEntry), and
that entry always books the FULL invoice: it takes no payment amount. Three
payment surfaces still let partial payments through to it, corrupting books:

- settleInvoicePayment dropped the fully-paid term entirely, so a partial
  payment (Stripe sync, mark-paid) booked the entire invoice: over-recognized
  revenue, over-declared output VAT, and a bank debit that did not match the
  money received.
- The dashboard and agent match-transaction paths fell back to an
  accrual-style clearing entry against an EMPTY 1510: negative receivable,
  no revenue, no moms (ML 13 kap 8 § puts each installment's moms in its own
  receipt period). The comment claimed the credit "gets resolved on final
  payment", but the cash builder never touches 1510 and books the full
  total, so the final payment double-debited the bank instead.
- The supplier routes had no full-settlement term at all, so a partial
  payment booked the full expense + input VAT.

Fix: one shared predicate (cashPartialBlockReason in booking-mode.ts)
rejects generated cash entries unless the payment settles the invoice in
full from a fully unpaid state, wired into all six POST surfaces, the agent
commit paths, and the three preview routes (so dialogs cannot propose a
verifikat the POST refuses). New bilingual error codes
INVOICE_PAID_CASH_PARTIAL_UNSUPPORTED / SI_CASH_PARTIAL_UNSUPPORTED.
Invoices booked at issue are unaffected: their partial payments keep the
normal 1510/2440 clearing path.

The v1 match-invoice route already had this guard (VALIDATION_ERROR); its
behavior is unchanged. Proper per-installment recognition (proportional
revenue + moms per receipt) is the follow-up feature that would lift this
restriction.

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

* docs(review): drop stale ML 13 kap 8 § cites for kontantmetoden VAT timing

Compliance-review finding: the section is the old ML 1994:200 numbering; in
ML 2023:200, 13 kap covers input-VAT deduction, not redovisningstidpunkt.
The substantive rule (bokslutsmetoden reports moms at payment, per
installment, except at year-end) is unchanged and stated without a section
cite until the current-law section is verified. Comments and cookbook prose
only; no behavior change. Also fixes the two pre-existing occurrences.

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

---------

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

lib/pending-operations/commit.ts

@@ -35,6 +35,7 @@ import {
   createCreditNoteJournalEntry,
 } from '@/lib/bookkeeping/invoice-entries'
 import { resolveSettlementAccount } from '@/lib/bookkeeping/settlement-account'
+import { cashPartialBlockReason } from '@/lib/bookkeeping/booking-mode'
 import { ensureManualCashAccount } from '@/lib/cash-accounts/service'
 import { createJournalEntry, findFiscalPeriod, getSwedishLocalDate, reverseEntry, validateBalance } from '@/lib/bookkeeping/engine'
 import {
@@ -1989,6 +1990,26 @@ async function commitMarkInvoicePaid(
   }
   const { newPaidAmount, newRemaining, newStatus } = payment.plan
 
+  // The generated cash entry books the FULL invoice: refuse to complete a
+  // previously part-paid, never-booked kontantmetoden invoice (it would book
+  // the full total a second time on the settlement account). A partial cannot
+  // arise here (this path always settles the full remaining), but the shared
+  // predicate covers it for safety.
+  const cashBlock = cashPartialBlockReason({
+    invoiceAlreadyBooked,
+    accountingMethod,
+    priorPaidAmount: inv.paid_amount,
+    paysRemainingInFull: newStatus === 'paid',
+  })
+  if (isRealInvoice && cashBlock) {
+    return {
+      error:
+        getErrorEntry('INVOICE_PAID_CASH_PARTIAL_UNSUPPORTED')?.message_sv ??
+        'Kontantmetoden kan inte bokföra delbetalningar av en obokförd faktura automatiskt.',
+      status: 400,
+    }
+  }
+
   if (isRealInvoice) {
     if (useCashEntry) {
       const je = await createInvoiceCashEntry(
@@ -2520,6 +2541,27 @@ async function commitMatchTransactionInvoice(
   const invoiceAlreadyBooked = !!(invoice as { journal_entry_id?: string | null }).journal_entry_id
   const useCashEntry = !invoiceAlreadyBooked && accountingMethod === 'cash' && isFullyPaid
 
+  // Reject cash-method partials and part-paid completions on never-booked
+  // invoices BEFORE the irreversible storno below. The old fallback booked an
+  // accrual-style clearing entry against an EMPTY 1510 (negative receivable,
+  // no revenue, no moms: bokslutsmetoden reports moms at payment, per
+  // installment), and the cash builder books the FULL invoice, so
+  // neither shape is bookable here. Mirrors the dashboard and v1 match routes.
+  const cashBlock = cashPartialBlockReason({
+    invoiceAlreadyBooked,
+    accountingMethod,
+    priorPaidAmount: (invoice as { paid_amount?: number | null }).paid_amount,
+    paysRemainingInFull: isFullyPaid,
+  })
+  if (cashBlock) {
+    return {
+      error:
+        getErrorEntry('INVOICE_PAID_CASH_PARTIAL_UNSUPPORTED')?.message_sv ??
+        'Kontantmetoden kan inte bokföra delbetalningar av en obokförd faktura automatiskt.',
+      status: 400,
+    }
+  }
+
   // Debit the cash account THIS transaction actually belongs to, never a
   // hardcoded 1930: cash_account_id -> cash_accounts.ledger_account is the
   // only source of truth for which bank/cash account a real, matched
@@ -2601,9 +2643,9 @@ async function commitMatchTransactionInvoice(
     }
   }
 
-  const paymentNotes = (accountingMethod === 'cash' && !isFullyPaid)
-    ? 'Kontantmetoden: intäkt bokförs vid slutbetalning' : null
-
+  // No cash-method note here anymore: pure kontantmetoden partials are now
+  // rejected above, and for an invoice booked at send the clearing entry
+  // handles a partial correctly, so the note would be misleading.
   await supabase.from('invoice_payments').insert({
     user_id: userId,
     company_id: companyId,
@@ -2614,7 +2656,7 @@ async function commitMatchTransactionInvoice(
     exchange_rate: invoice.exchange_rate,
     journal_entry_id: journalEntryId,
     transaction_id: transactionId,
-    notes: paymentNotes,
+    notes: null,
   })
 
   // The invoice is now settled, so every OTHER transaction still carrying a