Files
accounted/lib/tax/deadline-generator.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

675 lines
24 KiB
TypeScript

/**
* Deadline generator - creates tax deadlines based on company settings
*/
import { SupabaseClient } from '@supabase/supabase-js'
import { createLogger } from '@/lib/logger'
import { fetchAllRows } from '@/lib/supabase/fetch-all'
import type { TaxDeadlineType, DeadlineStatus } from '@/types'
const log = createLogger('deadline-generator')
import {
getApplicableDeadlineConfigs,
type CompanySettingsForDeadlines,
type DeadlineInstance,
} from './deadline-config'
import { adjustDeadlineToNextBankingDay } from './swedish-holidays'
/**
* Rolling generation horizons. Recurring skattekonto obligations (monthly
* and quarterly filings) only generate ~6 months ahead: nobody acts on a
* moms deadline 14 months out, and the rows just bury the near-term list.
* Annual obligations keep 12 months so year-end planning still gets
* warning. The daily backfill cron rolls the window forward: a row is
* created once its due date enters the horizon.
*
* The same cutoff MUST apply in generateTaxDeadlinesForUser and
* getExpectedUpcomingDeadlineKeys: if detection expected a row the
* generator refuses to create, the nightly cron would regenerate (and
* status-reset) the company every day forever.
*/
export const RECURRING_HORIZON_DAYS = 183
export const ANNUAL_HORIZON_DAYS = 365
/** Types on the recurring horizon; anything not listed defaults to annual. */
const RECURRING_HORIZON_TYPES = new Set<TaxDeadlineType>([
'moms_monthly',
'moms_quarterly',
'f_skatt',
'arbetsgivardeklaration',
'skatteinbetalning',
'periodisk_sammanstallning',
'oss_quarterly',
'ioss_monthly',
'intrastat_monthly',
'punktskatt_monthly',
])
function horizonEndFor(type: TaxDeadlineType, today: Date): Date {
const days = RECURRING_HORIZON_TYPES.has(type)
? RECURRING_HORIZON_DAYS
: ANNUAL_HORIZON_DAYS
const end = new Date(today)
end.setDate(end.getDate() + days)
return end
}
/**
* Fields in company_settings that affect tax deadline generation
*/
export const TAX_RELEVANT_FIELDS = [
'entity_type',
'moms_period',
'f_skatt',
'preliminary_tax_monthly',
'vat_registered',
'pays_salaries',
'employer_registered',
'employer_seasonal',
'fiscal_year_start_month',
'vat_taxable_base_over_40m',
'vat_has_eu_trade',
'vat_filing_method',
'periodisk_sammanstallning_enabled',
'periodisk_sammanstallning_period',
'periodisk_sammanstallning_filing_method',
'kontrolluppgifter_enabled',
'rot_rut_enabled',
'oss_enabled',
'ioss_enabled',
'intrastat_enabled',
'punktskatt_enabled',
'fyllnadsinbetalning_enabled',
] as const
export const DEADLINE_SETTINGS_SELECT =
'company_id, entity_type, moms_period, f_skatt, preliminary_tax_monthly, vat_registered, pays_salaries, employer_registered, employer_seasonal, fiscal_year_start_month, vat_taxable_base_over_40m, vat_has_eu_trade, vat_filing_method, periodisk_sammanstallning_enabled, periodisk_sammanstallning_period, periodisk_sammanstallning_filing_method, kontrolluppgifter_enabled, rot_rut_enabled, oss_enabled, ioss_enabled, intrastat_enabled, punktskatt_enabled, fyllnadsinbetalning_enabled' as const
/**
* Check if any tax-relevant fields changed
*/
export function didTaxFieldsChange(
oldSettings: Partial<CompanySettingsForDeadlines>,
newSettings: Partial<CompanySettingsForDeadlines>
): boolean {
for (const field of TAX_RELEVANT_FIELDS) {
if (oldSettings[field] !== newSettings[field]) {
return true
}
}
return false
}
export function hasTaxRelevantFields(body: Record<string, unknown>): boolean {
return TAX_RELEVANT_FIELDS.some((field) => Object.prototype.hasOwnProperty.call(body, field))
}
export function toDeadlineSettings(
settings: Partial<CompanySettingsForDeadlines>,
): CompanySettingsForDeadlines {
if (settings.entity_type !== 'aktiebolag' && settings.entity_type !== 'enskild_firma') {
throw new Error('Company entity type is required to generate tax deadlines')
}
return {
entity_type: settings.entity_type,
moms_period: settings.moms_period ?? null,
f_skatt: settings.f_skatt ?? true,
preliminary_tax_monthly: settings.preliminary_tax_monthly ?? null,
vat_registered: settings.vat_registered ?? false,
pays_salaries: settings.pays_salaries ?? false,
employer_registered: settings.employer_registered ?? null,
employer_seasonal: settings.employer_seasonal ?? false,
fiscal_year_start_month: settings.fiscal_year_start_month ?? 1,
vat_taxable_base_over_40m: settings.vat_taxable_base_over_40m ?? false,
vat_has_eu_trade: settings.vat_has_eu_trade ?? false,
vat_filing_method: settings.vat_filing_method ?? 'electronic',
periodisk_sammanstallning_enabled: settings.periodisk_sammanstallning_enabled ?? false,
periodisk_sammanstallning_period: settings.periodisk_sammanstallning_period ?? 'monthly',
periodisk_sammanstallning_filing_method:
settings.periodisk_sammanstallning_filing_method ?? 'electronic',
kontrolluppgifter_enabled: settings.kontrolluppgifter_enabled ?? false,
rot_rut_enabled: settings.rot_rut_enabled ?? false,
rot_rut_payment_years: settings.rot_rut_payment_years,
oss_enabled: settings.oss_enabled ?? false,
ioss_enabled: settings.ioss_enabled ?? false,
intrastat_enabled: settings.intrastat_enabled ?? false,
punktskatt_enabled: settings.punktskatt_enabled ?? false,
fyllnadsinbetalning_enabled: settings.fyllnadsinbetalning_enabled ?? false,
}
}
/**
* Decide whether a settings save should (re)generate tax deadlines.
*
* Regenerate when a tax-relevant field changed OR when the company has no
* system-generated deadlines yet. The second case is the common one: tax
* settings are filled at onboarding, so a later save with no tax-field change
* used to skip generation entirely and the deadlines page stayed empty even
* though the settings were "filled in". Backfilling an empty set is safe: there
* is no existing status/progress to clobber.
*/
export function shouldRegenerateTaxDeadlines(
taxFieldsChanged: boolean,
existingSystemDeadlineCount: number
): boolean {
return taxFieldsChanged || existingSystemDeadlineCount === 0
}
/**
* Format date to YYYY-MM-DD
*/
function formatDateISO(date: Date): string {
const year = date.getFullYear()
const month = String(date.getMonth() + 1).padStart(2, '0')
const day = String(date.getDate()).padStart(2, '0')
return `${year}-${month}-${day}`
}
/**
* Generate all tax deadlines for a user based on their company settings
*/
export async function generateTaxDeadlinesForUser(
supabase: SupabaseClient,
companyId: string,
settings: CompanySettingsForDeadlines,
years: number[] = []
): Promise<{ created: number; deleted: number }> {
// Default to current and next year if not specified
if (years.length === 0) {
const currentYear = new Date().getFullYear()
years = [currentYear, currentYear + 1]
}
// The ROT/RUT begäran deadline is data-dependent: a row for year Y only
// exists when Y has paid ROT/RUT invoices (Lag 2009:194 8 §, payment
// dates). Resolve the payment years here, in the one place that inserts
// and deletes rows, so every generation path agrees. Callers that pass
// pure settings (backfill detection) leave the field undefined and simply
// never expect rot_rut_begaran rows.
if (settings.rot_rut_enabled && settings.rot_rut_payment_years === undefined) {
const rotRutRows = await fetchAllRows<{ paid_at: string | null }>(({ from, to }) =>
supabase
.from('invoices')
.select('paid_at')
.eq('company_id', companyId)
.gt('deduction_total', 0)
.not('paid_at', 'is', null)
.order('id', { ascending: true })
.range(from, to),
)
settings = {
...settings,
rot_rut_payment_years: Array.from(
new Set(
rotRutRows
.filter((row) => row.paid_at)
.map((row) => Number(String(row.paid_at).slice(0, 4))),
),
),
}
}
// Get applicable deadline configs based on settings
const applicableConfigs = getApplicableDeadlineConfigs(settings)
const today = new Date()
today.setHours(0, 0, 0, 0)
const todayIso = formatDateISO(today)
const endDate = `${Math.max(...years) + 1}-12-31`
// Completed deadlines represent real filing progress and dismissed
// deadlines represent an explicit opt-out; preserve both and do not create
// a second pending row for the same obligation. The window starts a year
// before the earliest generated year, NOT today: a completed row can carry
// a superseded due date that already passed while the current statutory
// date is still ahead, and filtering on today would resurrect a pending
// row for an obligation the user already filed.
const completedFloor = `${Math.min(...years) - 1}-01-01`
const { data: preservedRows, error: preservedRowsError } = await supabase
.from('deadlines')
.select('tax_deadline_type, tax_period')
.eq('company_id', companyId)
.eq('source', 'system')
.or('is_completed.eq.true,dismissed_at.not.is.null')
.gte('due_date', completedFloor)
if (preservedRowsError) {
log.error('Error fetching completed/dismissed deadlines:', preservedRowsError)
throw preservedRowsError
}
const completedKeys = new Set(
(preservedRows ?? []).map(
(row: { tax_deadline_type: string | null; tax_period: string | null }) =>
`${row.tax_deadline_type}:${row.tax_period}`,
),
)
// Manual progress survives regeneration: a replacement row for the same
// obligation keeps its in_progress status instead of resetting to
// upcoming. This matters with the rolling horizon, where the backfill
// cron regenerates a company every time a new row enters the window.
const { data: inProgressRows, error: inProgressError } = await supabase
.from('deadlines')
.select('tax_deadline_type, tax_period, status')
.eq('company_id', companyId)
.eq('source', 'system')
.eq('is_completed', false)
.is('dismissed_at', null)
.eq('status', 'in_progress')
if (inProgressError) {
log.error('Error fetching in-progress deadlines:', inProgressError)
throw inProgressError
}
const inProgressKeys = new Set(
(inProgressRows ?? [])
.filter((row: { status?: string }) => row.status === 'in_progress')
.map(
(row: { tax_deadline_type: string | null; tax_period: string | null }) =>
`${row.tax_deadline_type}:${row.tax_period}`,
),
)
// Generate new deadlines
const deadlines: Array<{
company_id: string
title: string
due_date: string
deadline_type: 'tax'
priority: 'critical' | 'important' | 'normal'
is_completed: boolean
source: 'system'
status: DeadlineStatus
tax_deadline_type: TaxDeadlineType
tax_period: string
linked_report_type: string | null
linked_report_period: Record<string, unknown> | null
reminder_offsets: number[]
is_auto_generated: boolean
}> = []
for (const config of applicableConfigs) {
const horizonEnd = horizonEndFor(config.type, today)
for (const year of years) {
const instances = config.generateDates(year, settings)
for (const instance of instances) {
// Create the raw deadline date
const rawDate = new Date(instance.year, instance.month, instance.day)
// Adjust for banking days (skip weekends and holidays). EU-law
// deadlines (OSS/IOSS) opt out: their dates stand on weekends.
const adjustedDate = config.skipBankingDayAdjustment
? rawDate
: adjustDeadlineToNextBankingDay(rawDate)
const dueDate = formatDateISO(adjustedDate)
// Skip if the deadline is in the past
if (adjustedDate < today) {
continue
}
// Skip rows beyond the rolling horizon; the daily backfill creates
// them once they come into view.
if (adjustedDate > horizonEnd) {
continue
}
const deadlineKey = `${config.type}:${instance.period}`
if (completedKeys.has(deadlineKey)) {
continue
}
// Determine initial status based on days until deadline, keeping a
// manually set in_progress from the row being replaced.
const daysUntil = Math.ceil((adjustedDate.getTime() - today.getTime()) / (1000 * 60 * 60 * 24))
const status: DeadlineStatus = inProgressKeys.has(deadlineKey)
? 'in_progress'
: daysUntil <= 14 ? 'action_needed' : 'upcoming'
// Generate title from template
const title = config.titleTemplate.replace('{periodLabel}', instance.periodLabel)
// Create linked report period data
const linkedReportPeriod = createLinkedReportPeriod(instance, config.type)
deadlines.push({
company_id: companyId,
title,
due_date: dueDate,
deadline_type: 'tax',
priority: config.priority,
is_completed: false,
source: 'system',
status,
tax_deadline_type: config.type,
tax_period: instance.period,
linked_report_type: config.linkedReportType,
linked_report_period: linkedReportPeriod,
reminder_offsets: [14, 7, 1, 0],
is_auto_generated: true,
})
}
}
}
const uniqueDeadlines = Array.from(
new Map(
deadlines.map((deadline) => [
`${deadline.tax_deadline_type}:${deadline.tax_period}`,
deadline,
]),
).values(),
)
// Insert the replacement rows BEFORE deleting the old set. A failed insert
// then leaves the previous deadlines intact: the old delete-first order
// meant any insert failure (like the 23502 user_id regression) wiped the
// company's tax deadlines without replacing them.
//
// Not concurrency-safe: two overlapping regenerations (settings save racing
// the cron backfill) can each delete the other's freshly inserted rows and
// leave the company with fewer rows than expected. Accepted: the daily
// backfill cron detects the missing keys and repairs on its next run.
let newIds: string[] = []
if (uniqueDeadlines.length > 0) {
const { data: insertedData, error: insertError } = await supabase
.from('deadlines')
.insert(uniqueDeadlines)
.select('id')
if (insertError) {
log.error('Error inserting deadlines:', insertError)
throw insertError
}
newIds = (insertedData ?? []).map((d: { id: string }) => d.id)
}
// Delete the superseded system-generated deadlines for these years,
// excluding the rows just inserted. Dismissed rows survive: deleting one
// would erase the opt-out and let the next regeneration recreate the
// obligation as a fresh pending row.
let deleteQuery = supabase
.from('deadlines')
.delete()
.eq('company_id', companyId)
.eq('source', 'system')
.eq('is_completed', false)
.is('dismissed_at', null)
.gte('due_date', todayIso)
.lte('due_date', endDate)
if (newIds.length > 0) {
deleteQuery = deleteQuery.not('id', 'in', `(${newIds.join(',')})`)
}
const { data: deletedData, error: deleteError } = await deleteQuery.select('id')
if (deleteError) {
log.error('Error deleting existing deadlines:', deleteError)
throw deleteError
}
return {
created: uniqueDeadlines.length,
deleted: deletedData?.length || 0,
}
}
/**
* Create linked report period object for navigation
*/
function createLinkedReportPeriod(
instance: DeadlineInstance,
_type: TaxDeadlineType
): Record<string, unknown> | null {
const period = instance.period
// Parse the period string
if (period.includes('-Q')) {
// Quarterly: "2025-Q1"
const [year, quarter] = period.split('-Q')
return { year: parseInt(year), quarter: parseInt(quarter) }
}
if (period.includes('-') && period.length === 7) {
// Monthly: "2025-01"
const [year, month] = period.split('-')
return { year: parseInt(year), month: parseInt(month) }
}
if (period.includes('/')) {
// Fiscal year: "2024/2025"
const [startYear, endYear] = period.split('/')
return { startYear: parseInt(startYear), endYear: parseInt(endYear) }
}
// Annual: "2025"
if (/^\d{4}$/.test(period)) {
return { year: parseInt(period) }
}
return null
}
/**
* Regenerate tax deadlines for a user after settings change
*/
export async function regenerateTaxDeadlinesForUser(
supabase: SupabaseClient,
companyId: string,
newSettings: CompanySettingsForDeadlines
): Promise<{ created: number; deleted: number }> {
const currentYear = new Date().getFullYear()
return generateTaxDeadlinesForUser(supabase, companyId, newSettings, [currentYear, currentYear + 1])
}
interface DeadlineSettingsRow extends Partial<CompanySettingsForDeadlines> {
company_id: string
}
interface UpcomingDeadlineCompanyRow {
id: string
company_id: string
tax_deadline_type: string | null
tax_period: string | null
due_date: string | null
is_completed: boolean | null
dismissed_at: string | null
}
// The due date is part of the identity: rows created by older schedule logic
// keep their type and period but carry a superseded statutory date, and the
// repair loop must treat those as missing so they get regenerated.
function deadlineIdentity(
type: string | null,
period: string | null,
dueDate: string | null,
): string {
return `${type}:${period}:${dueDate}`
}
// Completed and dismissed rows use the looser type:period identity (no due
// date): a filed or opted-out obligation is satisfied even when its stored
// date comes from a superseded schedule, and the generator never replaces
// either kind, so flagging them by date would make the repair loop re-run
// for the same company every day without ever converging.
function completedIdentity(type: string | null, period: string | null): string {
return `${type}:${period}`
}
export function getExpectedUpcomingDeadlineKeys(
settings: CompanySettingsForDeadlines,
years: number[] = [],
fromDate: Date = new Date(),
): Set<string> {
if (years.length === 0) {
const currentYear = fromDate.getFullYear()
years = [currentYear, currentYear + 1]
}
const today = new Date(fromDate)
today.setHours(0, 0, 0, 0)
const keys = new Set<string>()
for (const config of getApplicableDeadlineConfigs(settings)) {
const horizonEnd = horizonEndFor(config.type, today)
for (const year of years) {
for (const instance of config.generateDates(year, settings)) {
const rawDate = new Date(instance.year, instance.month, instance.day)
const adjustedDate = config.skipBankingDayAdjustment
? rawDate
: adjustDeadlineToNextBankingDay(rawDate)
// Same window as the generator: past rows and rows beyond the
// rolling horizon are never expected.
if (adjustedDate >= today && adjustedDate <= horizonEnd) {
keys.add(deadlineIdentity(config.type, instance.period, formatDateISO(adjustedDate)))
}
}
}
}
return keys
}
export function findSettingsMissingUpcomingDeadlines(
settingsRows: DeadlineSettingsRow[],
upcomingDeadlineRows: UpcomingDeadlineCompanyRow[],
years: number[] = [],
fromDate: Date = new Date(),
): DeadlineSettingsRow[] {
const actualKeysByCompany = new Map<string, Set<string>>()
const completedKeysByCompany = new Map<string, Set<string>>()
for (const row of upcomingDeadlineRows) {
const keys = actualKeysByCompany.get(row.company_id) ?? new Set<string>()
keys.add(deadlineIdentity(row.tax_deadline_type, row.tax_period, row.due_date))
actualKeysByCompany.set(row.company_id, keys)
if (row.is_completed || row.dismissed_at) {
const completed = completedKeysByCompany.get(row.company_id) ?? new Set<string>()
completed.add(completedIdentity(row.tax_deadline_type, row.tax_period))
completedKeysByCompany.set(row.company_id, completed)
}
}
return settingsRows.filter((settings) => {
try {
const expectedKeys = getExpectedUpcomingDeadlineKeys(
toDeadlineSettings(settings),
years,
fromDate,
)
const actualKeys = actualKeysByCompany.get(settings.company_id) ?? new Set<string>()
const completedKeys = completedKeysByCompany.get(settings.company_id) ?? new Set<string>()
return Array.from(expectedKeys).some((key) => {
if (actualKeys.has(key)) return false
// key is `${type}:${period}:${dueDate}`; strip the date to compare
// against the completed set (periods never contain a colon).
const typeAndPeriod = key.slice(0, key.lastIndexOf(':'))
return !completedKeys.has(typeAndPeriod)
})
} catch {
// Include malformed settings so the repair loop logs the company-specific
// generation error without aborting recovery for every other company.
return true
}
})
}
// Paginate: PostgREST silently caps a plain .select() at 1000 rows, which
// would leave companies beyond the cap without deadlines.
async function fetchAllDeadlineSettings(supabase: SupabaseClient): Promise<DeadlineSettingsRow[]> {
return fetchAllRows<DeadlineSettingsRow>(({ from, to }) =>
supabase
.from('company_settings')
.select(DEADLINE_SETTINGS_SELECT)
.order('company_id', { ascending: true })
.range(from, to),
)
}
/**
* Generate tax deadlines for the new year for every company.
*/
export async function generateNewYearDeadlines(
supabase: SupabaseClient
): Promise<{ usersProcessed: number; totalCreated: number }> {
const newYear = new Date().getFullYear()
const allSettings = await fetchAllDeadlineSettings(supabase)
let usersProcessed = 0
let totalCreated = 0
for (const settings of allSettings) {
try {
const result = await generateTaxDeadlinesForUser(
supabase,
settings.company_id,
toDeadlineSettings(settings),
[newYear, newYear + 1]
)
usersProcessed++
totalCreated += result.created
} catch (err) {
log.error(`Error generating deadlines for company ${settings.company_id}:`, err)
}
}
return { usersProcessed, totalCreated }
}
/**
* Repair companies whose upcoming system tax deadlines are missing or carry
* dates from superseded schedule logic.
*/
export async function backfillMissingTaxDeadlines(
supabase: SupabaseClient,
): Promise<{ companiesScanned: number; companiesRepaired: number; totalCreated: number }> {
// Window starts a year back, not today: completed rows with a superseded
// (already passed) due date must still count as satisfied, otherwise the
// repair loop flags the company forever while the generator (correctly)
// refuses to recreate a filed obligation. Matches the generator's own
// completed-row floor.
const pastFloor = `${new Date().getFullYear() - 1}-01-01`
const [allSettings, upcomingDeadlineRows] = await Promise.all([
fetchAllDeadlineSettings(supabase),
fetchAllRows<UpcomingDeadlineCompanyRow>(({ from, to }) =>
supabase
.from('deadlines')
.select('id, company_id, tax_deadline_type, tax_period, due_date, is_completed, dismissed_at')
.eq('source', 'system')
.eq('deadline_type', 'tax')
.gte('due_date', pastFloor)
.order('id', { ascending: true })
.range(from, to),
),
])
const missingSettings = findSettingsMissingUpcomingDeadlines(allSettings, upcomingDeadlineRows)
let companiesRepaired = 0
let totalCreated = 0
for (const settings of missingSettings) {
try {
const result = await regenerateTaxDeadlinesForUser(
supabase,
settings.company_id,
toDeadlineSettings(settings),
)
companiesRepaired++
totalCreated += result.created
} catch (err) {
log.error(`Error repairing deadlines for company ${settings.company_id}:`, err)
}
}
return {
companiesScanned: allSettings.length,
companiesRepaired,
totalCreated,
}
}