* fix(invoices): record manual and Stripe settlements in invoice_payments (#2019)
settleInvoicePayment created the payment voucher and flipped the invoice to
paid but never wrote the AR sub-ledger row. The kontantmetod bokslut cut-off
reads invoice_payments only (payment DATE, not remaining_amount), so a
manually settled invoice was booked again as a fordran with vilande moms at
year end, double-counting revenue and VAT. The same gap hid the payment from
the Betalningar view and from the voucher -> invoice reference map.
- Insert the row between voucher creation and the CAS status update, same
shape as the bank-match path (amount in invoice currency, transaction_id
null). An insert failure cancels the voucher and fails closed; both CAS
failure branches remove the row together with the voucher.
- Backfill: scripts/backfill-invoice-payment-rows.ts (dry-run default) with
a pure planner in lib/invoices/backfill-invoice-payment-rows.ts. Writes
only where exactly one posted payment voucher exists; zero or several are
reported, never guessed. Rows carry notes 'backfill:#2019' so one DELETE
reverts a run. Executed on staging (10 rows); prod awaits explicit go.
- pg-real: transaction-less rows coexist under the tx/invoice unique index,
the je/invoice index still refuses a double link, and the authenticated
writer can delete its own row (the CAS-failure path depends on it).
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018pMEgrnPsxDMiYfnXcD2Zo
* fix(invoices): write the payment row from every mark-paid path and harden the backfill
Skeptic and review round on #2236 (issue #2019):
- One helper (lib/invoices/invoice-payment-row.ts) now writes the
invoice_payments row for all four transaction-less settlement paths:
dashboard mark-paid and Stripe via settleInvoicePayment, plus the MCP
mark_invoice_paid commit and the v1 mark-paid route, which booked their
own voucher and never wrote the row. Amount = applied amount (new
paid_amount minus prior), not cash received, so a 3740 öre absorption
never yields a negative fordran in the cut-off or a wrong storno restore.
- The two duplicate detectors no longer treat a payment row with
transaction_id NULL as "reconciled to a bank line": the bank line for a
manual settlement arrives later and the voucher must stay a twin.
- Backfill: payment_date from the voucher entry_date (paid_at was
wall-clock before #1332); refuse rows that disagree with the voucher's
1510 credit / settlement debit; report partially covered invoices
(rows_short) instead of patching; record each executed run in
behandlingshistorik (InvoicePaymentRowBackfilled, migration
20260903180000). Re-run end to end on staging: 10 rows, 10 events.
- Typecheck ratchet: cast in the cut-off test.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018pMEgrnPsxDMiYfnXcD2Zo
* fix(invoices): use roundOre in the #2019 backfill (guard ratchet)
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018pMEgrnPsxDMiYfnXcD2Zo
* fix(invoices): log a failed payment-row rollback and keep backfill rows with their audit event
Swedish review round 2 on #2236:
- removeInvoicePaymentRow no longer swallows a failed compensating DELETE:
it logs at error level with company and row id (a stranded row would
read as a settlement in the kontantmetod cut-off) and returns whether
the row is gone. Unit tests for the helper.
- The backfill deletes a company's rows from the run again when its
behandlingshistorik event cannot be written, so rows and change log
(BFNAR 2013:2 p. 9.16) never diverge; the company is listed for a re-run.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018pMEgrnPsxDMiYfnXcD2Zo
* fix(invoices): keep raw insert errors out of the v1 and MCP mark-paid responses
Compliance swarm on #2236 (ISO 27001 A.8.28): the payment-row insert
failure returned the driver's error text to API callers and MCP users.
The text now stays in the server log; callers get the reason code and a
generic Swedish outcome.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018pMEgrnPsxDMiYfnXcD2Zo
* fix(invoices): never backfill a payment row into a closed or locked period
Swedish review round 3 on #2236: a row dated into a closed or locked
fiscal period changes facts a filed bokslut or deklaration relied on. The
planner now reports such invoices (period_closed) instead of writing them,
and the script header states that the tagged DELETE is an emergency revert
for the window before any cut-off relies on the rows; afterwards the
correction path is a storno of the cut-off verifikat.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018pMEgrnPsxDMiYfnXcD2Zo
* test(fiscal-periods): pass route params in the two mid-month tests (typecheck ratchet)
cc18e9d53 (#2242) added two POST(req) calls without the params argument,
raising the file's TypeScript error count above the ratchet baseline
(25 vs 23). main is red on "Checks" for every PR since; this unblocks the
gate for #2236 and the rest without touching the baseline.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
399 lines
15 KiB
TypeScript
399 lines
15 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 { cashPartialBlockReason } from '@/lib/bookkeeping/booking-mode'
|
|
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 { recordInvoicePaymentRow, removeInvoicePaymentRow } from '@/lib/invoices/invoice-payment-row'
|
|
import { paidAtFromDate } from '@/lib/invoices/paid-at'
|
|
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. invoice_payments row (the AR sub-ledger): the only source of the
|
|
* payment DATE, which the kontantmetod bokslut cut-off, the voucher ->
|
|
* invoice reference map and the "Betalningar" view all read (#2019)
|
|
* 4. CAS-guarded invoice status update; a lost race or failed update cancels
|
|
* the just-posted voucher and removes the payment row so GL and
|
|
* sub-ledger never diverge
|
|
* 5. 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_CASH_PARTIAL_UNSUPPORTED'; 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' },
|
|
}
|
|
}
|
|
|
|
// 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 paidAt = newStatus === 'paid' ? paidAtFromDate(paymentDate) : null
|
|
|
|
const isRealInvoice = !invoice.document_type || invoice.document_type === 'invoice'
|
|
|
|
// The generated cash entry (createInvoiceCashEntry) books the FULL invoice
|
|
// and takes no payment amount, so a never-booked kontantmetoden invoice can
|
|
// only be settled in full from a fully unpaid state. Partials used to book
|
|
// the entire revenue + moms against a smaller bank movement (bokslutsmetoden
|
|
// reports moms at payment, per installment), and completing a
|
|
// prior partial would book the full total a second time. Custom lines are
|
|
// NOT exempt: the dialog pre-fills the same full-invoice shape, so lines
|
|
// would book the identical error under a user-shaped label.
|
|
const cashBlock = cashPartialBlockReason({
|
|
invoiceAlreadyBooked,
|
|
accountingMethod,
|
|
priorPaidAmount: invoice.paid_amount,
|
|
paysRemainingInFull: newStatus === 'paid',
|
|
})
|
|
if (isRealInvoice && cashBlock) {
|
|
return {
|
|
ok: false,
|
|
code: 'INVOICE_PAID_CASH_PARTIAL_UNSUPPORTED',
|
|
details: {
|
|
reason: cashBlock,
|
|
payment_amount: paymentAmountInInvoiceCurrency,
|
|
paid_amount: invoice.paid_amount ?? 0,
|
|
invoice_total: invoice.total,
|
|
},
|
|
}
|
|
}
|
|
|
|
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' },
|
|
}
|
|
}
|
|
}
|
|
|
|
// Sub-ledger row (see lib/invoices/invoice-payment-row.ts for why and for
|
|
// the shape). Written BEFORE the CAS update so the failure branches below
|
|
// can undo it together with the voucher; a real invoice never reaches paid
|
|
// through this service without it.
|
|
let paymentRowId: string | null = null
|
|
if (isRealInvoice) {
|
|
const recorded = await recordInvoicePaymentRow(supabase, {
|
|
userId,
|
|
companyId,
|
|
invoice,
|
|
paymentDate,
|
|
newPaidAmount,
|
|
journalEntryId,
|
|
})
|
|
if (!recorded.ok) {
|
|
if (journalEntryId) {
|
|
await cancelOrphanedPaymentEntry(
|
|
supabase,
|
|
companyId,
|
|
userId,
|
|
journalEntryId,
|
|
'Automatiskt makulerad: betalningsraden kunde inte sparas efter bokförd betalning',
|
|
)
|
|
}
|
|
return {
|
|
ok: false,
|
|
code: 'INVOICE_PAID_BOOK_FAILED',
|
|
details: { reason: 'payment_row_insert_failed', error: recorded.error },
|
|
}
|
|
}
|
|
paymentRowId = recorded.id
|
|
}
|
|
|
|
// 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,
|
|
...(paidAt ? { paid_at: paidAt } : {}),
|
|
})
|
|
.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.
|
|
await removeInvoicePaymentRow(supabase, companyId, paymentRowId)
|
|
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.
|
|
await removeInvoicePaymentRow(supabase, companyId, paymentRowId)
|
|
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: paidAt ?? 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,
|
|
}
|
|
}
|