3bbf2a051b
* 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>
101 lines
4.0 KiB
TypeScript
101 lines
4.0 KiB
TypeScript
/**
|
|
* Non-default work-schedule threading (payroll gap-closure 4.2).
|
|
*
|
|
* The default-schedule regression proof is the EXISTING absence/accrual
|
|
* suites passing unchanged (they exercise the legacy 21 divisor). These
|
|
* tests cover the new path: a part-time schedule's divisor flows into sick,
|
|
* VAB, parental, unpaid-leave, and sammalöneregeln day valuations.
|
|
*/
|
|
import { describe, expect, it } from 'vitest'
|
|
import {
|
|
calculateVabDeduction,
|
|
calculateParentalLeaveDeduction,
|
|
calculateSjuklon,
|
|
} from '@/lib/salary/absence-calculator'
|
|
import { calculateVacationAccrual } from '@/lib/salary/calculation-engine'
|
|
import { deriveAbsenceLineItems, type AbsenceDay, type DeriveInput } from '@/lib/salary/derive-absence-line-items'
|
|
import { dailyDivisor } from '@/lib/salary/work-schedule'
|
|
import type { PayrollConfig } from '@/lib/salary/payroll-config'
|
|
|
|
const config = {
|
|
sjuklonRate: 0.8,
|
|
karensavdragFactor: 0.2,
|
|
maxKarensavdragPerYear: 10,
|
|
} as PayrollConfig
|
|
|
|
const days = (entries: Array<[string, AbsenceDay['absence_type']]>): AbsenceDay[] =>
|
|
entries.map(([d, t]) => ({ absence_date: d, absence_type: t, hours: 8 }))
|
|
|
|
const baseInput = (over: Partial<DeriveInput> = {}): DeriveInput => ({
|
|
monthlySalary: 30000,
|
|
payrollConfig: config,
|
|
periodDays: [],
|
|
lookbackSickDates: [],
|
|
vabDaysYtd: 0,
|
|
parentalDaysPregnancyYtd: 0,
|
|
...over,
|
|
})
|
|
|
|
describe('non-default schedule: 4-day week (divisor 17.33)', () => {
|
|
const divisor = dailyDivisor(4)
|
|
|
|
it('VAB deduction uses the schedule divisor', () => {
|
|
const fourDay = calculateVabDeduction(30000, 2, 0, divisor)
|
|
const fiveDay = calculateVabDeduction(30000, 2, 0)
|
|
// 30000 / 17.33 = 1731.1 per day vs 30000 / 21 = 1428.57.
|
|
expect(fourDay.deduction).toBe(3462.2)
|
|
expect(fiveDay.deduction).toBe(2857.14)
|
|
expect(fourDay.deduction).toBeGreaterThan(fiveDay.deduction)
|
|
})
|
|
|
|
it('parental leave deduction uses the schedule divisor', () => {
|
|
const result = calculateParentalLeaveDeduction(30000, 1, 0, divisor)
|
|
expect(result.deduction).toBe(1731.1)
|
|
})
|
|
|
|
it('sjuklön daily rate scales while the weekly karens base does not', () => {
|
|
const fourDay = calculateSjuklon(30000, 3, config, false, divisor)
|
|
const fiveDay = calculateSjuklon(30000, 3, config, false)
|
|
expect(fourDay.dailyRate).toBe(1731.1)
|
|
expect(fiveDay.dailyRate).toBe(1428.57)
|
|
// Karensavdrag derives from the WEEKLY rate (monthly x 12/52 x 80%),
|
|
// which is schedule-independent by construction.
|
|
expect(fourDay.karensavdrag).toBe(fiveDay.karensavdrag)
|
|
})
|
|
|
|
it('derived sick + unpaid-leave line items use the schedule divisor', () => {
|
|
const result = deriveAbsenceLineItems(
|
|
baseInput({
|
|
periodDays: days([
|
|
['2026-04-06', 'sick'],
|
|
['2026-04-07', 'sick'],
|
|
['2026-04-08', 'unpaid_leave'],
|
|
]),
|
|
dailyDivisor: divisor,
|
|
}),
|
|
)
|
|
const day2 = result.lineItems.find((li) => li.item_type === 'sick_day2_14')!
|
|
// Day 2 net deduction = dailyRate - dailyRate x 80% = 20% of 1731.1.
|
|
expect(Math.abs(day2.amount)).toBeCloseTo(1731.1 - 1731.1 * 0.8, 1)
|
|
const unpaid = result.lineItems.find((li) => li.item_type === 'unpaid_leave')!
|
|
expect(unpaid.amount).toBe(-1731.1)
|
|
})
|
|
|
|
it('sammalöneregeln accrual does NOT take the schedule divisor', () => {
|
|
const accrual = calculateVacationAccrual({
|
|
monthlySalary: 30000,
|
|
vacationRule: 'sammaloneregeln',
|
|
vacationDaysPerYear: 25,
|
|
semestertillaggRate: 0.0043,
|
|
vacationBasis: 30000,
|
|
})
|
|
// 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)
|
|
})
|
|
})
|