Faktureringens serverdel — och två fel den grävde fram

Fakturering fanns som modell, vy och tester men aldrig som något en
server kunde utfärda. Nu finns tabellerna, vägarna och gränsen mellan
kund och utfärdare.

Beloppet tas aldrig emot. Det härleds ur organisationens faktiska
tillstånd — de konton som verkligen kan logga in, de moduler som
verkligen är påslagna — och ett anrop som ändå skickar rader eller
totalt avvisas med 400 i stället för att tigas ihjäl. Samma hållning som
mot okända fält i händelseschemat.

Fakturaraden är oföränderlig, skyddad av samma trigger som loggen. Det
får en följd som är lätt att missa: "betald" kan då inte vara en kolumn
som uppdateras. Betalningen är en egen händelse och statusen en
projektion av händelserna. En felaktig faktura rättas inte heller — den
bemöts av en kreditfaktura med omvänt tecken och ett granskbart skäl.

Utfärdaren är inte en användare. Ingen av rollerna i en verkstad är
motpart i avtalet, så en kunds administratör kan varken utfärda sin egen
faktura eller bokföra den som betald; utfärdandet kräver en egen nyckel,
och utan den i miljön utfärdas ingenting alls. Nummerserien är utan
luckor — en sequence hade varit billigare men lämnar hål vid rollback,
och ett underlag med hål i är en lista.

---- Vad som föll ut när sviten faktiskt kördes ------------------------

integrationstest.sh fanns men låg utanför CI, och den föll på andra
raden — i kod som inte hade med fakturering att göra:

C-7  Append-only-triggern på felsokning_arenden förbjöd ALL update. Två
     av radens kolumner är härledda efteråt: gallringsdatumet vid avslut
     och det blindade fordonsindexet. Alltså föll varje avslut med 500,
     efter att kvalitetsgrinden redan godkänt ärendet. Skyddet är nu
     kolumnvis: identitet och ursprung är fortfarande låsta, radering
     fortfarande omöjlig, men de fält systemet självt härleder får
     skrivas.

C-8  Fordonshistoriken sökte i klartext efter en identifierare som
     krypteras i vila. Jämförelsen kunde aldrig träffa: historiken
     svarade tomt på varje fordon, med 200. Det blindade indexet fanns
     just för den frågan och var aldrig inkopplat.

Bägge ligger i backenden till produktens centrala löfte — att ett
avslutat ärende är ett varaktigt underlag — och ingen av dem kunde synas
i en grön enhetssvit, eftersom ingen av dem kan falla utan en databas.
Sviten är därför ett eget CI-jobb nu.

Bevisad: 364 enhetstester, 100+ integrationskontroller mot riktig
Postgres, genomgången 4/4 ärenden. Spärren mot angivet belopp
mutationstestad — borttagen ger den 201 i stället för 400.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012EQg3rJsrQ1ZNTvkzmQAtt

felsokning/infra/postgres-init.sql

@@ -127,10 +127,40 @@ create trigger handelser_append_only
   before update or delete on felsokning_handelser
   for each row execute function forbjud_andring();
 
+-- Ärenderaden är inte en logg utan ett omslag, och två av dess kolumner
+-- är HÄRLEDDA av systemet efteråt: gallringsdatumet sätts vid avslut
+-- utifrån ärendetypen, och det blindade fordonsindexet skrivs när
+-- objektet identifieras.
+--
+-- Den tidigare triggern förbjöd all update och gjorde därmed avslut
+-- omöjligt: servern försökte sätta gallras_efter, databasen sa nej, och
+-- hela synken föll med 500. Kvalitetsgrinden hade redan godkänt ärendet
+-- — det var lagringen som vägrade, efteråt, av ett skäl som inte hade
+-- med ärendet att göra.
+--
+-- Skyddet är därför kolumnvis i stället för totalt: identitet, tillhörighet
+-- och ursprung kan inte ändras, radering är fortfarande omöjlig, men de
+-- fält systemet självt härleder får skrivas.
+create or replace function skydda_arende() returns trigger
+language plpgsql as $$
+begin
+  if TG_OP = 'DELETE' then
+    raise exception 'Ärenden kan inte raderas';
+  end if;
+  if (new.id, new.organisation_id, new.nummer, new.skapad, new.delningskod,
+      new.metodik_id, new.skapad_av, new.insatt)
+     is distinct from
+     (old.id, old.organisation_id, old.nummer, old.skapad, old.delningskod,
+      old.metodik_id, old.skapad_av, old.insatt) then
+    raise exception 'Ärendets historik kan inte ändras — endast härledda fält får sättas';
+  end if;
+  return new;
+end $$;
+
 drop trigger if exists arenden_append_only on felsokning_arenden;
 create trigger arenden_append_only
   before update or delete on felsokning_arenden
