Files
accounted/lib/invoices/issue-and-book-invoice.ts
T
Mattsson 26e29f47bc feat(company): ideell förening as a third legal form, behind a flag (#2072 step 1) (#2423)
* feat(company): ideell förening as a third legal form, behind a flag (#2072 step 1)

Why the problem occurred: the legal form was modelled as a binary flag in
~300 files. `EntityType` was a two-member union, but nothing dispatched on it
exhaustively: 28 sites defaulted `?? 'enskild_firma'` (invoice, categorize,
match, stripe, invoice-inbox) or `?? 'aktiebolag'` (year-end, bokslut,
MCP), and every form-dependent choice was an `=== 'aktiebolag' ? A : B`
ternary. Widening the union compiled everywhere and changed nothing, so a
förening would have booked as an enskild firma in the app and as an
aktiebolag in bokslut and MCP, with no error anywhere. The lookup refused
föreningar at the door (mapEntityType returned null), which is what the
tester hit.

What was removed or simplified: the silent defaults. One module,
lib/company/entity-type.ts, now holds the list (ENTITY_TYPES), the parser
(never defaults), the resolver (settings hint, then companies.entity_type,
then throw) and `byEntityType`, whose Record arms make the compiler refuse
the next widening until each site has an answer. The form-dependent facts
(closing account, owner settlement account, calendar-year lock, default
method, K1/K2 label, personnummer vs 16-prefix) live there once instead of
in the ternaries. On the SQL side supported_entity_types() replaces four
copies of the literal list in the create RPCs.

Why this shape and not the proposed one: the tracker asked for the enum
widening plus a chart; that alone was the dangerous version (compiles, books
wrong). Bundling stiftelse was considered and dropped: identical plumbing but
no chart block. Creation sits behind NEXT_PUBLIC_IDEELL_FORENING_ENABLED so
the CHECK, RPCs and seed can ship now and the first partner is switched on
without a migration; the flag goes when Phase 2 (packs, INK3, årsbokslut,
Swish) lands on the tracker.

Domain choices (DECISIONS.md 2026-09-08, verify with an accountant before
Phase 2): result closes to 2069 with 2068 as prior-year carry; no owner
accounts, member settlement on 2890; accrual default; brutet räkenskapsår
allowed; K1 label for the 5 000 kr accrual threshold (BFNAR 2010:1); org
number gets the 16 prefix.

Migration 20260908110835 widens the three CHECK constraints, adds
supported_entity_types(), re-creates the three create RPCs with the widened
guard and adds the förening block to seed_chart_of_accounts. Applied to
staging and covered by ideell-forening-entity-type.pg.test.ts.

Part of #2072

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

* fix(company): close the förening paths the skeptic refuted (#2072)

Five refutations from the /skeptic pass on 7a05c54d2, each fixed at the
shared definition rather than the reported site:

1. Privately paid supplier invoices and the utlägg dialog resolved the owner
   account in lib/expenses/payer.ts with its own AB/EF ternary, so a förening
   member's invoice was built on 2893 and then refused by the expense-claim
   service (which already said 2890), burning an ankomstnummer. The helper now
   uses ownerSettlementAccount.
2. Booking templates substitute their `_ab` accounts only for an aktiebolag;
   the `private_expense` template kept its base 2013 for a förening. Template
   accounts now resolve through templateAccountForForm: EF base, AB override,
   förening base with owner accounts translated to 2890 (booking-templates.ts
   and proposal-lines.ts share it).
3. A VAT-registered förening with helårsmoms got no momsdeklaration deadline:
   the annual VAT rule bailed on anything but AB/EF. A förening is a juridisk
   person and follows the räkenskapsår schedule (SFL 26 kap 33 §), so the rule
   now keys on fiscalYearLockedToCalendar instead of the two literals; same in
   the MCP VAT report.
4. 2069 would have accumulated across years: the year-open omföring was
   AB-only with 2099/2098 hard-coded. planResultAppropriation now takes the
   pair from resultClosingAccounts (AB 2099 -> 2098, förening 2069 -> 2068)
   and skips forms with no carry (EF).
5. With the flag off, a registry lookup that returned "Ideell förening" was
   prefilled into the onboarding journey, the form picker was skipped and the
   create step answered "Ogiltig företagsform" with no way back. The
   journey, the BankID picker, the onboarding page and the MCP lookup now use
   mapSetupEntityType, which maps only creatable forms, so a flagged-off form
   falls through to the picker as before.

Also: form picker keeps its AB-first order; tests for each fix.

Part of #2072

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

* chore(migrations): move ideell förening migration after main's latest version (20260908143051)

Two migrations landed on main after the branch forked; a lower version
would be skipped by the merge-time apply. Staging history row renamed to
match.

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

* chore(skills): regenerate accounted-api reference for the widened entity_type enum

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

---------

Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-08 14:47:50 +02:00

385 lines
14 KiB
TypeScript

import { renderToBuffer } from '@react-pdf/renderer'
import { resolveCompanyEntityType } from '@/lib/company/entity-type'
import type { SupabaseClient } from '@supabase/supabase-js'
import { createInvoiceJournalEntry } from '@/lib/bookkeeping/invoice-entries'
import { booksInvoicesOnIssue } from '@/lib/bookkeeping/booking-mode'
import { createSchedulesForCustomerInvoice } from '@/lib/bookkeeping/accruals/from-invoices'
import { eventBus } from '@/lib/events'
import { ensureInvoiceNumber } from '@/lib/invoices/ensure-invoice-number'
import type { CustomIssuanceLine } from '@/lib/invoices/issuance-custom-lines'
import { recordManualInvoiceDelivery } from '@/lib/invoices/invoice-deliveries'
import { InvoicePDF } from '@/lib/invoices/pdf-template'
import { prepareInvoicePdfRender, buildSwishQrDataUrl } from '@/lib/invoices/pdf-render-helpers'
import { snapshotInvoicePayee } from '@/lib/invoices/invoice-payee'
import { invoicePdfFilename } from '@/lib/invoices/pdf-filename'
import {
hasRequiredInvoicePaymentAccount,
invoiceRequiresPaymentAccount,
} from '@/lib/invoices/payment-accounts'
import { hasRequiredSellerVatNumber } from '@/lib/invoices/seller-vat-number'
import { uploadDocument } from '@/lib/core/documents/document-service'
import type { Logger } from '@/lib/logger'
import type {
CompanySettings,
Customer,
EntityType,
Invoice,
InvoiceItem,
} from '@/types'
export interface IssuePartialFailure {
step: string
reason: string
}
/** Joined invoice row as the issuance flows fetch it. */
export type IssuableInvoice = Invoice & {
customer?: (Customer & { name?: string }) | null
items?: InvoiceItem[] | null
}
export type IssueAndBookResult =
| {
ok: true
journalEntryId: string | null
partialFailures: IssuePartialFailure[]
}
| { ok: false; errorCode: string; details?: Record<string, unknown> }
export interface IssueAndBookOptions {
supabase: SupabaseClient
companyId: string
userId: string
/**
* The draft invoice (with customer + items joined). Never a credit note:
* credit-note issuance lives in issue-credit-note.ts and stays on the
* mark-sent route.
*/
invoice: IssuableInvoice
settings: CompanySettings
log: Logger
/**
* User-edited journal lines from the mark-sent body. Bulk paths pass none:
* generated lines book as-is.
*/
customLines?: CustomIssuanceLine[] | null
}
/**
* Archive the issued invoice's PDF as underlag so it remains retrievable even
* if the invoice row is later cancelled. Shared between the mark-sent route
* (real invoices and credit notes) and the bulk Bokför flow. Returns a partial
* failure instead of throwing: the issuance itself already committed.
*/
export async function archiveIssuedInvoicePdf(args: {
supabase: SupabaseClient
companyId: string
userId: string
invoice: IssuableInvoice
settings: CompanySettings
journalEntryId: string | null
originalInvoiceNumber?: string
log: Logger
}): Promise<IssuePartialFailure | null> {
const { supabase, companyId, userId, invoice, settings, journalEntryId, log } = args
try {
const items = ((invoice.items as InvoiceItem[] | null) ?? [])
.slice()
.sort((a, b) => a.sort_order - b.sort_order)
// The DB status flip already happened, but the in-memory `invoice` is
// stale and still reads 'draft': override here so the archived underlag
// isn't stamped "UTKAST: inte en giltig faktura".
const renderableInvoice = { ...(invoice as Invoice), status: 'sent' as const }
const paymentAccountRequired = invoiceRequiresPaymentAccount(invoice as Invoice)
const { branding, company: renderCompany } = await prepareInvoicePdfRender(
settings,
renderableInvoice.currency,
{ paymentAccountRequired, payee: renderableInvoice.payment_details ?? null },
)
const swishQrDataUrl = await buildSwishQrDataUrl(renderCompany, renderableInvoice)
const pdfBuffer = await renderToBuffer(
InvoicePDF({
invoice: renderableInvoice,
customer: invoice.customer as Customer,
items,
company: renderCompany,
originalInvoiceNumber: args.originalInvoiceNumber,
branding,
swishQrDataUrl,
}),
)
const filename = invoicePdfFilename({
companyName: settings.company_name,
customerName: (invoice.customer as Customer).name,
invoiceNumber: invoice.invoice_number,
invoiceId: invoice.id,
invoiceDate: invoice.invoice_date,
documentType: invoice.document_type,
isCreditNote: !!invoice.credited_invoice_id,
})
const pdfArrayBuffer = new Uint8Array(pdfBuffer).buffer as ArrayBuffer
await uploadDocument(
supabase,
userId,
companyId,
{
name: filename,
buffer: pdfArrayBuffer,
type: 'application/pdf',
},
{
upload_source: 'system',
journal_entry_id: journalEntryId ?? undefined,
},
)
return null
} catch (err) {
log.error('failed to archive invoice PDF on mark-sent', err as Error)
return {
step: 'pdf_archive',
reason: 'Fakturans PDF kunde inte arkiveras.',
}
}
}
/**
* Issue a draft invoice without sending an email: assign the F-number, flip
* the status to 'sent', and (under faktureringsmetoden with inline booking)
* create and link the revenue verifikat. Exactly the mark-sent semantics for
* a non-credit-note invoice; used by both POST /api/invoices/[id]/mark-sent
* and POST /api/invoices/bulk-book so the two can never drift apart.
*
* Under kontantmetoden or deferred booking (#967) the invoice is marked sent
* without a journal entry, matching mark-sent.
*/
export async function issueAndBookInvoice(
opts: IssueAndBookOptions,
): Promise<IssueAndBookResult> {
const { supabase, companyId, userId, invoice, settings, log } = opts
const customLines = opts.customLines ?? null
const id = invoice.id
// An invoice that chose a bank account freezes that account's payee now,
// from the account as it is at issue; a chosen account that can no longer
// be used blocks issue instead of silently printing the company default.
const payeeSnapshot = await snapshotInvoicePayee(supabase, companyId, invoice as Invoice)
if (!payeeSnapshot.ok) {
return { ok: false, errorCode: payeeSnapshot.code, details: payeeSnapshot.details }
}
;(invoice as Invoice).payment_details = payeeSnapshot.payee
if (!hasRequiredInvoicePaymentAccount(settings, invoice as Invoice)) {
return {
ok: false,
errorCode: 'INVOICE_SEND_PAYMENT_ACCOUNT_MISSING',
details: { currency: (invoice as Invoice).currency },
}
}
if (!hasRequiredSellerVatNumber(settings, invoice as Invoice)) {
return { ok: false, errorCode: 'INVOICE_SEND_VAT_NUMBER_MISSING' }
}
// Assign the number only after all payment-instruction guards pass.
try {
await ensureInvoiceNumber(supabase, companyId, invoice as Invoice)
} catch (err) {
log.error('failed to assign invoice number on mark-sent', err as Error)
return { ok: false, errorCode: 'INVOICE_CREATE_NUMBER_ASSIGN_FAILED' }
}
const entityType = await resolveCompanyEntityType(supabase, companyId, settings.entity_type)
// Compare-and-set prevents two concurrent requests from posting two journal
// entries for the same draft.
const { data: updatedRows, error: updateError } = await supabase
.from('invoices')
.update({ status: 'sent' })
.eq('id', id)
.eq('company_id', companyId)
.eq('status', 'draft')
.select('id')
if (updateError) {
log.error('invoice mark-sent status update failed', updateError)
return { ok: false, errorCode: 'INVOICE_MARK_SENT_STATUS_FAILED' }
}
if (!updatedRows || updatedRows.length === 0) {
return { ok: false, errorCode: 'INVOICE_MARK_SENT_RACE' }
}
// Only create journal entries for real invoices (not proformas or delivery notes)
const isRealInvoice = !invoice.document_type || invoice.document_type === 'invoice'
let journalEntryId: string | null = null
const partialFailures: IssuePartialFailure[] = []
// Custom lines only apply where issuance books inline; elsewhere they are
// deliberately ignored (documented in MarkInvoiceSentSchema). Log it so the
// mismatch is visible in audit review instead of vanishing silently.
if (customLines && (!isRealInvoice || !booksInvoicesOnIssue(settings))) {
log.warn('mark-sent: custom lines ignored (not on accrual book-at-issue path)', {
invoiceId: id,
lineCount: customLines.length,
})
}
if (isRealInvoice && booksInvoicesOnIssue(settings)) {
// #967: deferred companies fall past this branch (mark sent WITHOUT
// booking); ekonomi books later via POST /api/invoices/[id]/book, like
// under kontantmetoden.
try {
if (customLines) {
// Audit trail: distinguish user-edited bookings from generated ones.
log.info('mark-sent: booking user-edited custom lines', {
invoiceId: id,
userId,
lineCount: customLines.length,
})
}
const journalEntry = customLines
? await createInvoiceJournalEntry(
supabase,
companyId,
userId,
invoice as Invoice,
entityType,
invoice.customer?.name,
{ customLines },
)
: await createInvoiceJournalEntry(
supabase,
companyId,
userId,
invoice as Invoice,
entityType,
invoice.customer?.name,
)
if (journalEntry) {
journalEntryId = journalEntry.id
// Periodiserade lines: create schedules + catch-up dissolutions now
// that the revenue entry exists. Failures are logged, never fatal:
// the verifikat is committed. Skipped when the user edited the lines:
// the generated 29xx deferral may no longer exist in what was booked,
// and a schedule would then dissolve an interim balance that was
// never credited. User-edited lines book exactly as reviewed.
if (!customLines) {
const accrual = await createSchedulesForCustomerInvoice(
supabase,
companyId,
userId,
invoice as Invoice,
(invoice.items as InvoiceItem[] | null) ?? [],
journalEntry.id,
entityType,
)
if (accrual.failed > 0) {
log.error('accrual schedule creation failed on mark-sent', {
failed: accrual.failed,
})
partialFailures.push({
step: 'accrual_schedules',
reason: `${accrual.failed} periodisering(ar) kunde inte skapas`,
})
}
}
const { error: linkError } = await supabase
.from('invoices')
.update({ journal_entry_id: journalEntry.id })
.eq('id', id)
if (linkError) {
// Don't fail the issuance: the verifikat committed; only the link
// failed. But log it through the structured logger so it reaches log
// aggregation/alerting: this write silently no-ops when the
// journal_entry_id column is missing (it was absent in prod until the
// 20260613100000 migration), which leaves mark-paid unable to detect
// an already-booked sale.
log.error('mark-sent: journal_entry_id link to invoice failed', linkError, {
journalEntryId: journalEntry.id,
})
partialFailures.push({
step: 'journal_link',
reason: 'Verifikatet skapades men kunde inte kopplas till fakturan.',
})
}
} else {
partialFailures.push({
step: 'journal_entry',
reason: 'Ingen öppen bokföringsperiod hittades för fakturans datum.',
})
}
} catch (err) {
log.error('failed to create invoice journal entry on mark-sent', err as Error)
partialFailures.push({
step: 'journal_entry',
reason: 'Fakturans verifikat kunde inte skapas.',
})
}
}
// Fail-closed only when inline booking was supposed to happen: deferred
// (#967) and cash-method invoices are legitimately unbooked at this point.
if (isRealInvoice && booksInvoicesOnIssue(settings) && !journalEntryId) {
const { error: rollbackError } = await supabase
.from('invoices')
.update({ status: 'draft' })
.eq('id', id)
.eq('company_id', companyId)
.eq('status', 'sent')
.is('journal_entry_id', null)
if (rollbackError) {
log.error('failed to restore draft after mark-sent booking failure', rollbackError)
}
return { ok: false, errorCode: 'INVOICE_MARK_SENT_BOOK_FAILED' }
}
if (partialFailures.some((failure) => failure.step === 'journal_link')) {
return {
ok: false,
errorCode: 'INVOICE_MARK_SENT_REPAIR_REQUIRED',
details: { failure_steps: ['journal_link'] },
}
}
// Render and archive the PDF as underlag so it remains retrievable even if
// the invoice row is later cancelled. Mirrors the send route.
if (isRealInvoice) {
const pdfFailure = await archiveIssuedInvoicePdf({
supabase,
companyId,
userId,
invoice,
settings,
journalEntryId,
log,
})
if (pdfFailure) partialFailures.push(pdfFailure)
}
try {
await recordManualInvoiceDelivery({
supabase,
companyId,
userId,
invoiceId: id,
})
} catch (err) {
log.error('failed to record manual invoice delivery', err as Error)
partialFailures.push({
step: 'delivery_history',
reason: 'Utskicket kunde inte sparas i fakturans historik.',
})
}
await eventBus.emit({
type: 'invoice.sent',
payload: { invoice: { ...(invoice as Invoice), status: 'sent' }, companyId, userId },
})
return { ok: true, journalEntryId, partialFailures }
}