Fix/bank sync bas (#1284)

* fix(year-end): stop revaluing FX items that were not on the balance sheet

The year-end close ran currency revaluation as an unconditional step before
the irreversible close, and the revaluation queried LIVE open invoices with
no date scoping. An invoice issued after balansdagen, settled before it, or
never booked at all was therefore revalued into the year being closed,
writing down a 1510/2440 that stood at zero. Because the entry lands inside
the same run that closes the period, the only remedy left was a rattelse in
the following year.

The population is now measured as of balansdagen, reusing the reconstruction
the reskontra reports already use (fetchPaymentsAsOf / outstandingAsOf): the
invoice_date ceiling is unconditional (post-dated invoices make the bug
reachable for a current period too) and the widening to 'paid' applies only
to a historical date, where a since-settled invoice was still open then.

Rows that carry no balance-sheet exposure are skipped per row rather than per
company: an unbooked registration is not on 1510/2440. Deliberately NOT keyed
on accounting_method, since BFL 5 kap 2 § 3 st requires kontantmetoden
companies to book their outstanding fordringar/skulder at balansdagen, and
those converted rows are genuine exposure that ARL 4 kap. 13 § must value.

The readiness warning stays ungated on purpose: an unbooked FX row is exactly
what deserves a warning, because /book still posts it into the year about to
close and lockPeriod/closePeriod then removes that remedy for good.

The wizard preview now lists the per-invoice revaluation rows it will post
instead of three aggregate numbers, so the user approves line-level content
before the close.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(bookkeeping): reach accounts outside BAS 2026 from a verifikat rattelse

A user could not move a verifikat line to konto 8022: the picker reported no
such account and offered no way forward. 8022 was dropped from BAS 2026 (it
is in BAS 2018), so it is a legitimate company-specific underkonto rather
than a catalog gap. Verified against the official bas.se kontoplan that our
BAS reference already matches BAS 2026, so 8022 is deliberately NOT added to
it: seeding a retired account would push it onto every company.

StrikeLinesDialog and CorrectionEntryDialog were the only account pickers in
the app that never passed onCreateAccount, so their combobox rendered a dead
empty state. Both now open AddAccountDialog prefilled, then refetch the chart
and select the new account on the initiating line, leaving the half-finished
rattelse intact.

AccountCombobox closed its dropdown on the fourth digit of any committed
number, which hid the empty state before it was ever painted and made the
create affordance unreachable for exactly the numbers that need it. It now
closes only when the number matches something, so focus still advances to the
belopp field for real accounts.

No change to posting rules: correct_entry_lines_inline validates chart
membership, not BAS membership, and account creation already required the
same write role.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(vacation): adjust vacation accrual calculations for mid-year hires and update related logic

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

lib/salary/__tests__/calculation-engine.test.ts

@@ -7,6 +7,7 @@ import {
   calculateVacationAccrual,
   prorateBaseSalaryForPeriod,
 } from '../calculation-engine'
+import { calculateVacationPay } from '../absence-calculator'
 import type { PayrollConfig } from '../payroll-config'
 import type { TaxTableRate } from '../tax-tables'
 
@@ -641,8 +642,8 @@ describe('hardening: vacation rule contract', () => {
     )
     expect(r.grossSalary).toBe(40000)
     expect(r.vacationCompensation).toBe(0)
-    // dagslön 40000/21 × 0.43% × 25 ≈ 204.76
-    expect(r.vacationAccrual).toBeCloseTo(204.76, 1)
+    // månadslön 40000 × 0.43% × 25/12 ≈ 358.33
+    expect(r.vacationAccrual).toBeCloseTo(358.33, 1)
   })
 
   it('none: nothing accrued, nothing paid out', () => {
@@ -755,8 +756,48 @@ describe('hardening: sammalöneregeln', () => {
       }),
       config2026, emptyTaxRates
     )
-    // 40000/21 × 0.8% × 25 ≈ 380.95
-    expect(r.vacationAccrual).toBeCloseTo(380.95, 1)
+    // 40000 × 0.8% × 25/12 ≈ 666.67
+    expect(r.vacationAccrual).toBeCloseTo(666.67, 1)
+  })
+
+  it('values the tillägg on the monthly salary, not the dagslön', () => {
+    const r = calculateSalary(
+      makeBasicInput({
+        vacationRule: 'sammaloneregeln', monthlySalary: 36000,
+        lineItems: [baseLineItem(36000)],
+      }),
+      config2026, emptyTaxRates
+    )
+    // Semesterlagen 16a §: the tillägg is a share of the MONTHLY salary per
+    // vacation day (154.80/day here), and only the month's earned share
+    // (25/12 days) accrues. Valuing it off a dagslön (36000/21) and booking
+    // all 25 days every run produced 184.29, under-provisioning 2920 by ~43%.
+    expect(r.vacationAccrual).toBeCloseTo(322.5, 1)
+  })
+
+  it('accrues a day at exactly what absence-calculator later pays out for it', () => {
+    const monthlySalary = 36000
+    const semestertillaggRate = 0.0043
+    const run = calculateSalary(
+      makeBasicInput({
+        vacationRule: 'sammaloneregeln', monthlySalary, semestertillaggRate,
+        lineItems: [baseLineItem(monthlySalary)],
+      }),
+      config2026, emptyTaxRates
+    )
+    const accrualPerDay = run.vacationAccrual / (25 / 12)
+    const payoutPerDay = calculateVacationPay({
+      monthlySalary,
+      vacationDaysTaken: 1,
+      vacationRule: 'sammaloneregeln',
+      semestertillaggRate,
+      vacationDaysPerYear: 25,
+    }).tillagg
+
+    // 2920 is credited here and relieved there. When the two bases disagreed
+    // the liability drifted negative on every taken day, which is the defect
+    // this pins: provision and payout must value a day identically.
+    expect(accrualPerDay).toBeCloseTo(payoutPerDay, 2)
   })
 })
 
