Files
accounted/app/api/transactions/[id]/book/route.ts
T
MattssonandClaude Fable 5.1 f1230282a9 feat(bookkeeping): verifikationsserie per bankkonto for bank-transaction bookings (#2160)
* feat(bookkeeping): verifikationsserie per bankkonto for bank-transaction bookings

A company running several bank accounts (main bank on A, company card on M,
both imported via CSV) could not route each account's bookings into its own
series: every bank_transaction booking took the single company-wide default
from default_voucher_series_per_source_type.

- cash_accounts.voucher_series (nullable, single letter): per-account override,
  editable under Inställningar → Bokföring → Verifikationsserier per bankkonto
  (new PATCH /api/cash-accounts/[id]).
- resolveCashAccountVoucherSeries(): step 2 of the resolution order
  (explicit pick → account override → per-type map → A). Wired into the book
  route and createTransactionJournalEntry, which covers categorize, the agent,
  pending operations and the v1 API.
- Booking dialog gets the series picker, seeded from the server via
  /voucher-sequences/next?source_type&cash_account_id so dialog and route can
  never disagree. An unresolved embedded picker omits voucher_series so a
  stray 'A' never overrides the account's series.

Scope: bank_transaction bookings only. Invoice settlements matched from the
bank keep their payment series; bulk-book resolves inside its RPC (see
DECISIONS.md).

Migration applied to staging as 20260902121420.

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

* fix(bookkeeping): audit and document the per-bankkonto series, tighten preview and PATCH

Consolidated pass over the PR #2160 findings (skeptics, CodeRabbit, Swedish
compliance review):

- Behandlingshistorik (BFNAR 2013:2 p. 9.16): changing cash_accounts.voucher_series
  is a behandlingsregel that outranks the audited per-type map. New trigger
  audit_cash_accounts_voucher_series (UPDATE only, WHEN the series changes, so
  bank-sync churn never logs), cash_accounts added to AUDITED_TABLES and the
  audit_log filter, "Bankkonto ... Verifikationsserie: (tomt) -> M" events in
  the report, pg-real test. Applied to staging as 20260902124513.
- Systemdokumentation (p. 9.2-9.15): revision/systemdokumentation.json gains a
  verifikationsserier_regler block with the resolution order and the two
  exceptions (invoice settlements, samlingsverifikat); the per-account mapping
  itself is in data/cash_accounts.json.
- Settings picker uses the same closed list as the manual verifikat form
  (presets plus letters already in use) instead of all 26 letters; strings
  moved to messages/sv.json and messages/en.json.
- /voucher-sequences/next applies the account override only for
  source_type=bank_transaction (CodeRabbit), so a manual-entry preview cannot
  show a series the entry will not get.
- Book route resolves the series from the account the row ends up on after a
  stranded-row repoint, not the stale one.
- PATCH /api/cash-accounts/[id] answers 404 for a non-UUID id instead of a
  Postgres cast 500; the series lookup logs a warning when it fails open.

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

---------

Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-02 15:25:34 +02:00

279 lines
12 KiB
TypeScript

