Files
accounted/lib/invoices/settle-invoice-payment.ts
T
Jakob WennbergandClaude Opus 5 27ae59040e fix(transactions): retire stale invoice match pointers when an invoice settles (#1313)
* fix(transactions): retire stale invoice match pointers when an invoice settles

potential_invoice_id / potential_supplier_invoice_id are write-once import
suggestions: nothing revisited them once written. With recurring same-amount
invoices, an earlier suggestion pointed transaction A at invoice X, X was then
paid off by transaction B, and A kept pointing at a fully paid invoice. The
match dialog computed its amount diff against that invoice's 0 kr
remaining_amount and reported a bogus partial payment, and the dead pointer
also blocked a fresh suggestion: both re-suggestion scans require the column
to be NULL.

Add one shared helper, clearSettledInvoiceSuggestions(), that nulls a settled
invoice's own suggestion column on every other transaction of the same
company, scoped by company_id and by that invoice id only, never widening to
the confirmed invoice_id / supplier_invoice_id links. It is best effort by
construction: every caller has already booked a payment verifikat, so a failed
cleanup logs and returns instead of failing the settle.

Wired into every path where an invoice reaches paid through a payment:
the dashboard and v1 match-invoice / match-supplier-invoice routes, the
dashboard and v1 mark-paid routes, settleInvoicePayment, the batch allocation
route (per fully settled allocation), linkInvoiceToVoucher and
linkSupplierInvoiceToVoucher, linkTransactionToJournalEntry, and the MCP
staged-operation executors for mark_invoice_paid and
match_transaction_invoice. Partial payments are deliberately left alone: a
partially paid invoice is still matchable. The v1 supplier match route also
clears its own row's hint, which it was missing next to its dashboard twin.

Read-time revalidation stays as the backstop for the paths not wired up here.
countSuggestedMatches now delegates to listSuggestedMatches, which already
revalidates candidates, so the worklist badge can no longer claim a number the
list refuses to render.

A data-only backfill migration retires the pointers already stranded in the
database. It touches no journal entry, verifikat or period-locked data, is
idempotent, and its status lists mirror lib/invoices/matchable-statuses.ts.

Fixes #1259

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(transactions): wire the MCP batch allocation into the settled-pointer cleanup

Review follow-up on the #1259 fix.

commitMatchBatchAllocate calls the same match_batch_allocate RPC as the
dashboard route, and gnubok_match_batch_allocate is a live staged MCP tool, so
an agent settling a samlingsbetalning reproduced the issue exactly: the RPC
nulls potential_invoice_id / potential_supplier_invoice_id only on the source
transaction, leaving every other transaction of the company pointing at an
invoice the batch just closed. The per-allocation loop moves into
clearSettledBatchAllocationSuggestions() so the HTTP route and the MCP executor
run the same code and cannot drift again, with a commit-path test pinning that
only the fully settled allocation is retired.

The enlarged badge scan is made safe. countSuggestedMatches now feeds up to 200
ids into listSuggestedMatches, past the 150 per .in() that countInboxDocuments
already chunks for, so the candidate lookups are chunked at IN_CLAUSE_CHUNK too
and their ids deduped. Both lookups now check .error: previously a 414, a 500 or
an RLS change produced empty maps, an empty list and a zero badge with nothing
logged. Every failure branch here logs companyId, matching the logAndZero
convention.

Also: restore the anchorSupplierInvoiceDocument doc comment above its own call
in the dashboard supplier-invoice mark-paid route (the #1259 block had been
inserted between them), and assert the transaction update payload in the v1
match-supplier-invoice test, which now covers the potential_supplier_invoice_id
null that the route was missing next to its dashboard twin.

Fixes #1259

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-07-30 18:52:24 +02:00

329 lines
12 KiB
TypeScript

import type { SupabaseClient } from '@supabase/supabase-js'
import {
createInvoicePaymentJournalEntry,
createInvoiceCashEntry,
} from '@/lib/bookkeeping/invoice-entries'
import { createJournalEntry, findFiscalPeriod } from '@/lib/bookkeeping/engine'
import { resolveInvoicePaymentSourceType } from '@/lib/bookkeeping/propose-payment-lines'
import { isBookkeepingError } from '@/lib/bookkeeping/errors'
import { cancelOrphanedPaymentEntry } from '@/lib/bookkeeping/cancel-orphaned-entry'
import { planInvoicePaymentForLines } from '@/lib/invoices/apply-invoice-payment'
import { clearSettledInvoiceSuggestions } from '@/lib/invoices/clear-settled-invoice-suggestions'
import { eventBus } from '@/lib/events'
import type { CreateJournalEntryInput, Customer, EntityType, Invoice } from '@/types'
/**
* The core "apply a payment to an invoice" operation, extracted from the
* mark-paid route so the Stripe payment sync (and any future automated payment
* channel) shares the exact same booking, status transition, orphan handling
* and event emission as the manual flow:
*
* 1. planInvoicePayment: ledger math + overpayment guard
* 2. journal entry: custom lines | cash entry (kontantmetoden, unbooked) |
* payment entry (clears 1510), fail-closed for real invoices
* 3. CAS-guarded invoice status update; a lost race or failed update cancels
* the just-posted voucher so GL and sub-ledger never diverge
* 4. invoice.paid event (best-effort)
*
* `settlementAccountNumber` routes the debit side: default 1930 (bank), 1686
* for PSP-balance settlements (Stripe) where the money reaches the bank only
* with the later payout.
*
* The function performs the write path only. Caller-owned concerns stay in
* the callers: fetching the invoice, payable-status guards, request parsing,
* the duplicate-payment guard (a UX advisory: the Stripe sync skips it
* because the payment event IS the authoritative payment), and mapping the
* result to a transport-specific response.
*/
export interface SettleCustomLine {
account_number: string
debit_amount: number
credit_amount: number
line_description?: string
}
/**
* Invoice shape at the settlement boundary. Callers typically join only the
* customer's name (`customer:customers(name)`), so the relation is modelled
* as exactly that: reading any other Customer field here would be undefined
* at runtime. A fully joined Customer still satisfies this structurally.
*/
export type InvoiceWithCustomerName = Omit<Invoice, 'customer'> & {
customer?: Pick<Customer, 'name'> | null
}
export interface SettleInvoicePaymentParams {
invoice: InvoiceWithCustomerName
/** Payment amount in the INVOICE currency (caller converts if needed). */
paymentAmountInInvoiceCurrency: number
/** Booking date (YYYY-MM-DD). */
paymentDate: string
accountingMethod: string
entityType: EntityType
/** FX difference in SEK (manual flow only). */
exchangeRateDifference?: number
/** Caller-supplied booking lines (manual dialog only); must balance. */
customLines?: SettleCustomLine[]
/** Debit-side account; default '1930'. Stripe settlements pass '1686'. */
settlementAccountNumber?: string
}
export type SettleInvoicePaymentResult =
| {
ok: true
newStatus: 'paid' | 'partially_paid'
newPaidAmount: number
newRemaining: number
journalEntryId: string | null
paidAt: string | null
}
| { ok: false; code: 'MATCH_AMOUNT_EXCEEDS_REMAINING'; details: Record<string, unknown> }
| { ok: false; code: 'INVOICE_PAID_LINES_UNBALANCED'; details: Record<string, unknown> }
| { ok: false; code: 'INVOICE_PAID_NO_FISCAL_PERIOD'; details: Record<string, unknown> }
| { ok: false; code: 'INVOICE_PAID_BOOK_FAILED'; details: Record<string, unknown> }
| { ok: false; code: 'INVOICE_PAID_NOT_PAYABLE'; details: Record<string, unknown> }
| { ok: false; code: 'INVOICE_PAID_RACE' }
| { ok: false; code: 'BOOKKEEPING_ERROR'; error: unknown }
| { ok: false; code: 'UPDATE_FAILED'; error: unknown }
export async function settleInvoicePayment(
supabase: SupabaseClient,
companyId: string,
userId: string,
params: SettleInvoicePaymentParams,
): Promise<SettleInvoicePaymentResult> {
const {
invoice,
paymentAmountInInvoiceCurrency,
paymentDate,
accountingMethod,
entityType,
exchangeRateDifference,
customLines,
settlementAccountNumber,
} = params
if (invoice.credited_invoice_id) {
return {
ok: false,
code: 'INVOICE_PAID_NOT_PAYABLE',
details: { reason: 'credit_note' },
}
}
const now = new Date().toISOString()
// Drive the JE shape from the invoice's actual booking state, not from
// the current accounting_method setting. If the invoice was booked at
// send (Dr 1510 / Cr 30xx + VAT), the payment MUST clear 1510:
// otherwise the receivable orphans and 30xx + VAT double-count. Only
// when there is no prior JE (pure kontantmetoden) do we recognise
// revenue + VAT here.
const invoiceAlreadyBooked = !!(invoice as { journal_entry_id?: string | null })
.journal_entry_id
const useCashEntry = !invoiceAlreadyBooked && accountingMethod === 'cash'
// Ledger math + overpayment guard. Runs BEFORE any journal entry is
// created so a doomed overpayment never burns a voucher number.
// Custom-line SEK settlements absorb a sub-krona öresavrundning residual
// (customer paid the rounded "Att betala" from the PDF, up to 1 kr off the
// stored öre total) ONLY when the lines actually carry the residual on
// 3740, mirroring the bank-transaction match flow; lines that don't (e.g.
// a deliberate sub-krona partial) get the strict plan instead. The
// generated-entry paths (Stripe sync, no-body mark-paid) always pay the
// exact remaining, so absorption is a no-op there.
const payment = planInvoicePaymentForLines(
invoice,
paymentAmountInInvoiceCurrency,
customLines,
invoice.currency,
)
if (!payment.ok) {
return {
ok: false,
code: 'MATCH_AMOUNT_EXCEEDS_REMAINING',
details: payment.details as Record<string, unknown>,
}
}
const { newPaidAmount, newRemaining, newStatus } = payment.plan
const isRealInvoice = !invoice.document_type || invoice.document_type === 'invoice'
let journalEntryId: string | null = null
if (isRealInvoice) {
try {
if (customLines) {
const totalDebit = customLines.reduce((s, l) => s + l.debit_amount, 0)
const totalCredit = customLines.reduce((s, l) => s + l.credit_amount, 0)
if (Math.round((totalDebit - totalCredit) * 100) !== 0 || totalDebit <= 0) {
return {
ok: false,
code: 'INVOICE_PAID_LINES_UNBALANCED',
details: { totalDebit, totalCredit },
}
}
const fiscalPeriodId = await findFiscalPeriod(supabase, companyId, paymentDate)
if (!fiscalPeriodId) {
return {
ok: false,
code: 'INVOICE_PAID_NO_FISCAL_PERIOD',
details: { paymentDate },
}
}
const sourceType = resolveInvoicePaymentSourceType({
invoiceAlreadyBooked,
// Settings store a raw string; anything but 'cash' books as accrual,
// matching the useCashEntry check above.
accountingMethod: accountingMethod === 'cash' ? 'cash' : 'accrual',
})
const input: CreateJournalEntryInput = {
fiscal_period_id: fiscalPeriodId,
entry_date: paymentDate,
description: invoice.customer?.name
? `Inbetalning kundfaktura ${invoice.invoice_number}, ${invoice.customer.name}`
: `Inbetalning kundfaktura ${invoice.invoice_number}`,
source_type: sourceType,
source_id: invoice.id,
lines: customLines,
}
const journalEntry = await createJournalEntry(supabase, companyId, userId, input)
journalEntryId = journalEntry?.id ?? null
} else if (useCashEntry) {
// The entry helpers never read invoice.customer (the display name is
// passed explicitly), so the partial customer relation is safe here.
const journalEntry = await createInvoiceCashEntry(
supabase,
companyId,
userId,
invoice as Invoice,
paymentDate,
entityType,
invoice.customer?.name ?? undefined,
settlementAccountNumber,
)
journalEntryId = journalEntry?.id ?? null
} else {
const journalEntry = await createInvoicePaymentJournalEntry(
supabase,
companyId,
userId,
invoice as Invoice,
paymentDate,
exchangeRateDifference,
invoice.customer?.name ?? undefined,
undefined,
settlementAccountNumber,
)
journalEntryId = journalEntry?.id ?? null
}
} catch (err) {
if (isBookkeepingError(err)) {
return { ok: false, code: 'BOOKKEEPING_ERROR', error: err }
}
return {
ok: false,
code: 'INVOICE_PAID_BOOK_FAILED',
details: { reason: err instanceof Error ? err.message : 'unknown' },
}
}
// Fail closed: a real invoice must produce a payment voucher. If a helper
// returned null without throwing (e.g. a closed/locked fiscal period),
// refuse to mark the invoice paid: flipping status with no journal entry
// orphans the receivable and diverges the GL from the sub-ledger.
if (!journalEntryId) {
return {
ok: false,
code: 'INVOICE_PAID_BOOK_FAILED',
details: { reason: 'no_journal_entry_created' },
}
}
}
// CAS guard: only update if status is still in a payable state.
const { data: updateResult, error: updateError } = await supabase
.from('invoices')
.update({
status: newStatus,
paid_amount: newPaidAmount,
remaining_amount: newRemaining,
...(newStatus === 'paid' ? { paid_at: now } : {}),
})
.eq('id', invoice.id)
.eq('company_id', companyId)
.in('status', ['sent', 'overdue', 'partially_paid'])
.select('id')
if (updateError) {
// The payment voucher already posted but the invoice row did not flip to
// paid; cancel the orphan so the GL doesn't diverge from the sub-ledger.
if (journalEntryId) {
await cancelOrphanedPaymentEntry(
supabase,
companyId,
userId,
journalEntryId,
'Automatiskt makulerad: fakturauppdatering misslyckades efter bokförd betalning',
)
}
return { ok: false, code: 'UPDATE_FAILED', error: updateError }
}
if (!updateResult || updateResult.length === 0) {
// Status changed between read and write (concurrent settle): cancel the
// orphaned payment voucher; the trigger documents the voucher gap.
if (journalEntryId) {
await cancelOrphanedPaymentEntry(
supabase,
companyId,
userId,
journalEntryId,
'Automatiskt makulerad: dubblettbokning förhindrad av samtidighetsskydd',
)
}
return { ok: false, code: 'INVOICE_PAID_RACE' }
}
// Fully settled: retire every transaction's suggestion pointer at this
// invoice (issue #1259). No exceptTransactionId: this flow is not driven by
// a bank transaction, so any pointer at it is now dead.
if (newStatus === 'paid') {
await clearSettledInvoiceSuggestions(supabase, companyId, 'invoice', invoice.id)
}
// Notify subscribers: invoice.paid fans out to registered webhooks and the
// Stripe extension's link-deactivation handler. Best-effort: the payment is
// already committed, so an emit failure must not fail the operation.
try {
await eventBus.emit({
type: 'invoice.paid',
payload: {
invoice: {
...invoice,
status: newStatus,
paid_amount: newPaidAmount,
remaining_amount: newRemaining,
paid_at: newStatus === 'paid' ? now : invoice.paid_at,
} as Invoice,
companyId,
userId,
paymentAmount: paymentAmountInInvoiceCurrency,
paymentDate,
},
})
} catch {
// Swallowed by design; the DB state is the source of truth.
}
return {
ok: true,
newStatus,
newPaidAmount,
newRemaining,
journalEntryId,
paidAt: newStatus === 'paid' ? now : null,
}
}