@@ -945,8 +986,8 @@ describe('calculateVacationAccrual (standalone export)', () => {
       vacationBasis: 40000,
     })
     expect(partTime.accrual).toBeCloseTo(fullTime.accrual / 2, 1)
-    // Independent check: 20000/21 × 0.43% × 25 ≈ 102.38
-    expect(partTime.accrual).toBeCloseTo(102.38, 1)
+    // Independent check: 20000 × 0.43% × 25/12 ≈ 179.17
+    expect(partTime.accrual).toBeCloseTo(179.17, 1)
   })
 
   it('semesterersattning: 0 accrual with the correct step label', () => {

lib/salary/__tests__/vacation-ledger.test.ts

@@ -65,6 +65,7 @@ describe('syncVacationLedgerForEmployees', () => {
     openRows?: Array<Record<string, unknown>>
     opening?: Array<Record<string, unknown>>
     savedLegacy?: number
+    employmentStart?: string
   }) => {
     mock.enqueue({ data: { salary_vacation_year_basis: over.basis ?? 'calendar' } }) // company_settings
     mock.enqueue({
@@ -74,6 +75,8 @@ describe('syncVacationLedgerForEmployees', () => {
           vacation_days_per_year: 25,
           vacation_days_saved: over.savedLegacy ?? 0,
           vacation_rule: 'procentregeln',
+          // Long-tenured by default so the pro-rating cases stay opt-in.
+          employment_start: over.employmentStart ?? '2015-01-01',
         },
       ],
     }) // employees
@@ -104,6 +107,49 @@ describe('syncVacationLedgerForEmployees', () => {
     expect(row.accrued_days).toBe(0)
   })
 
+  it('pro-rates entitled days for a mid-intjänandeår hire (Semesterlagen 7 §)', async () => {
+    // Hired 2025-05-19. For semesteråret starting 2026-04-01 the intjänandeår
+    // is 2025-04-01 to 2026-04-01 (365 days), of which 317 were employed:
+    // 317/365 x 25 = 21.71, rounded UP to 22. Reporting a flat 25 told the
+    // employee they had three paid days they had not earned.
+    queueBase({ basis: 'statutory_apr_mar', employmentStart: '2025-05-19' })
+
+    const result = await syncVacationLedgerForEmployees(supabase, COMPANY_ID, [EMPLOYEE_ID], '2026-07-13')
+    expect(result.ok).toBe(true)
+    const row = upserted![0]
+    expect(row.vacation_year_start).toBe('2026-04-01')
+    expect(row.entitled_days).toBe(22)
+  })
+
+  it('gives a full entitlement to someone employed the whole intjänandeår', async () => {
+    queueBase({ basis: 'statutory_apr_mar', employmentStart: '2015-01-01' })
+
+    const result = await syncVacationLedgerForEmployees(supabase, COMPANY_ID, [EMPLOYEE_ID], '2026-07-13')
+    expect(result.ok).toBe(true)
+    expect(upserted![0].entitled_days).toBe(25)
+  })
+
+  it('accrues from the employment date, not the vacation-year boundary', async () => {
+    // Hired 2026-07-01, three whole months into the year starting 2026-04-01
+    // as of 2026-10-15: 3/12 x 25 = 6.25, held to half days = 6.5. Counting
+    // from the year boundary instead would credit 12.5.
+    queueBase({ basis: 'statutory_apr_mar', employmentStart: '2026-07-01' })
+
+    const result = await syncVacationLedgerForEmployees(supabase, COMPANY_ID, [EMPLOYEE_ID], '2026-10-15')
+    expect(result.ok).toBe(true)
+    expect(upserted![0].accrued_days).toBe(6.5)
+  })
+
+  it('keeps the flat entitlement on a sammanfallande calendar year', async () => {
+    // Earning and taking share the year there, commonly with förskottssemester,
+    // so mid-year hires are a CBA question rather than a statutory one.
+    queueBase({ basis: 'calendar', employmentStart: '2026-05-19' })
+
+    const result = await syncVacationLedgerForEmployees(supabase, COMPANY_ID, [EMPLOYEE_ID], '2026-07-13')
+    expect(result.ok).toBe(true)
+    expect(upserted![0].entitled_days).toBe(25)
+  })
+
   it('seeds entitled + saved days from the cutover opening row', async () => {
     queueBase({
       opening: [

lib/salary/__tests__/work-schedule-threading.test.ts

@@ -81,24 +81,20 @@ describe('non-default schedule: 4-day week (divisor 17.33)', () => {
     expect(unpaid.amount).toBe(-1731.1)
   })
 
-  it('sammalöneregeln accrual values days by the schedule divisor', () => {
-    const fourDay = calculateVacationAccrual({
-      monthlySalary: 30000,
-      vacationRule: 'sammaloneregeln',
-      vacationDaysPerYear: 25,
-      semestertillaggRate: 0.0043,
-      vacationBasis: 30000,
-      dailyDivisor: divisor,
-    })
-    const fiveDay = calculateVacationAccrual({
+  it('sammalöneregeln accrual does NOT take the schedule divisor', () => {
+    const accrual = calculateVacationAccrual({
       monthlySalary: 30000,
       vacationRule: 'sammaloneregeln',
       vacationDaysPerYear: 25,
       semestertillaggRate: 0.0043,
       vacationBasis: 30000,
     })
-    // dailyRate 1731.1 vs 1428.57; tillägg = dailyRate x 0.43% x 25 days.
-    expect(fourDay.accrual).toBe(186.09)
-    expect(fiveDay.accrual).toBe(153.57)
+    // Semestertillägg is a share of the MONTHLY salary per vacation day, so a
+    // 4-day week earns the same tillägg as a 5-day week on the same monthly
+    // salary: 30000 x 0.43% x 25/12. The function deliberately exposes no
+    // divisor parameter; part-time is carried by vacationBasis instead.
+    // Previously this valued a day at monthly/divisor, which made the accrual
+    // vary with workdays per week and under-provisioned 2920 in every case.
+    expect(accrual.accrual).toBeCloseTo(268.75, 2)
   })
 })