import { NextResponse } from 'next/server'
import { eventBus } from '@/lib/events'
import { ensureInitialized } from '@/lib/init'
import { withRouteContext } from '@/lib/api/with-route-context'
import { createJournalEntry } from '@/lib/bookkeeping/engine'
import { resolveCashAccountVoucherSeries } from '@/lib/bookkeeping/cash-account-voucher-series'
import { guardBookedCounterLines } from '@/lib/cash-accounts/service'
import { reverseOrphanedJournalEntry } from '@/lib/bookkeeping/cancel-orphaned-entry'
import { bookkeepingErrorResponse } from '@/lib/bookkeeping/errors'
import { validateBody } from '@/lib/api/validate'
import { BookTransactionSchema } from '@/lib/api/schemas'
import { detectBookingDuplicate } from '@/lib/transactions/booking-duplicate-detection'
import { propagateUnderlagForBookedTransaction } from '@/lib/transactions/inbox-underlag'
import { errorResponse, errorResponseFromCode } from '@/lib/errors/get-structured-error'
import { getErrorMessage } from '@/lib/errors/get-error-message'
import { appendProcessingHistory } from '@/lib/processing-history/append'
import type { Transaction } from '@/types'
ensureInitialized()
export const POST = withRouteContext<{ params: Promise<{ id: string }> }>(
'transaction.book',
async (request, { supabase, user, companyId, log, requestId }, { params }) => {
const { id } = await params
const validation = await validateBody(request, BookTransactionSchema)
if (!validation.success) return validation.response
const { fiscal_period_id, entry_date, description, lines, force, expected_duplicate_transaction_id, expected_duplicate_journal_entry_id } = validation.data
// Fetch transaction (validates ownership)
const { data: transaction, error: fetchError } = await supabase
.from('transactions')
.select('*')
.eq('id', id)
.eq('company_id', companyId)
.single()
if (fetchError || !transaction) {
return NextResponse.json({ error: 'Transaction not found' }, { status: 404 })
}
// Reject if already booked
if (transaction.journal_entry_id) {
return NextResponse.json(
{ error: 'Transaction already has a journal entry' },
{ status: 409 }
)
}
// Booking-time duplicate guard: if another transaction with the same
// date+amount+account is already booked, booking this one would double-count
// one real event (two verifikationer: felaktig bokföring per BFL). Warn; the
// user confirms with force=true bound to the reviewed sibling. Mirrors the
// match-invoice soft-duplicate guard.
const dupLog = log
try {
const candidate = await detectBookingDuplicate(supabase, companyId, {
id,
date: transaction.date,
amount: transaction.amount,
// The FX trio must ride along: `amount` is in `currency`, the ledger
// legs it is compared against are always SEK. Selected above via
// select('*').
currency: transaction.currency ?? null,
amount_sek: transaction.amount_sek ?? null,
exchange_rate: transaction.exchange_rate ?? null,
cash_account_id: transaction.cash_account_id ?? null,
})
if (!force) {
if (candidate) {
return errorResponseFromCode('TRANSACTION_BOOK_POSSIBLE_DUPLICATE', dupLog, {
details: { candidate },
})
}
} else if (
// force=true is bound to the reviewed candidate. A sibling-transaction
// candidate carries a transaction_id; a ledger-only voucher candidate does
// not, so both are bound by journal_entry_id. Either echoed id confirms.
// Re-detect and refuse the bypass unless it still matches, so a guessed id
// can't wave the guard.
!candidate ||
!(
(candidate.journal_entry_id && candidate.journal_entry_id === expected_duplicate_journal_entry_id) ||
(candidate.transaction_id && candidate.transaction_id === expected_duplicate_transaction_id)
)
) {
return errorResponseFromCode('TRANSACTION_BOOK_FORCE_CANDIDATE_MISMATCH', dupLog, {
details: {
expected_duplicate_transaction_id: expected_duplicate_transaction_id ?? null,
expected_duplicate_journal_entry_id: expected_duplicate_journal_entry_id ?? null,
detected_transaction_id: candidate?.transaction_id ?? null,
detected_journal_entry_id: candidate?.journal_entry_id ?? null,
},
})
} else {
dupLog.warn('booking-time duplicate guard bypassed', {
reason: 'force=true',
transactionId: id,
dismissedTransactionId: candidate.transaction_id,
})
// Persist the dismissal to behandlingshistorik (BFNAR 2013:2 kap 8): the
// decision to book over a DETECTED possible double-booking is a
// bookkeeping act that must leave a durable, queryable record; a warn in
// the application log is ephemeral and does not satisfy the requirement.
// Best-effort: a logging failure must never block a legitimate booking.
try {
await appendProcessingHistory({
companyId,
correlationId: id,
aggregateType: 'BankTransaction',
aggregateId: id,
eventType: 'BankTransactionDuplicateDismissed',
payload: {
transaction_id: id,
dismissed_transaction_id: candidate.transaction_id,
dismissed_journal_entry_id: candidate.journal_entry_id,
// Null when the candidate's SEK value could not be established
// (a rateless foreign sibling); the foreign figures below then
// carry the durable record instead of a fabricated kr amount.
amount_ore: candidate.amount != null ? Math.round(candidate.amount * 100) : null,
dismissed_currency: candidate.currency,
dismissed_amount_in_currency: candidate.amount_in_currency,
entry_date: candidate.entry_date,
// Whether the user dismissed a confirmed same-amount twin or a
// candidate whose amounts could never be compared (BFNAR 2013:2
// kap 8: the behandlingshistorik has to say which).
amount_verified: candidate.amount_verified,
unverified_reason: candidate.unverified_reason,
},
actor: { type: 'user', id: user.id },
occurredAt: new Date(),
})
} catch (logErr) {
dupLog.error('failed to append duplicate-dismissal behandlingshistorik', logErr as Error)
}
}
} catch (err) {
// Detection is fail-open for the non-force path; force requires a confirmed
// candidate, so a detection failure under force is rejected as a mismatch.
if (force) {
return errorResponseFromCode('TRANSACTION_BOOK_FORCE_CANDIDATE_MISMATCH', dupLog, {
details: { detection_failed: true },
})
}
dupLog.warn('booking-time duplicate detection failed (continuing)', err as Error)
}
// A 19xx counter line that is a twin of the transaction's own cash account
// (same IBAN, same currency: the other ledger of one connection, or a
// stale row left by a broken reconnect) or an orphaned ledger books one
// physical account against itself or onto a junk balance-sheet account.
// The dialog pre-fills such lines from learned templates (issue #1643
// problem 4); this is the same refusal the categorize paths apply. A
// booking whose single 19xx line is a sibling ledger the row should move
// to (the live twin of a stranded row) instead re-points the transaction
// there in the locked UPDATE below, as manualLink does for the same
// voucher (see guardBookedCounterLines).
const { refusedLedger, repointCashAccountId } = await guardBookedCounterLines(
supabase,
companyId,
lines.map((line) => line.account_number),
transaction.cash_account_id ?? null,
)
if (refusedLedger) {
return errorResponseFromCode('TX_CATEGORIZE_ORPHANED_COUNTER_ACCOUNT', log, {
requestId,
details: { accountNumber: refusedLedger },
})
}
// Series: the dialog's explicit pick wins; otherwise the bank account the
// row will sit on after this booking (the live sibling when the guard
// re-points a stranded row, else its own) may carry its own
// verifikationsserie; otherwise the engine falls back to the
// per-source-type default.
const voucherSeries =
validation.data.voucher_series ??
(await resolveCashAccountVoucherSeries(
supabase,
companyId,
repointCashAccountId ?? (transaction as Transaction).cash_account_id,
))
// Create journal entry via the engine
let journalEntry
try {
journalEntry = await createJournalEntry(supabase, companyId, user.id, {
fiscal_period_id,
entry_date,
description,
source_type: 'bank_transaction',
source_id: id,
lines,
...(voucherSeries ? { voucher_series: voucherSeries } : {}),
})
} catch (err) {
const typed = bookkeepingErrorResponse(err)
if (typed) return typed
// Untyped errors map to Swedish via getErrorMessage: the raw message is
// logged here and must never reach the user verbatim (issue #337).
log.error('failed to create journal entry on book', err as Error)
return NextResponse.json(
{ error: getErrorMessage(err, { context: 'transaction' }) },
{ status: 400 }
)
}
// Link transaction to the journal entry
const { data: updateResult, error: updateError } = await supabase
.from('transactions')
.update({
journal_entry_id: journalEntry.id,
is_business: true,
is_ignored: false,
category: 'uncategorized',
...(repointCashAccountId ? { cash_account_id: repointCashAccountId } : {}),
})
.eq('id', id)
.eq('company_id', companyId)
.is('journal_entry_id', null)
.select('*')
if (updateError) {
await reverseOrphanedJournalEntry(
supabase,
companyId,
user.id,
journalEntry.id,
'Bokföringsverifikation utan transaktionskoppling; automatisk storno misslyckades. Manuell avstämning krävs.',
)
return errorResponse(updateError, log, { requestId })
}
if (!updateResult || updateResult.length === 0) {
// CAS guard: another request linked this transaction after our read. The
// posted orphan is immutable, so compensate through the engine with a
// storno entry instead of overwriting the winning journal entry link.
await reverseOrphanedJournalEntry(
supabase,
companyId,
user.id,
journalEntry.id,
'Bokföringsverifikation utan transaktionskoppling; automatisk storno misslyckades. Manuell avstämning krävs.',
)
return errorResponseFromCode('TX_CATEGORIZE_RACE', log, { requestId })
}
const updatedTransaction = updateResult[0] as Transaction
// A hunt- or hand-matched inbox item is consumed by this booking even
// though the dialog never saw it: link its underlag to the verifikat and
// stamp it so it leaves the active inbox (best-effort, logged inside).
await propagateUnderlagForBookedTransaction(supabase, companyId, id, journalEntry.id)
// Emit event (non-blocking)
try {
await eventBus.emit({
type: 'transaction.categorized',
payload: {
transaction: updatedTransaction,
account: lines[0]?.account_number || '',
taxCode: '',
userId: user.id,
companyId,
},
})
} catch {
// Non-critical
}
return NextResponse.json({
data: journalEntry,
journal_entry_id: journalEntry.id,
success: true,
})
},
{ requireWrite: true },
)