-  for each row execute function forbjud_andring();
+  for each row execute function skydda_arende();
 
 -- Live Share-delningar: återkallbara länkar med behörighetsnivå.
 -- (Åtkomststyrning, inte journal — därför ingen append-only-trigger:
@@ -248,3 +278,65 @@ create table if not exists prenumerationer (
   senaste_status text
 );
 create index if not exists prenumerationer_org on prenumerationer (organisation_id) where aktiv;
+
+-- ---- Fakturering (ALVA-PROC-0001) --------------------------------------
+--
+-- En utfärdad faktura ändras aldrig. Det är inte en ambition utan en
+-- egenskap i schemat: samma append-only-trigger som skyddar
+-- händelseloggen skyddar fakturaraden.
+--
+-- Det får en följd som är lätt att missa. "Betald" kan då inte vara en
+-- kolumn som uppdateras — en betalning är en HÄNDELSE som inträffar
+-- efter utfärdandet, och statusen är en projektion av de händelserna.
+-- Precis som ärendets tillstånd inte lagras utan härleds ur loggen.
+--
+-- Beloppet lagras som det räknades fram, i öre, tillsammans med hela
+-- underlaget. Skulle prislistan ändras nästa år står den gamla fakturan
+-- kvar oförändrad, med de rader och de priser som faktiskt gällde.
+create table if not exists fakturor (
+  id uuid primary key default gen_random_uuid(),
+  organisation_id uuid not null references organisationer(id),
+  -- Löpnumret är gemensamt för hela installationen och utan luckor:
+  -- ALVA är utfärdaren, organisationerna är mottagare. Se
+  -- nästaFakturanummer() i server.mjs för hur luckor undviks.
+  nummer bigint not null unique,
+  beteckning text not null unique,
+  utfardad date not null,
+  forfaller date not null,
+  valuta text not null,
+  totalt bigint not null,
+  -- Krediterar en tidigare faktura. Null för en vanlig faktura.
+  krediterar uuid references fakturor(id),
+  -- Hela det härledda dokumentet, fruset vid utfärdandet: rader,
+  -- underlag, à-priser, moms. Den som läser den om två år ska inte
+  -- behöva systemet för att förstå den.
+  dokument jsonb not null,
+  skapad timestamptz not null default now()
+);
+create index if not exists fakturor_org_idx on fakturor (organisation_id, nummer desc);
+
+drop trigger if exists fakturor_append_only on fakturor;
+create trigger fakturor_append_only
+  before update or delete on fakturor
+  for each row execute function forbjud_andring();
+
+-- Vad som hänt med en utfärdad faktura. Append-only av samma skäl som
+-- allt annat som utgör underlag: en registrerad betalning som kan
+-- backas bort tyst är inte ett underlag, den är en anteckning.
+create table if not exists fakturahandelser (
+  id uuid primary key default gen_random_uuid(),
+  faktura_id uuid not null references fakturor(id),
+  typ text not null check (typ in ('betald', 'krediterad')),
+  intraffade date not null,
+  -- Betalningsreferens, kreditorsak. Fritext, men aldrig tom.
+  uppgift text not null,
+  registrerad_av text not null,
+  insatt timestamptz not null default now()
+);
+create index if not exists fakturahandelser_faktura_idx
+  on fakturahandelser (faktura_id, insatt);
+
+drop trigger if exists fakturahandelser_append_only on fakturahandelser;
+create trigger fakturahandelser_append_only
+  before update or delete on fakturahandelser
+  for each row execute function forbjud_andring();