Files
accounted/lib/salary/derive-absence-line-items.ts
T
MattssonandClaude Fable 5 b6332e9ff4 Fix/skv connection flow (#1015)
* feat(salary): one-click AGI submission with filing state machine and success feedback

The AGI panel required users to know that "Ladda ner AGI-fil" was the
generate step, then click submit, signing link, and kvittens manually.
A nollkorning filing stalled on "AGI-XML saknas" pointing at a UI path
that does not exist.

- New primary button "Lamna in till Skatteverket" chains the existing
  endpoints client-side: generate XML if missing, POST underlag, poll
  kontrollresultat, create signing link, open Mina Sidor in a tab opened
  synchronously at click (popup-blocker safe). Inline stepper shows each
  step; the four old buttons become collapsed advanced/recovery actions,
  auto-expanded in stale-draft and rejected states. XML download stays
  visible and free for manual filing.
- deriveAgiFilingState() + useAgiSubmission() lift the per-period
  submission record to the run page: the progress rail and salary hero
  now render the real state machine (generated, underlag inskickat,
  vantar pa BankID-signatur, inlamnad med kvittensnummer) instead of
  telling users to "lamna in" an already-submitted declaration.
- Success card with kvittensnummer and signature metadata once signed,
  plus a toast when a poll flips the state while the page is open.
- AGI kvittens cron every 15 min instead of every 2 h so filings signed
  on another device get stamped and emailed promptly.
- Advanced submit also auto-generates, and the stale "Lon -> AGI ->
  Generera" error text now points at the real buttons.

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

* fix(enable-banking): instant OAuth callback feedback and dead-attempt cleanup

The bank redirect landed on a blank page for the several seconds the
callback spent exchanging the PSD2 session and mirroring accounts, and
every failed connect attempt left a status='error' row that rendered
forever as an "Atgard kravs" card next to a successful retry, showing
duplicate connections to the same bank.

- Stream a branded "Slutfor bankanslutningen" progress page from the
  callback: the shell flushes before the session exchange starts and a
  script/meta redirect follows when the work completes, with a 30s
  slow-work escape hatch. Fast outcomes (denial, bad params, unknown
  state) keep their plain redirects.
- Delete never-activated connection rows (no session_id, no
  accounts_data) on denial or exchange failure, and sweep leftovers for
  the same bank on the next connect. Established connections keep their
  "Atgard krävs" card via the accounts_data guard; FKs are ON DELETE
  SET NULL so deletion has no dependents.
- Show "Banken ar ansluten: hamtar dina konton" while the settings
  panel loads after the callback instead of an anonymous spinner.

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

* fix(invoices): reject re-send of issued invoices and gate bookkeeping on the sent flip

A direct POST to /api/invoices/[id]/send against an already-issued
invoice re-emailed the customer and posted a second revenue verifikat
(createInvoiceJournalEntry has no dedup), overwriting journal_entry_id
and orphaning the first entry. Only the UI hid the button; the v1 route
and the MCP commit executor already rejected non-drafts.

- Non-draft invoices now return 409 INVOICE_ALREADY_SENT.
- The draft to sent status flip is an optimistic lock (status guard plus
  row-count check); journal entry, accrual schedules, PDF archival and
  the invoice.sent event only run for the request that won the flip.
- On a flip failure the journal entry is deferred: the row stays draft
  and a retry re-runs the pipeline, ending with exactly one verifikat.

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

* fix(invoices): payment links, failure visibility and sandbox guard for recurring auto-send

- sendInvoiceFromSchedule now auto-creates an online payment link via
  applyPaymentLinkToInvoice before rendering and passes the payment
  link QR to the PDF: parity with the dashboard and v1 send routes,
  which recurring invoices silently lacked.
- The recurring cron persists last_run_warning both when a claimed run
  throws (hourly retries stay visible on the schedule) and when a stale
  schedule is rolled forward, so a deterministic failure can no longer
  skip a month silently.
- Auto-send is blocked for sandbox companies at the email chokepoint
  (freeze-and-retain: the invoice is still generated as a draft),
  covering both the cron and the run-now route with one guard.

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

* feat(salary): close the Fortnox payroll API gaps (phases 1-4)

Payroll now runs end-to-end through the open API, including onboarding a
client from another payroll system, with every write staged for approval.

- v1: per-employee payslips (list/detail/PDF), payslip line writes,
  run roster attach/remove, absence ranges (per-day storage), jamkning
  fields, cutover opening balances (single + atomic bulk PUT), vacation
  balance + vacation-year-close. PUT added to the wrapper's idempotency/
  test-key set (test keys could otherwise write through PUT).
- MCP: 10 new tools (get_employee/get_payslip/list_absence/
  get_vacation_balance reads + staged update_payslip_line,
  register_absence, create_employee, update_employee,
  set_employee_opening_balances, close_vacation_year), executors, risk
  tiers, op-type CHECK expansions. create_employee encrypts personnummer
  at staging: pending_operations never holds plaintext.
- Scope-map audit retrofit: 11 formerly unmapped tools now scoped;
  BREAKING for keys that relied on the 4 default-allow writes.
- Cutover: employee_opening_balances (derived lock trigger, self-unlocks
  on run correction), engine YTD/karens/liability integration,
  Ingaende saldon section in the employee editor.
- Arbetsschema-lite: employees.hours_per_week/workdays_per_week drive the
  hourly/daily divisors; legacy 173/21 preserved exactly at defaults so
  existing pay math is byte-identical.
- Vacation ledger + semesterberedning/arsavslut: recomputed per-year day
  balances (synced on book/correct, non-fatal), year-close with the
  min-20 floor, 5-year sparade-dagar expiry to forced payout, and a
  2920/2940 drift adjustment via the bookkeeping engine; Semester
  dashboard card with preview-then-confirm dialog.
- Fix: Zod 4 defaults leak through .partial(), which made every sparse
  employee PATCH fail validation and reset defaulted columns.

Migrations 20260713100000/101000/110000/121000/122000 (applied to
staging with version rows; prod via merge). vacation_ledger renamed from
20260713120000 to avoid colliding with vat_declaration_totals_rpc.

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

* perf: cut dashboard page-load latency (region, round trips, caching, VAT RPC)

The dominant cost was infrastructure: Vercel functions ran in iad1
(Washington D.C.) while Supabase (DB + auth) lives in eu-north-1
(Stockholm), so every request paid 4-5 transatlantic round trips of
auth + company resolution before doing any real work (measured
530-1900ms for single-query GETs in prod logs). Pin functions to arn1
and cut the redundant work on top:

- vercel.json: functions to arn1, same city as the database
- getActiveCompanyId: preference + first-membership queries run in
  parallel; the fallback result doubles as validation in the common
  single-company case (one round trip instead of two sequential)
- withRouteContext: Server-Timing header and authMs/companyMs/handlerMs
  in the op-completed log, so latency is attributable per phase
- dashboard layout: nav badge counts off the critical path; DashboardNav
  loads them client-side via the new use-worklist-badges SWR hook with
  debounced realtime revalidation
- swr (new dependency, approved): global provider; useCompanySettings
  shares one cache entry across consumers and renders from cache on
  back-navigation instead of re-showing skeletons
- /pending: realtime refetch debounced; bulk operations previously
  fired 4 requests per row-change event
- VAT declaration: new get_vat_declaration_totals RPC returns
  per-account totals, settlement-shape detection (#984) and
  source_type counts in ONE round trip instead of paging every
  entry+line through PostgREST. Account lists stay TS-side parameters
  so ACCOUNT_RUTA remains the single source of truth. Shape-exclusion
  coverage moved to tests/pg/vat-declaration-totals-rpc.pg.test.ts;
  DDL already applied to staging.
- bundle: CommandPalette lazy-mounts on first Ctrl/Cmd+K, AgentChat
  dynamic-imports the markdown parser, @vercel/speed-insights (new
  dependency, approved) added for real-user timings

The /salary fetch-waterfall fix from the same effort already landed
inside 2084a756.

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

* fix(invoices): settle öre-rounded payments from the mark-paid flow

An invoice with öresavrundning shows a rounded "Att betala" on the PDF;
the customer pays that amount (up to 50 öre off the stored öre total) and
the invoice-page mark-paid flow rejected it with
MATCH_AMOUNT_EXCEEDS_REMAINING: a dead end, while the bank-transaction
match flow already absorbed the residual to 3740.

- PaymentBookingDialog now proposes the rounded bank leg plus the 3740
  residual line (credit when rounded up, debit when rounded down),
  resolved via getDisplayTotal from the per-invoice override and
  company_settings.ore_rounding.
- settleInvoicePayment and the v1 mark-paid route absorb the sub-krona
  residual, gated by planInvoicePaymentForLines: absorption applies ONLY
  when the caller lines carry the exact residual on 3740; otherwise the
  strict plan applies (sub-krona partials stay partial, no-3740
  overshoots keep the 400), so the GL can never diverge from the AR
  sub-ledger.
- planInvoicePayment absorb-band boundary tightened to >= 1 kr: an
  exactly-1-kr overshoot used to slip past both the guard and the absorb
  branch and silently over-record paid_amount (pre-existing on the
  bank-match path).

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

* fix(security): resolve all 7 PR compliance findings

- ASVS V3.3: per-request CSP nonce on the enable-banking finalize page
  (mirrors the mcp-oauth consent page); inline scripts are nonce-bound
- ASVS V16: decouple callback finalize work from the response stream
  (eager promise + next/server after()) so a client disconnect cannot
  drop session persistence or the consent_granted audit emit
- ISO 27001 A.8.15: failed audit-event emits log through the structured
  logger with a stable message for log-based alerting
- ASVS V2.3: recurring-invoice cron and run-now routes resolve
  isSandboxCompany themselves and pass an explicit suppressAutoSend flag
  (defence in depth around the email chokepoint, freeze-and-retain kept)
- ISO 27001 A.8.11: stagePendingOperation rejects plaintext
  personnummer-bearing keys in params/preview_data (key-based guard;
  EF org numbers make value-matching unsafe)
- ASVS V4.5: employee PATCH body is truly sparse; cleared number fields
  are omitted instead of resetting DB values to hardcoded fallbacks
- ASVS V8.2.1: route-level tests pin the v1 cross-company deny (404 by
  convention, not 403) on the payslip PDF endpoint

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

* feat: implement vacation-year basis change validation and error handling

- Added tests to block vacation-year basis changes when open balances exist.
- Implemented error handling for open-balances guard query failures in the settings route.
- Enhanced absence route to reject reversed date ranges with a validation error.
- Updated absence handling to use atomic upserts instead of delete+insert for better performance and reliability.
- Refactored salary calculation logic to correctly handle age-based avgifter rates according to Skatteverket's rules.
- Improved error messaging for vacation year closure adjustments.
- Adjusted employee opening balances handling to preserve audit information during upserts.

* feat(settings): add validation to block vacation-year basis change with open balances

feat(absence): reject reversed date ranges in absence queries

fix(absence): update absence handling to use atomic upserts instead of delete+insert

fix(employee): improve validation for jamkning dates in employee updates

fix(opening-balances): ensure created_by field is preserved during upserts

test(absence): enhance tests for absence range and date validations

test(calculation): add tests for age-based avgifter rates and edge cases

test(semesterberedning): validate vacation year closure adjustments and error handling

test(employee-opening-balances): update tests to reflect changes in salary_run_employees schema

* fix(migrations): implement NOT VALID constraints for pending_operations and add validation migration

---------

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
2026-07-13 22:54:33 +02:00

467 lines
17 KiB
TypeScript
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
import type { SupabaseClient } from '@supabase/supabase-js'
import type { PayrollConfig } from './payroll-config'
import {
calculateVabDeduction,
calculateParentalLeaveDeduction,
} from './absence-calculator'
/**
* Derive payroll line items from per-day absence records.
*
* Why this lives outside the existing absence-calculator: those formulas
* still take `sickDays: number`. They cannot determine sjuklöneperiod
* boundaries, återinsjuknande, or högriskskydd: those depend on actual
* dates, which now live in `salary_absence_days`. This module is the
* bridge: it walks the per-day records and emits correctly-classified
* line items.
*
* Swedish payroll rules implemented:
* - **Sjuklöneperiod** (Sjuklönelagen) = first sick day → calendar-day 14.
* Day 1 is karensavdrag (one per period). Days 2-14 are sjuklön at 80%.
* Day 15+ is Försäkringskassan; employer pays nothing but must report.
* - **Återinsjuknande**: if the next sick day is within 5 calendar days of
* the previous sjuklöneperiod's last day, both merge: no new karens.
* - **Allmänt högriskskydd**: max 10 karensavdrag per rolling 12-month
* window (inclusive of the new one). The 11th is suppressed.
*
* For VAB and parental leave, days are aggregated within the pay period and
* forwarded to the existing calculators with YTD context.
*/
export type AbsenceType =
| 'sick'
| 'vab'
| 'parental'
| 'pregnancy'
| 'care_relative'
| 'study'
| 'unpaid_leave'
| 'other_leave'
export interface AbsenceDay {
absence_date: string // YYYY-MM-DD
absence_type: AbsenceType
hours: number
}
export interface DerivedLineItem {
item_type: 'sick_karens' | 'sick_day2_14' | 'sick_day15_plus' | 'vab' | 'parental_leave' | 'unpaid_leave'
description: string
quantity: number
amount: number
is_taxable: boolean
is_avgift_basis: boolean
is_vacation_basis: boolean
is_gross_deduction: boolean
}
export interface AggregatedCounts {
sickDays: number
vabDays: number
parentalDays: number
unpaidLeaveDays: number
}
export interface DeriveResult {
lineItems: DerivedLineItem[]
aggregated: AggregatedCounts
/** At least one sick day in the pay period fell on segment day 15+ (Försäkringskassan reporting required). */
flagFkReporting: boolean
/** At least one segment passed day 8 in the period (läkarintyg expected). */
flagLakarintyg: boolean
}
interface SjukloneperiodSegment {
startDate: string
endDate: string
/** Number of *sick days* in this merged segment (not calendar days). */
sickDayCount: number
/** True if this segment is the continuation of a prior segment via
* återinsjuknande (gap 1-5 calendar days). No new karensavdrag. */
isAterinsjuknande: boolean
}
const ONE_DAY_MS = 24 * 60 * 60 * 1000
function dateOnly(s: string): Date {
return new Date(`${s}T00:00:00Z`)
}
function daysBetween(a: string, b: string): number {
return Math.round((dateOnly(b).getTime() - dateOnly(a).getTime()) / ONE_DAY_MS)
}
function addDays(d: string, n: number): string {
const t = new Date(dateOnly(d).getTime() + n * ONE_DAY_MS)
return t.toISOString().slice(0, 10)
}
/**
* Walk the (sorted ascending) sick dates and merge them into sjuklöneperioder
* using the SjLL återinsjuknande rule: gap of 1-5 calendar days = same
* period continues; gap ≥ 6 = new period.
*/
export function buildSjukloneperioder(sickDates: string[]): SjukloneperiodSegment[] {
if (sickDates.length === 0) return []
const sorted = [...new Set(sickDates)].sort()
const segments: SjukloneperiodSegment[] = []
let startDate = sorted[0]
let endDate = sorted[0]
let count = 1
const flush = (gapToNext: number | null) => {
segments.push({
startDate,
endDate,
sickDayCount: count,
// The *first* segment is never återinsjuknande (no prior period).
// For subsequent segments, this flag is set below when starting a new one.
isAterinsjuknande: false,
})
void gapToNext
}
for (let i = 1; i < sorted.length; i++) {
const date = sorted[i]
const gap = daysBetween(endDate, date)
if (gap === 0) continue
if (gap >= 1 && gap <= 5) {
// Within 5 calendar days: same period (contiguous OR återinsjuknande)
endDate = date
count += 1
continue
}
// gap > 5: close current segment, start new one
flush(gap)
startDate = date
endDate = date
count = 1
}
flush(null)
// Annotate isAterinsjuknande based on inter-segment gap (only meaningful if
// the gap from prior segment's end to this segment's start is 1-5 days,
// which the merge logic above already excludes: so this stays false. The
// återinsjuknande logic is fully captured by the merge above; we keep the
// flag for caller introspection if they pass in pre-segmented data.)
return segments
}
export interface DeriveInput {
monthlySalary: number
payrollConfig: PayrollConfig
/** Absence rows in the pay period being calculated. */
periodDays: AbsenceDay[]
/** All sick dates in the prior 12 months (excluding the period). Needed
* to merge segments across pay periods (a period that started in the
* previous month already consumed some of the 14-day window) and to
* count karensavdrag for högriskskydd. */
lookbackSickDates: string[]
/** Year-to-date VAB days for this employee, excluding the current period. */
vabDaysYtd: number
/** Parental leave days in the current pregnancy window (best-effort:
* defaults to calendar-year aggregate). */
parentalDaysPregnancyYtd: number
/** Cutover state (payroll gap-closure 2.2): karens periods in the 12
* months before cutover NOT represented by imported salary_absence_days
* rows. Added to the högriskskydd window count so a mid-year switcher's
* cap position carries over. The caller zeroes this once the lookback
* window no longer overlaps pre-cutover time. */
karensPeriodsAdjustment?: number
/** Work-schedule daily-rate divisor (arbetsschema-lite). Defaults to the
* legacy 21 (5-day week); part-time schedules pass
* dailyDivisor(workdays_per_week) from lib/salary/work-schedule. */
dailyDivisor?: number
}
export function deriveAbsenceLineItems(input: DeriveInput): DeriveResult {
const { monthlySalary, payrollConfig, periodDays } = input
const lineItems: DerivedLineItem[] = []
const r = (x: number) => Math.round(x * 100) / 100
const periodSickDates = periodDays
.filter(d => d.absence_type === 'sick')
.map(d => d.absence_date)
const vabDays = periodDays.filter(d => d.absence_type === 'vab')
const parentalDays = periodDays.filter(d => d.absence_type === 'parental')
const unpaidLeaveDays = periodDays.filter(d => d.absence_type === 'unpaid_leave')
let flagFkReporting = false
let flagLakarintyg = false
if (periodSickDates.length > 0) {
const periodMin = periodSickDates[0]
// Build segments over (lookback ∪ period). Segments may straddle the
// boundary; we need the full picture to classify each period day's
// index within its segment.
const allSickDates = [...input.lookbackSickDates, ...periodSickDates]
const segments = buildSjukloneperioder(allSickDates)
// Allmänt högriskskydd (Sjuklönelagen 11§): from the 11th sjuklöneperiod
// within a rolling 12-month window, no karensavdrag is made.
//
// Interpretation: we count *sjuklöneperioder* in the lookback window. The
// law's phrasing: "från och med den 11:e sjukperioden under en
// tolvmånadersperiod görs inget karensavdrag": keys the cap to the
// period count. An alternative reading is that cap-suppressed periods
// shouldn't count toward future windows (only periods that actually
// had karens deducted). That requires persisting per-period karens-
// deduction state, which Accounted doesn't yet do. The period-count
// reading can over-suppress karens for an employee who hits the cap
// repeatedly: softer error than the opposite.
//
// TODO: persist per-period karens deduction state if the period-count
// reading produces complaints in the field.
const cap = payrollConfig.maxKarensavdragPerYear ?? 10
const cutoff = addDays(periodMin, -365)
const lookbackOnlySegments = buildSjukloneperioder(
input.lookbackSickDates.filter(d => d >= cutoff),
)
// Cutover adjustment: karens periods from the previous payroll system
// that were never imported as day rows. Over-suppression of karens is
// the softer error (consistent with the period-count reading above).
let karensInWindow = lookbackOnlySegments.length + (input.karensPeriodsAdjustment ?? 0)
// weeklyRate stays monthly x 12/52 by construction (schedule-independent);
// only the DAILY rate scales with the workday schedule.
const dailyRate = r(monthlySalary / (input.dailyDivisor ?? 21))
const weeklyRate = r(monthlySalary * 12 / 52 * payrollConfig.sjuklonRate)
const karensAmount = r(weeklyRate * payrollConfig.karensavdragFactor)
let day2_14CountTotal = 0
let day15PlusCountTotal = 0
// Walk each segment that touches the period.
for (const seg of segments) {
// Skip segments that don't touch the period at all.
if (seg.endDate < periodMin) continue
if (seg.startDate > periodSickDates[periodSickDates.length - 1]) continue
const segmentStartsInPeriod = seg.startDate >= periodMin
// Karens for the segment? Day 1 of segment, only if it starts in this
// period and the högriskskydd cap isn't hit. (If the segment started
// in a prior pay period, the karens was already booked there; nothing
// to emit here.)
if (segmentStartsInPeriod) {
if (karensInWindow < cap) {
lineItems.push({
item_type: 'sick_karens',
description: `Karensavdrag (${seg.startDate})`,
quantity: 1,
amount: -karensAmount,
is_taxable: true,
is_avgift_basis: true,
is_vacation_basis: false,
is_gross_deduction: true,
})
karensInWindow += 1
} else {
// Suppressed by allmänt högriskskydd. The employee keeps day-1 pay
// (no karens deduction). Day 1 still consumed from the 14-day
// window but treated as paid normal: emit nothing for it.
}
}
// Classify each *period* sick day in this segment by its segment day
// index (calendar days from segment start, 1-based).
for (const d of periodSickDates) {
if (d < seg.startDate || d > seg.endDate) continue
const segDayIndex = daysBetween(seg.startDate, d) + 1
if (segDayIndex === 1 && segmentStartsInPeriod) {
// already accounted for as karens (or suppressed); skip
continue
}
if (segDayIndex >= 2 && segDayIndex <= 14) {
day2_14CountTotal += 1
if (segDayIndex >= 8) flagLakarintyg = true
} else if (segDayIndex >= 15) {
day15PlusCountTotal += 1
flagFkReporting = true
}
}
}
if (day2_14CountTotal > 0) {
const lostPay = r(dailyRate * day2_14CountTotal)
const sjuklon = r(dailyRate * payrollConfig.sjuklonRate * day2_14CountTotal)
lineItems.push({
item_type: 'sick_day2_14',
description: `Sjuklön dag 2-14 (${day2_14CountTotal} dagar)`,
quantity: day2_14CountTotal,
// Net deduction vs full pay = lostPay - sjuklon (employer pays 80%).
amount: -(lostPay - sjuklon),
is_taxable: true,
is_avgift_basis: true,
is_vacation_basis: true,
is_gross_deduction: true,
})
}
if (day15PlusCountTotal > 0) {
const lostPay = r(dailyRate * day15PlusCountTotal)
lineItems.push({
item_type: 'sick_day15_plus',
description: `Sjukfrånvaro dag 15+ (FK) (${day15PlusCountTotal} dagar)`,
quantity: day15PlusCountTotal,
// Employer pays nothing: full daily rate deducted.
amount: -lostPay,
is_taxable: true,
is_avgift_basis: false,
is_vacation_basis: false,
is_gross_deduction: true,
})
}
}
// ── VAB ────────────────────────────────────────────────────────────────
const vabCount = vabDays.length
if (vabCount > 0) {
const vab = calculateVabDeduction(monthlySalary, vabCount, input.vabDaysYtd, input.dailyDivisor)
lineItems.push({
item_type: 'vab',
description: `VAB (${vabCount} dagar)`,
quantity: vabCount,
amount: -vab.deduction,
is_taxable: true,
is_avgift_basis: true,
is_vacation_basis: vab.semesterGrundande,
is_gross_deduction: true,
})
}
// ── Parental leave ─────────────────────────────────────────────────────
const parentalCount = parentalDays.length
if (parentalCount > 0) {
const parental = calculateParentalLeaveDeduction(
monthlySalary,
parentalCount,
input.parentalDaysPregnancyYtd,
input.dailyDivisor,
)
lineItems.push({
item_type: 'parental_leave',
description: `Föräldraledighet (${parentalCount} dagar)`,
quantity: parentalCount,
amount: -parental.deduction,
is_taxable: true,
is_avgift_basis: true,
is_vacation_basis: parental.semesterGrundande,
is_gross_deduction: true,
})
}
// ── Unpaid leave (tjänstledighet utan lön) ─────────────────────────────
// Each day reduces gross pay by one daily rate (monthlySalary / 21: same
// convention used elsewhere in the engine). Not semestergrundande per SemL
// 17 § (only paid leave types accrue vacation).
//
// is_gross_deduction is deliberately false: the engine's Step 3 absence
// sum already subtracts items whose item_type is 'unpaid_leave', so setting
// the flag would double-count the amount in Step 4's gross_deduction sum.
const unpaidLeaveCount = unpaidLeaveDays.length
if (unpaidLeaveCount > 0) {
const dailyRate = r(monthlySalary / (input.dailyDivisor ?? 21))
const deduction = r(dailyRate * unpaidLeaveCount)
lineItems.push({
item_type: 'unpaid_leave',
description: `Tjänstledighet utan lön (${unpaidLeaveCount} dagar)`,
quantity: unpaidLeaveCount,
amount: -deduction,
is_taxable: true,
is_avgift_basis: true,
is_vacation_basis: false,
is_gross_deduction: false,
})
}
return {
lineItems,
aggregated: {
sickDays: periodSickDates.length,
vabDays: vabCount,
parentalDays: parentalCount,
unpaidLeaveDays: unpaidLeaveCount,
},
flagFkReporting,
flagLakarintyg,
}
}
/**
* Convenience: load all DB inputs and derive in one call. Used by the
* salary calculate route.
*/
export async function loadAndDeriveAbsence(params: {
supabase: SupabaseClient
companyId: string
employeeId: string
monthlySalary: number
payrollConfig: PayrollConfig
periodStart: string
periodEnd: string
/** See DeriveInput.karensPeriodsAdjustment. */
karensPeriodsAdjustment?: number
/** See DeriveInput.dailyDivisor. */
dailyDivisor?: number
}): Promise<DeriveResult> {
const { supabase, companyId, employeeId, periodStart, periodEnd } = params
const { data: periodRows, error: periodErr } = await supabase
.from('salary_absence_days')
.select('absence_date, absence_type, hours')
.eq('company_id', companyId)
.eq('employee_id', employeeId)
.gte('absence_date', periodStart)
.lte('absence_date', periodEnd)
.order('absence_date', { ascending: true })
if (periodErr) throw new Error(`Failed to load absence days: ${periodErr.message}`)
const periodDays = (periodRows ?? []) as AbsenceDay[]
const lookbackStart = addDays(periodStart, -365)
const { data: lookbackRows, error: lookbackErr } = await supabase
.from('salary_absence_days')
.select('absence_date')
.eq('company_id', companyId)
.eq('employee_id', employeeId)
.eq('absence_type', 'sick')
.gte('absence_date', lookbackStart)
.lt('absence_date', periodStart)
if (lookbackErr) throw new Error(`Failed to load absence lookback: ${lookbackErr.message}`)
const lookbackSickDates = (lookbackRows ?? []).map(r => r.absence_date as string)
const yearStart = `${periodStart.slice(0, 4)}-01-01`
const { data: vabYtd } = await supabase
.from('salary_absence_days')
.select('absence_date')
.eq('company_id', companyId)
.eq('employee_id', employeeId)
.eq('absence_type', 'vab')
.gte('absence_date', yearStart)
.lt('absence_date', periodStart)
const vabDaysYtd = vabYtd?.length ?? 0
const { data: parentalYtd } = await supabase
.from('salary_absence_days')
.select('absence_date')
.eq('company_id', companyId)
.eq('employee_id', employeeId)
.eq('absence_type', 'parental')
.gte('absence_date', yearStart)
.lt('absence_date', periodStart)
const parentalDaysPregnancyYtd = parentalYtd?.length ?? 0
return deriveAbsenceLineItems({
monthlySalary: params.monthlySalary,
payrollConfig: params.payrollConfig,
periodDays,
lookbackSickDates,
vabDaysYtd,
parentalDaysPregnancyYtd,
karensPeriodsAdjustment: params.karensPeriodsAdjustment,
dailyDivisor: params.dailyDivisor,
})
}