Change Fiscal Year Shape

Plan — or perform — a deliberate re-cut of the fiscal-year shape (accountant, ZET-306).

PUT /accounting-settings refuses a change to fiscal_year_start_month or base_currency once the company has any gl_fiscal_year row, because nothing there re-cuts the existing years: one request would otherwise silently reinterpret how a whole tenant's books are divided into years. This route is the remedy that refusal names, and a refusal with no remedy beside it is a dead end rather than protection — onboarding auto-creates a Jan–Dec year and the accountant may only afterwards discover the client's books run Jul–Jun.

apply defaults to false, and that is the design. The default answer is the plan: every existing year with the window it has and the window it would get, or — when the re-cut is refused — the blockers with their counts, so the caller is told what is in the way rather than only that something is. Confirming with apply=true deletes the (unreferenced) posting periods, rewrites the year windows, writes the settings and records who did it and why (gl_fiscal_year_shape_change).

Refused with 409 whenever the books are not empty — any journal entry, a sealed year, a closed period, a VAT period, a period-derived artefact, or an irregular (stub/short) year whose window is not the twelve-month formula window. Re-cutting a year that holds postings moves entries between fiscal years, and with them the opening balances and any VAT already filed; that is an accounting migration and is deliberately not attempted here. 422 when the request changes nothing.

scoped_tx rather than db.tx(), deliberately: this route writes gl_fiscal_year rows guarded by a GIST exclusion constraint, and api/deps.py's IntegrityError mapping only runs under scoped_tx. Under db.tx() a raced constraint violation would answer 500 — the same defect ZET-296 recorded for GET …/accounting-settings?fiscal_year=.