fix(bookkeeping): a following year's own IB no longer blocks nollställ, and a re-dated räkenskapsår gets the right name (#2286)

Customer report (Aisen & Adison AB, 2026-09-03): Fortnox years 2024-2026
imported first, then the first year 2022/2023 backfilled. Two bugs surfaced.

1. The backfilled year was saved as "Räkenskapsår 2027": CreatePeriodDialog
   seeds the next forward year and kept that name when the user re-dated the
   form. The name now follows the typed dates until the user edits the name
   (fiscalYearName exported from suggest-fiscal-period).

2. Nollställ of the backfilled year was refused with next_year_dependency
   because 2024 carried an opening-balance verifikat. Any IB in the next year
   counted as reliance, so a backfilled year could never be reset, while a
   next year WITHOUT an IB (whose balansrapport really rolls from this year)
   was allowed. Migration 20260904163000 redefines fiscal_year_reset_snapshot:
   the block fires only when the next year is locked, closed or has its own
   closing entry; a bokslut-generated IB is still refused via this year's
   closing_entry_id (year_end_state). The snapshot returns next_period
   {id, name, has_opening_balances} and the dialog states that the following
   year's IB stays as it is.

pg-real: reset-fiscal-year.pg.test.ts pins the narrowed guard (closed next
year, next year with closing entry, next year with its own IB survives the
reset untouched).

Co-authored-by: Jakob Wennberg <311770904+jakobwennberg-oss@users.noreply.github.com>
Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>

lib/bookkeeping/__tests__/suggest-fiscal-period.test.ts

@@ -1,6 +1,7 @@
 import { describe, it, expect } from 'vitest'
 import {
   computeSuggestedPeriod,
+  fiscalYearName,
   suggestSeedDate,
   resolveCurrentPeriodId,
 } from '../suggest-fiscal-period'
@@ -10,6 +11,22 @@ type Range = { period_start: string; period_end: string }
 const FY2024: Range = { period_start: '2024-01-01', period_end: '2024-12-31' }
 const FY2026: Range = { period_start: '2026-01-01', period_end: '2026-12-31' }
 
+describe('fiscalYearName', () => {
+  it('names a calendar year by its year', () => {
+    expect(fiscalYearName('2025-01-01', '2025-12-31')).toBe('Räkenskapsår 2025')
+  })
+
+  it('names a straddling year by both years', () => {
+    expect(fiscalYearName('2024-07-01', '2025-06-30')).toBe('Räkenskapsår 2024/2025')
+  })
+
+  it('names a backfilled first year that spans two calendar years by both years', () => {
+    // The customer case: the create dialog seeded "Räkenskapsår 2027" and the
+    // user re-dated the form to the company's first, extended year.
+    expect(fiscalYearName('2022-07-28', '2023-12-31')).toBe('Räkenskapsår 2022/2023')
+  })
+})
+
 describe('computeSuggestedPeriod', () => {
   it('suggests a calendar year around the entry date when there are no periods', () => {
     expect(computeSuggestedPeriod('2025-06-15', [])).toEqual({

lib/bookkeeping/suggest-fiscal-period.ts

@@ -28,13 +28,19 @@ export interface SuggestedPeriod {
  * A fiscal-year name: `Räkenskapsår 2025`, or `Räkenskapsår 2024/2025` when it
  * straddles two calendar years. Swedish by default to match the app's existing
  * fiscal-year naming (Swedish-first); the field stays editable in the dialog.
+ * Exported so the create dialog can keep the name in step with the dates the
+ * user actually types: a suggested "Räkenskapsår 2027" must not survive the
+ * user re-dating the year to 2022-07-01..2023-12-31. Callers pass full
+ * YYYY-MM-DD strings.
  */
-function periodName(start: string, end: string): string {
-  const startYear = Number(start.slice(0, 4))
-  const endYear = Number(end.slice(0, 4))
+export function fiscalYearName(start: string, end: string): string {
+  const startYear = start.slice(0, 4)
+  const endYear = end.slice(0, 4)
   return startYear === endYear ? `Räkenskapsår ${startYear}` : `Räkenskapsår ${startYear}/${endYear}`
 }
 
+const periodName = fiscalYearName
+
 /**
  * Suggest a fiscal period for the create dialog, given the date the user is
  * trying to book and the company's existing periods. Three cases:

lib/core/bookkeeping/__tests__/fiscal-year-reset.test.ts

@@ -35,6 +35,7 @@ const SNAPSHOT = {
     period_end: '2026-12-31',
   },
   counts: { vouchers: 7, documents_to_detach: 2 },
+  next_period: { id: 'period-2', name: '2027', has_opening_balances: true },
 }
 
 describe('getFiscalYearResetEligibility', () => {
@@ -52,6 +53,7 @@ describe('getFiscalYearResetEligibility', () => {
         blockers: [],
         period: SNAPSHOT.period,
         counts: SNAPSHOT.counts,
+        next_period: SNAPSHOT.next_period,
       },
     })
     expect(supabase.rpc).toHaveBeenCalledWith('get_fiscal_year_reset_eligibility', {

lib/core/bookkeeping/fiscal-year-reset.ts

@@ -56,6 +56,7 @@ export async function getFiscalYearResetEligibility(
       blockers: result.blockers ?? [],
       period: result.period!,
       counts: result.counts ?? { vouchers: 0, documents_to_detach: 0 },
+      next_period: result.next_period ?? null,
     },
   }
 }