Files
accounted/lib/tax/__tests__/deadline-generator.test.ts
T
MattssonandClaude Fable 5 87f0d5af48 fix: GH issues batch: deadlines opt-ins, SKV reconnect, narrative edit, payment-link gating (#1076)
* fix(errors): close remaining raw-message leaks after #1048 (#337)

Follow-up to PR #1048. No user-visible toast or response field can now
carry a raw engine or DB message; everything maps through getErrorMessage
or the structured-errors registry.

- get-error-message: only normalize a code-carrying Error instance into
  the structured path when the registry knows the code; unknown codes
  (Node system errors, stray third-party codes, Error-wrapped Postgres
  SQLSTATEs) fall through to pattern match, Swedish check, Postgres map
  and the status/context/generic fallbacks instead of returning the raw
  message. New Swedish-detection pattern for "ar last" phrases and a
  known-pattern row for "already has a journal entry".
- structured-errors: add CANNOT_EDIT_NON_DRAFT (409) and
  MANDATORY_DIMENSION_MISSING (400) rows, plus common Node network codes
  (ECONNREFUSED, ECONNRESET, ETIMEDOUT, ENOTFOUND, EAI_AGAIN, EPIPE) as
  retryable 503 transients with a Swedish message.
- pending-operations commit + bulk-commit routes: map executor error
  strings through getErrorMessage before responding (raw stays in logs);
  Swedish passes through, English falls to status-appropriate Swedish.
- pending page: toast via getErrorMessage, fixing raw English toasts and
  "[object Object]" for structured envelopes on commit/bulk/reject.
- transactions book + journal-entries routes: untyped catch and DB list
  errors no longer return err.message; mapped or static Swedish instead.
- invoice send + issue-credit-note: partial_failures reasons are now
  Swedish (raw provider/DB text logged, never returned).
- Tests: new unknown-code/Error-instance suite, registry rows asserted,
  route tests updated off the pinned raw-English expectations.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(skatteverket): target the räkenskapsår for yearly VAT redovisningsperiod

A yearly filer with a broken fiscal year has a Skatteverket period ending
in its FY-end month, not December, and the panel's year state is never
maintained in yearly mode (the year picker is replaced by the
räkenskapsår selector), so calls targeted the wrong period even for
calendar-FY companies filing after year end. The selected fiscal period
now rides through the whole chain: panel query strings, draft/validate/
submit bodies, buildMomsuppgift (which resolves the FY bounds so the
period id and the figures describe the same räkenskapsår), and the
staged-commit path. MCP callers without a fiscal period keep the
calendar fallback.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* feat(deadlines): group same-day skattekonto deadlines into one card

Moms, AGI and preliminärskatt legally share the skattekonto date (den
12:e), so a small monthly-moms employer saw 2-3 near-identical rows per
month. Two or more pending system rows of the skattekonto family on the
same due date now render as one grouped card with the date block once
and each obligation as a sub-row keeping its own confirm-to-complete
flow. Presentation only: rows, statuses, ICS feed unchanged.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* feat(deadlines): KU + ROT/RUT + long-tail opt-in deadlines, rolling horizon

Follow-ups from the #1028 audit left out of the #1057-#1060 fix stack,
each with its own condition modeling:

- kontrolluppgifter (KU10/KU20/KU31), due 31 Jan (SFL 24 kap. 1 §):
  opt-in flag suggested from ledger signals (2898 utdelning, 2393/2893
  ägarlån; deliberately not 2091, see DECISIONS.md), AB only, mirroring
  the #1059 EU-sales suggest-and-confirm pattern.
- rot_rut_begaran, due 31 Jan after the payment year (Lag 2009:194
  8 §): rows generated only for years with actually PAID ROT/RUT
  invoices, resolved inside the generator; invoice-derived suggestion.
- Long tail, explicit opt-in ('Fler deadlines'): OSS quarterly and IOSS
  monthly with a skipBankingDayAdjustment config flag (EU-law dates
  stand on weekends), Intrastat (10th banking day of the following
  month), punktskatt (ordinary skattedeklaration schedule), and
  fyllnadsinbetalning (12th of 2nd month over 30k / 3rd of 5th month,
  SFL 62:8 + 65 kap.). Kvarskatt deferred: needs a slutskattebesked
  date the app does not hold.
- Rolling generation horizon: recurring types ~6 months ahead, annual
  12 months, mirrored in the backfill expectation keys so the nightly
  cron never thrashes; regeneration now preserves manual in_progress
  status; one-time cleanup migration removes existing far-future rows.

Migrations also applied to the staging branch, together with the
previously missing 20260717xxxxxx deadline migrations (staging had
drifted and lacked dismissed_at).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(arsredovisning): keep narrative editable after year-end close

The narrative save endpoint refused writes whenever the fiscal period was
closed/locked, but Verkstall bokslut closes the period before the
arsredovisning text is ever written, so every legitimate save failed with
PERIOD_LOCKED and the PDF fell back to placeholder text.

The narrative is arsredovisning document text (ARL 6 kap.), not journal
rakenskapsinformation, so the bookkeeping period lock does not apply.
Saves are now refused only once a Bolagsverket submission for the period
is registrerad (ARSREDOVISNING_REGISTERED, 409); the filed artifact was
already frozen separately by the submissions immutability trigger.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(skatteverket): surface dead SKV connections and nudge reconnect

Prod has ~70 companies that connected Skatteverket before the post-connect
sync fix (#1010) and silently never synced skattekonto: the only reconnect
prompt lived in the settings panel nobody revisits.

- transactions-page banner when the connection is needs_reconsent or
  expired without refresh, linking to /settings/tax
- pre-connect note in the connect panel: approve ALL behorigheter on
  Skatteverket's consent page (previously only shown after a failure)
- wire the inert skattekonto.connection.expired event to an email nudge
  to the token owner; one send per consent episode via claim-first dedup
  in notification_log (type skv_connection_expired, partial unique index
  in migration 20260720090000, applied to staging)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(archive): per-year behandlingshistorik covers late-booked vouchers + Drive backup disclaimer

The per-fiscal-year archive filtered audit rows by created_at within the
period, dropping treatment history for bokslut entries, stornos and SIE
imports booked after year end (BFNAR 2013:2 kap 8). The year archive now
unions the date window with every audit row touching the period's journal
entries and lines, deduped by audit id; line rows (company_id NULL by
trigger design) are admitted via a scoped OR and reachable on the
service-role backup path. ARCHIVE_FORMAT_VERSION 2->3 forces a one-time
Drive re-upload so existing archives pick up the complete history. The
Drive card on /import Exportera and the LASMIG texts now state the Drive
copy is a convenience backup, not the BFL 7 kap legal archive.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(decisions): clarify Arsredovisning narrative save behavior on submission status

* feat(invoices): gate payment links behind invoice settings opt-in

The payment-link section (manual URL field + Stripe auto-create toggle)
was visible on every invoice and auto-created Stripe links on send for
any connected company. It is now opt-in per company:

- new company_settings.invoice_payment_links_enabled, default false for
  everyone (no grandfathering of Stripe-connected companies)
- invoice editor hides the whole section unless enabled; a draft that
  already carries a link still shows it so old links stay clearable
- enforced server-side in maybeCreatePaymentLinkForInvoice (after the
  provider lookup, so the extension-free core build never queries), so
  dashboard, v1, MCP and recurring sends all obey it
- new toggle on Settings -> Invoicing, saves instantly; sv/en strings

Migration applied to the staging branch; prod gets it on merge.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(tests): add invoice_payment_links_enabled to company settings fixture

The makeCompanySettings fixture missed the new required boolean, failing
the core-only build's type check of tests/helpers.ts. Default false,
matching the migration default.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: Emil <emilmattsson14@gmail.com>

* fix(review): address CodeRabbit, compliance and Swedish review findings

Round 2 of PR #1076 review feedback, one change per accepted finding:

- pending page: res.json() safe fallback in both commit paths so a
  non-JSON proxy response cannot surface a raw parser error
- bulk-commit: map operation status enums to Swedish display labels in
  the 'Redan hanterad' skip message
- payment-link settings: disable the toggle while a save is in flight
  to prevent out-of-order PUT responses
- deadlines group card: route all UI strings through next-intl
  (deadlines namespace, sv + en)
- archive export: scope the period audit entry lookup to
  posted/reversed, matching the rest of the export
- error tests: assert the exact registry English message for
  ECONNREFUSED to lock the no-leakage contract
- signal routes: log.warn when best-effort lookups swallow a Supabase
  error (forensics), keep fail-closed behavior
- narrative route: document that 'avslutad' submissions deliberately
  stay editable (never registered at Bolagsverket)
- VAT: yearly declarations without an explicit fiscalPeriodId now
  resolve the räkenskapsår ending in the target year from
  fiscal_periods instead of assuming a calendar FY (SFL 26 kap
  10-11 §§); calendar fallback only when no fiscal period exists
- deadlines: IOSS deadline no longer requires vat_registered
  (Art. 369s has no Swedish VAT registration prerequisite)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: Emil <emilmattsson14@gmail.com>

---------

Signed-off-by: Emil <emilmattsson14@gmail.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
2026-07-20 13:38:14 +02:00

405 lines
14 KiB
TypeScript

import { describe, it, expect, vi, beforeEach } from 'vitest'
import type { SupabaseClient } from '@supabase/supabase-js'
import {
ANNUAL_HORIZON_DAYS,
RECURRING_HORIZON_DAYS,
findSettingsMissingUpcomingDeadlines,
generateTaxDeadlinesForUser,
getExpectedUpcomingDeadlineKeys,
shouldRegenerateTaxDeadlines,
} from '../deadline-generator'
import type { CompanySettingsForDeadlines } from '../deadline-config'
const SETTINGS: CompanySettingsForDeadlines = {
entity_type: 'aktiebolag',
moms_period: 'monthly',
f_skatt: true,
preliminary_tax_monthly: 5000,
vat_registered: true,
pays_salaries: true,
employer_registered: null,
employer_seasonal: false,
fiscal_year_start_month: 1,
vat_taxable_base_over_40m: false,
vat_has_eu_trade: false,
vat_filing_method: 'electronic',
periodisk_sammanstallning_enabled: false,
periodisk_sammanstallning_period: 'monthly',
periodisk_sammanstallning_filing_method: 'electronic',
kontrolluppgifter_enabled: false,
rot_rut_enabled: false,
oss_enabled: false,
ioss_enabled: false,
intrastat_enabled: false,
punktskatt_enabled: false,
fyllnadsinbetalning_enabled: false,
}
// Current + next year (the generator's own default): with the rolling
// horizon, rows only generate within ~6-12 months of today, so a
// next-year-only window would be empty for most of the year.
const CURRENT_YEAR = new Date().getFullYear()
const GEN_YEARS = [CURRENT_YEAR, CURRENT_YEAR + 1]
/** Period string for next month (YYYY-MM): always inside the horizon. */
function nextMonthPeriod(): string {
const d = new Date()
d.setDate(1)
d.setMonth(d.getMonth() + 1)
return `${d.getFullYear()}-${String(d.getMonth() + 1).padStart(2, '0')}`
}
/**
* Recording mock: captures the order of insert/delete operations and the
* insert payload, so the tests can assert the insert-first/delete-after
* ordering that prevents regeneration failures from wiping deadlines.
*/
function makeRecordingSupabase(opts: {
insertError?: { code: string; message: string }
completedRows?: Array<{ tax_deadline_type: string; tax_period: string }>
inProgressRows?: Array<{ tax_deadline_type: string; tax_period: string; status: string }>
} = {}) {
const calls: string[] = []
let insertPayload: Array<Record<string, unknown>> | null = null
const from = vi.fn(() => {
const chain: Record<string, ReturnType<typeof vi.fn>> = {}
let isDelete = false
let isInProgressQuery = false
const self = () => chain
chain.insert = vi.fn((rows: Array<Record<string, unknown>>) => {
calls.push('insert')
insertPayload = rows
return {
select: vi.fn(async () =>
opts.insertError
? { data: null, error: opts.insertError }
: { data: rows.map((_, i) => ({ id: `new-${i}` })), error: null }
),
}
})
chain.delete = vi.fn(() => {
calls.push('delete')
isDelete = true
return chain
})
chain.eq = vi.fn((...args: unknown[]) => {
if (args[0] === 'status' && args[1] === 'in_progress') isInProgressQuery = true
return chain
})
chain.or = vi.fn(self)
chain.is = vi.fn(self)
chain.gte = vi.fn(self)
chain.lte = vi.fn(self)
chain.not = vi.fn((...args: unknown[]) => {
calls.push(`not(${String(args[2]).slice(0, 20)}…)`)
return chain
})
chain.select = vi.fn(() => {
if (isDelete) {
return Promise.resolve({ data: [{ id: 'old-1' }, { id: 'old-2' }], error: null })
}
return chain
})
chain.then = vi.fn((resolve: (value: unknown) => unknown) => Promise.resolve({
data: isInProgressQuery ? (opts.inProgressRows ?? []) : (opts.completedRows ?? []),
error: null,
}).then(resolve))
return chain
})
return {
supabase: { from } as unknown as SupabaseClient,
calls,
getInsertPayload: () => insertPayload,
}
}
beforeEach(() => {
vi.clearAllMocks()
})
describe('generateTaxDeadlinesForUser', () => {
it('inserts replacement rows before deleting the old set', async () => {
const { supabase, calls } = makeRecordingSupabase()
const result = await generateTaxDeadlinesForUser(supabase, 'company-1', SETTINGS, GEN_YEARS)
expect(calls[0]).toBe('insert')
expect(calls[1]).toBe('delete')
expect(result.created).toBeGreaterThan(0)
expect(result.deleted).toBe(2)
})
it('excludes the newly inserted rows from the delete', async () => {
const { supabase, calls } = makeRecordingSupabase()
await generateTaxDeadlinesForUser(supabase, 'company-1', SETTINGS, GEN_YEARS)
expect(calls.some((c) => c.startsWith('not('))).toBe(true)
})
it('builds rows owned by company_id, without a user_id field', async () => {
const { supabase, getInsertPayload } = makeRecordingSupabase()
await generateTaxDeadlinesForUser(supabase, 'company-1', SETTINGS, GEN_YEARS)
const rows = getInsertPayload()
expect(rows).not.toBeNull()
for (const row of rows!) {
expect(row.company_id).toBe('company-1')
expect('user_id' in row).toBe(false)
expect(row.source).toBe('system')
expect(row.is_auto_generated).toBe(true)
}
})
it('caps generation at the rolling horizon (6 months recurring, 12 months annual)', async () => {
const { supabase, getInsertPayload } = makeRecordingSupabase()
await generateTaxDeadlinesForUser(supabase, 'company-1', SETTINGS, GEN_YEARS)
const rows = getInsertPayload()
expect(rows).not.toBeNull()
const today = new Date()
today.setHours(0, 0, 0, 0)
const daysOut = (dueDate: string) =>
Math.round((new Date(`${dueDate}T00:00:00`).getTime() - today.getTime()) / 86_400_000)
const recurring = new Set([
'moms_monthly', 'moms_quarterly', 'f_skatt',
'arbetsgivardeklaration', 'skatteinbetalning', 'periodisk_sammanstallning',
])
for (const row of rows!) {
const limit = recurring.has(row.tax_deadline_type as string)
? RECURRING_HORIZON_DAYS
: ANNUAL_HORIZON_DAYS
expect(daysOut(row.due_date as string)).toBeLessThanOrEqual(limit)
}
// The old 17-month window is gone: nothing sits beyond a year out.
expect(rows!.every((row) => daysOut(row.due_date as string) <= ANNUAL_HORIZON_DAYS)).toBe(true)
// But the near-term rows are all there (monthly settings → rows exist).
expect(rows!.length).toBeGreaterThan(0)
})
it('does not delete existing deadlines when the insert fails', async () => {
const { supabase, calls } = makeRecordingSupabase({
insertError: { code: '23502', message: 'null value in column "user_id"' },
})
await expect(
generateTaxDeadlinesForUser(supabase, 'company-1', SETTINGS, GEN_YEARS)
).rejects.toMatchObject({ code: '23502' })
expect(calls).toContain('insert')
expect(calls).not.toContain('delete')
})
it('does not replace a completed future obligation with a new pending row', async () => {
const completedPeriod = nextMonthPeriod()
const { supabase, getInsertPayload } = makeRecordingSupabase({
completedRows: [{ tax_deadline_type: 'f_skatt', tax_period: completedPeriod }],
})
await generateTaxDeadlinesForUser(supabase, 'company-1', SETTINGS, GEN_YEARS)
expect(getInsertPayload()).not.toContainEqual(expect.objectContaining({
tax_deadline_type: 'f_skatt',
tax_period: completedPeriod,
}))
})
it('keeps a manually set in_progress status on the replacement row', async () => {
const period = nextMonthPeriod()
const { supabase, getInsertPayload } = makeRecordingSupabase({
inProgressRows: [
{ tax_deadline_type: 'f_skatt', tax_period: period, status: 'in_progress' },
],
})
await generateTaxDeadlinesForUser(supabase, 'company-1', SETTINGS, GEN_YEARS)
const replaced = getInsertPayload()!.find(
(row) => row.tax_deadline_type === 'f_skatt' && row.tax_period === period,
)
expect(replaced).toBeDefined()
expect(replaced!.status).toBe('in_progress')
// Other rows keep the computed status.
const other = getInsertPayload()!.find(
(row) => row.tax_deadline_type === 'f_skatt' && row.tax_period !== period,
)
expect(other?.status).not.toBe('in_progress')
})
})
describe('getExpectedUpcomingDeadlineKeys: banking-day handling', () => {
it('keeps EU-law deadlines (IOSS) on the raw date even when it is a Sunday', () => {
// 2030-03-31 (IOSS for February 2030) is a Sunday; the banking-day
// adjustment would move it to 2030-04-01, but EU deadlines stand.
const keys = getExpectedUpcomingDeadlineKeys(
{ ...SETTINGS, ioss_enabled: true },
[2030],
new Date(2030, 0, 1),
)
expect(keys.has('ioss_monthly:2030-02:2030-03-31')).toBe(true)
expect(keys.has('ioss_monthly:2030-02:2030-04-01')).toBe(false)
})
it('still shifts ordinary Skatteverket deadlines to the next banking day', () => {
// 12 January 2030 is a Saturday; the January f-skatt date is the 17th
// (a Thursday) so use February: 12 Feb 2030 is a Tuesday. Take May
// instead: 2030-05-12 is a Sunday → shifted to Monday 2030-05-13.
const keys = getExpectedUpcomingDeadlineKeys(SETTINGS, [2030], new Date(2030, 0, 1))
expect(keys.has('f_skatt:2030-05:2030-05-13')).toBe(true)
expect(keys.has('f_skatt:2030-05:2030-05-12')).toBe(false)
})
})
describe('findSettingsMissingUpcomingDeadlines', () => {
const fromDate = new Date(2030, 0, 1)
const years = [2030]
function rowsFor(
companyId: string,
keys: Set<string>,
isCompleted = false,
dismissedAt: string | null = null,
) {
return Array.from(keys, (key, index) => {
const [taxDeadlineType, taxPeriod, dueDate] = key.split(':')
return {
id: `${companyId}-${index}`,
company_id: companyId,
tax_deadline_type: taxDeadlineType,
tax_period: taxPeriod,
due_date: dueDate,
is_completed: isCompleted,
dismissed_at: dismissedAt,
}
})
}
it('returns only companies missing at least one expected obligation', () => {
const settings = [
{ company_id: 'company-1', ...SETTINGS },
{ company_id: 'company-2', ...SETTINGS },
]
const completeRows = rowsFor(
'company-1',
getExpectedUpcomingDeadlineKeys(SETTINGS, years, fromDate),
)
expect(findSettingsMissingUpcomingDeadlines(
settings,
completeRows,
years,
fromDate,
)).toEqual([settings[1]])
})
it('repairs a company that has F-tax deadlines but is missing VAT deadlines', () => {
const settings = [{ company_id: 'company-1', ...SETTINGS }]
const expectedKeys = getExpectedUpcomingDeadlineKeys(SETTINGS, years, fromDate)
const fTaxRows = rowsFor(
'company-1',
new Set(Array.from(expectedKeys).filter((key) => key.startsWith('f_skatt:'))),
)
expect(findSettingsMissingUpcomingDeadlines(
settings,
fTaxRows,
years,
fromDate,
)).toEqual(settings)
})
it('repairs a company whose rows carry dates from a superseded schedule', () => {
const settings = [{ company_id: 'company-1', ...SETTINGS }]
const staleRows = rowsFor(
'company-1',
getExpectedUpcomingDeadlineKeys(SETTINGS, years, fromDate),
).map((row) => ({ ...row, due_date: '2030-12-31' }))
expect(findSettingsMissingUpcomingDeadlines(
settings,
staleRows,
years,
fromDate,
)).toEqual(settings)
})
it('treats a completed obligation as satisfied even with a superseded due date', () => {
// A filed (is_completed) row keeps its old statutory date. The generator
// never replaces completed rows, so flagging it by date would make the
// repair loop re-run for this company every day without converging.
const settings = [{ company_id: 'company-1', ...SETTINGS }]
const completedStaleRows = rowsFor(
'company-1',
getExpectedUpcomingDeadlineKeys(SETTINGS, years, fromDate),
true,
).map((row) => ({ ...row, due_date: '2029-01-15' }))
expect(findSettingsMissingUpcomingDeadlines(
settings,
completedStaleRows,
years,
fromDate,
)).toEqual([])
})
it('treats a dismissed obligation as satisfied even with a superseded due date', () => {
// A dismissed row is an explicit opt-out. The generator never replaces
// dismissed rows, so flagging one by date would resurrect the obligation
// the user opted out of on every cron run.
const settings = [{ company_id: 'company-1', ...SETTINGS }]
const dismissedStaleRows = rowsFor(
'company-1',
getExpectedUpcomingDeadlineKeys(SETTINGS, years, fromDate),
false,
'2029-06-01T00:00:00Z',
).map((row) => ({ ...row, due_date: '2029-01-15' }))
expect(findSettingsMissingUpcomingDeadlines(
settings,
dismissedStaleRows,
years,
fromDate,
)).toEqual([])
})
it('still repairs missing pending obligations when other obligations are completed', () => {
const settings = [{ company_id: 'company-1', ...SETTINGS }]
const expectedKeys = getExpectedUpcomingDeadlineKeys(SETTINGS, years, fromDate)
// Only the F-tax obligations exist (completed); everything else is missing.
const completedFTaxRows = rowsFor(
'company-1',
new Set(Array.from(expectedKeys).filter((key) => key.startsWith('f_skatt:'))),
true,
)
expect(findSettingsMissingUpcomingDeadlines(
settings,
completedFTaxRows,
years,
fromDate,
)).toEqual(settings)
})
})
describe('shouldRegenerateTaxDeadlines', () => {
it('regenerates when a tax-relevant field changed', () => {
expect(shouldRegenerateTaxDeadlines(true, 42)).toBe(true)
})
it('regenerates when the company has no system deadlines yet, even with no field change', () => {
// The reported bug: settings were filled at onboarding, so a later save with
// no tax-field change never generated deadlines and the page stayed empty.
expect(shouldRegenerateTaxDeadlines(false, 0)).toBe(true)
})
it('does not regenerate when nothing changed and deadlines already exist', () => {
// Avoid clobbering existing status/progress on unrelated settings saves.
expect(shouldRegenerateTaxDeadlines(false, 12)).toBe(false)
})
})