Fix/invoice numbers (#365)

* feat: make invoice_number nullable and assign on send

- Updated the invoices table to allow invoice_number to be nullable.
- Modified the logic to assign invoice numbers only when the invoice status transitions to 'sent'.
- Refactored related code to handle nullable invoice numbers, including UI components and API routes.
- Added tests to ensure correct behavior when handling invoices with null invoice numbers.
- Introduced a utility function to display invoice numbers, defaulting to '(Utkast)' for drafts.

* fix: update fiscal period handling to return names of open periods in error messages

* fix: enhance period creation logic to account for company-wide bookkeeping lock-through

* fix: remove unnecessary customer_type field from customer insertion query

* fix: scope invoice number count query to specific companies to avoid test interference

* feat: Implement atomic invoice number generation and ensure compliance with invoice numbering rules

- Introduced `ensureInvoiceNumber` function to assign invoice numbers atomically, handling concurrency and ensuring compliance with document types.
- Updated invoice-related components to utilize the new `invoiceNumberDisplay` utility for consistent invoice number formatting.
- Added checks to ensure that invoices in non-draft statuses have valid invoice numbers, preventing violations of legal requirements.
- Created tests for the new invoice number generation logic, ensuring correct behavior under various scenarios, including concurrent requests.
- Added a draft banner to PDF templates for invoices without assigned numbers, clarifying their status to users.
- Updated database migrations to support the new atomic invoice number generation logic and enforce constraints on invoice statuses.

components/bookkeeping/CreatePeriodDialog.tsx

@@ -41,34 +41,36 @@ function computeSuggestedPeriod(entryDate: string, periods: FiscalPeriod[]) {
 
   if (entryDate < earliest.period_start) {
     // Backward: end = day before earliest start, start = 12 months back, 1st of month
-    const end = new Date(earliest.period_start + 'T00:00:00')
-    end.setDate(end.getDate() - 1)
+    // Use UTC throughout — local-time Date math + toISOString() shifts dates by
+    // the timezone offset (e.g. CET produces 2024-12-31 → 2025-12-30).
+    const end = new Date(earliest.period_start + 'T00:00:00Z')
+    end.setUTCDate(end.getUTCDate() - 1)
 
     const start = new Date(end)
-    start.setMonth(start.getMonth() - 11)
-    start.setDate(1)
+    start.setUTCMonth(start.getUTCMonth() - 11)
+    start.setUTCDate(1)
 
     const startStr = start.toISOString().split('T')[0]
     const endStr = end.toISOString().split('T')[0]
-    const startYear = start.getFullYear()
-    const endYear = end.getFullYear()
+    const startYear = start.getUTCFullYear()
+    const endYear = end.getUTCFullYear()
     const name = startYear === endYear ? `FY ${startYear}` : `FY ${startYear}/${endYear}`
 
     return { name, period_start: startStr, period_end: endStr }
   }
 
   // Forward: start = day after latest end, end = 12 months later (last day of month)
-  const start = new Date(latest.period_end + 'T00:00:00')
-  start.setDate(start.getDate() + 1)
+  const start = new Date(latest.period_end + 'T00:00:00Z')
+  start.setUTCDate(start.getUTCDate() + 1)
 
   const end = new Date(start)
-  end.setMonth(end.getMonth() + 12)
-  end.setDate(0) // Last day of previous month
+  end.setUTCMonth(end.getUTCMonth() + 12)
+  end.setUTCDate(0) // Last day of previous month
 
   const startStr = start.toISOString().split('T')[0]
   const endStr = end.toISOString().split('T')[0]
-  const startYear = start.getFullYear()
-  const endYear = end.getFullYear()
+  const startYear = start.getUTCFullYear()
+  const endYear = end.getUTCFullYear()
   const name = startYear === endYear ? `FY ${startYear}` : `FY ${startYear}/${endYear}`
 
   return { name, period_start: startStr, period_end: endStr }