Files
accounted/app/api/transactions/[id]/match-batch/route.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

177 lines
6.1 KiB
TypeScript

import { NextResponse } from 'next/server'
import { withRouteContext } from '@/lib/api/with-route-context'
import { validateBody } from '@/lib/api/validate'
import { MatchBatchSchema } from '@/lib/api/schemas'
import { errorResponseFromCode } from '@/lib/errors/get-structured-error'
import { eventBus } from '@/lib/events/bus'
import { clearSettledBatchAllocationSuggestions } from '@/lib/invoices/clear-settled-batch-allocations'
import { ensureInitialized } from '@/lib/init'
import type { Invoice, SupplierInvoice, Transaction } from '@/types'
import { getErrorMessage as getUserErrorMessage } from '@/lib/errors/get-error-message'
ensureInitialized()
interface RpcAllocationResult {
kind: 'customer_invoice' | 'supplier_invoice'
invoice_id?: string
supplier_invoice_id?: string
payment_id: string
status: 'paid' | 'partially_paid'
paid_amount: number
remaining_amount: number
amount: number
}
interface RpcOk {
ok: true
journal_entry_id: string
voucher_series: string
voucher_number: number
tx_id: string
allocations: RpcAllocationResult[]
total_allocated: number
leftover: number
}
interface RpcErr {
ok: false
code: string
details?: Record<string, unknown>
}
/**
* POST /api/transactions/[id]/match-batch
*
* Allocate one bank transaction across N customer OR N supplier invoices.
* Builds a single combined verifikat (samlingsverifikation) and inserts N
* payment rows via the match_batch_allocate PL/pgSQL RPC.
*
* The RPC is the atomicity boundary; this route is a thin wrapper that:
* 1. Validates the request body via MatchBatchSchema.
* 2. Invokes the RPC.
* 3. Maps the structured RPC error (jsonb { ok: false, code }) to an
* errorResponseFromCode call.
* 4. On success, refetches the per-allocation invoice/supplier_invoice rows
* to emit the same per-allocation events the legacy single-tx routes
* emit (invoice.match_confirmed, invoice.paid, supplier_invoice.*).
* Event emission is best-effort: a failure here does not roll back
* the booking; the RPC commit is the source of truth.
*/
export const POST = withRouteContext(
'transaction.match_batch',
async (request, ctx, { params }: { params: Promise<{ id: string }> }) => {
const { id: transactionId } = await params
const { user, supabase, companyId, log, requestId } = ctx
const validation = await validateBody(request, MatchBatchSchema, {
log,
operation: 'transaction.match_batch',
})
if (!validation.success) return validation.response
const txLog = log.child({ transactionId })
// PR #607 round 3: p_user_id removed: RPC resolves caller from
// auth.uid() directly. Keeps the attack surface off the API boundary.
const { data, error } = await supabase.rpc('match_batch_allocate', {
p_tx_id: transactionId,
p_allocations: validation.data.allocations,
p_company_id: companyId,
})
if (error) {
txLog.error('match_batch_allocate RPC error', error)
return errorResponseFromCode('BATCH_RPC_FAILED', txLog, {
requestId,
details: { message: getUserErrorMessage(error) },
})
}
const result = data as RpcOk | RpcErr | null
if (!result || !result.ok) {
const code = (result as RpcErr | null)?.code ?? 'BATCH_RPC_FAILED'
const details = (result as RpcErr | null)?.details
return errorResponseFromCode(code, txLog, { requestId, details })
}
// Re-fetch the transaction row for event payloads (the RPC has already
// updated it). Lookup is non-critical: events fail open on miss.
const { data: tx } = await supabase
.from('transactions')
.select('*')
.eq('id', transactionId)
.eq('company_id', companyId)
.maybeSingle()
// Emit one event per allocation so existing subscribers (reminder
// cancellation, automation, processing-history) keep working without a
// new event channel. Loop sequentially so a single failure logs cleanly.
for (const alloc of result.allocations) {
try {
if (alloc.kind === 'customer_invoice' && alloc.invoice_id) {
const { data: invoice } = await supabase
.from('invoices')
.select('*')
.eq('id', alloc.invoice_id)
.eq('company_id', companyId)
.maybeSingle()
if (invoice && tx) {
await eventBus.emit({
type: 'invoice.match_confirmed',
payload: {
invoice: invoice as Invoice,
transaction: tx as Transaction,
userId: user.id,
companyId,
},
})
}
} else if (alloc.kind === 'supplier_invoice' && alloc.supplier_invoice_id) {
const { data: supplierInvoice } = await supabase
.from('supplier_invoices')
.select('*')
.eq('id', alloc.supplier_invoice_id)
.eq('company_id', companyId)
.maybeSingle()
if (supplierInvoice && tx) {
await eventBus.emit({
type: 'supplier_invoice.match_confirmed',
payload: {
supplierInvoice: supplierInvoice as SupplierInvoice,
transaction: tx as Transaction,
userId: user.id,
companyId,
},
})
}
}
} catch (err) {
txLog.warn('match_batch event emission failed', err as Error)
}
}
// Every allocation the RPC settled in full retires its suggestion pointer
// from the company's OTHER transactions (issue #1259). This request's own
// row is linked by the RPC, so it is excluded there. Shared with the MCP
// executor for the same RPC (commitMatchBatchAllocate).
await clearSettledBatchAllocationSuggestions(
supabase,
companyId!,
result.allocations,
transactionId,
)
return NextResponse.json({
data: {
journal_entry_id: result.journal_entry_id,
voucher_series: result.voucher_series,
voucher_number: result.voucher_number,
allocations: result.allocations,
total_allocated: result.total_allocated,
leftover: result.leftover,
},
})
},
{ requireWrite: true },
)