Files
accounted/lib
Jakob Wennberg 11e07b34c3 fix(sie-import): reject overlap-but-not-contain fiscal periods (#421)
* fix(sie-import): reject overlap-but-not-contain fiscal periods

ensureFiscalPeriod previously fell back silently to any partially-overlapping
fiscal_period when no period fully contained the SIE file's #RAR range. That
stamped every imported voucher with a fiscal_period_id whose date window
didn't cover the voucher's own entry_date — breaking the SIE invariant that
#VER dates fall inside #RAR and BFL 5 kap. (verifikationsnummer i obruten
serie per räkenskapsår). Reproduced in production: a customer with a broken
fiscal year (Mar–Feb) had their previous-year SIE collapse into a calendar
2026 period, mixing 116 prior-year vouchers into the current period's
voucher sequence.

Now: fully-contained → reuse; partial overlap → reject with a clear Swedish
message pointing at the period dates that would need to be fixed; no overlap
→ create a new period as before.

Adds a defense-in-depth pre-check in executeImport that rejects with a
Swedish error if any individual #VER date falls outside the resolved fiscal
period — catches multi-year SIE files (which gnubok does not yet support)
without producing corrupted journal entries.

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

* fix(sie-import): fail closed on period-fetch error in voucher-date guard

Greptile correctly flagged that the voucher-date guard wrapped the period
fetch in `if (resolvedPeriod)` without checking the .single() error. A
transient network error or RLS failure returned null for data, the guard
body skipped, and importVouchers ran with no date validation — the same
data-corruption path the guard exists to close.

Now: surface the fetch error to the user (Swedish) and abort the import.

Also switches the date comparison from millisecond timestamps to YYYY-MM-DD
string compare. SIE per spec is date-only and our parser normalizes to
midnight, but string compare matches the underlying DATE columns exactly and
removes a latent off-by-one risk on the period's last day if a future
parser change ever attached a time component to v.date.

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

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-08 17:17:36 +02:00
..
2026-05-06 11:12:02 +02:00
2026-05-08 15:42:06 +02:00
2026-03-21 00:47:54 +01:00
2026-05-05 09:53:37 +02:00
2026-05-06 14:08:38 +02:00
2026-02-24 16:06:36 +01:00
2026-05-05 09:53:37 +02:00
2026-04-29 16:32:26 +02:00
2026-05-08 15:42:06 +02:00
2026-05-08 15:42:06 +02:00
2026-05-06 11:12:02 +02:00
2026-05-06 11:12:02 +02:00
2026-04-22 18:14:01 +02:00
2026-05-06 11:12:02 +02:00
2026-04-15 11:17:39 +02:00
2026-05-05 09:53:37 +02:00
2026-05-06 11:12:02 +02:00
2026-05-08 15:42:06 +02:00
2026-04-29 16:32:26 +02:00
2026-04-09 16:22:51 +02:00