Enter the personnel number, tell the two kinds of company car apart, record who to call

Three requests from use, one of which changes the schema's mind about
something.

The personnel number is no longer issued. It was GENERATED ALWAYS AS
IDENTITY, which refuses a supplied value outright — but it has to match Loga
and Interflex, and a number this application invents is unknown there, so the
same person ends up with two. Identity dropped, entered everywhere instead:
in the wizard, in the import, and validated against a duplicate with a
message that names the number.

Worth stating plainly: the column had no unique constraint. The identity
prevented collisions as a side effect, and once the value comes from outside
that side effect is gone. The constraint is the point now, and it was
missing.

Company cars distinguish Verbrenner from Elektro, tied to has_dienstwagen by
a CHECK so "E-KFZ" cannot appear against someone without a car. The list
filters on it — with, without, only electric, only combustion — which is the
question the report was really about; it was answerable before only through
an export and manual work.

Emergency contact is name, phone and relationship. Relationship stays free
text: the examples given — Gattin/Gatte, Schwester/Bruder, Freund — are not
a list that closes without telling someone their arrangement does not count.
Name and phone are all-or-nothing, in the database and in both forms: a name
without a number helps nobody, a number without a name does not say who
answers.

Two mistakes of mine on the way, both caught by checks I had written into
the migrations rather than by me:

  - The first CHECK on the car type would have permitted exactly the case it
    was written against. `art in (…)` yields NULL rather than false when the
    column is null, and a CHECK counts NULL as satisfied. It needs an
    explicit `is not null` in front.
  - The constraint was added before the backfill, so it rejected every
    existing row with a car.

Existing cars are recorded as Verbrenner, which is an assumption — but a
visible one: "Elektro" appears nowhere nobody confirmed it.

hire_employee and change_employee_data both had to learn the new columns.
They name their columns one by one, and what is missing there is dropped in
silence — the interface would have collected the fields and thrown them
away, which is what happened to the email address this morning.

Verified against the live database, all rolled back: a hire without a number
is refused, a duplicate is refused naming it, a freely chosen one goes
through; E-KFZ plus contact arrive intact; a contact without a phone is
refused. A change records both, with before and after in the audit detail.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

lib/import/load.ts

@@ -226,6 +226,13 @@ export async function laden(
         source: (txt(w.source) ?? "Extern") as never,
         is_betriebsrat: bool(w.is_betriebsrat, false),
         has_dienstwagen: bool(w.has_dienstwagen, false),
+        // Ohne Dienstwagen zwingend null, mit Dienstwagen zwingend gesetzt —
+        // so verlangt es chk_dienstwagen_art. Fehlt die Angabe in der Datei,
+        // gilt Verbrenner, wie im übernommenen Bestand.
+        dienstwagen_art: bool(w.has_dienstwagen, false) ? (txt(w.dienstwagen_art) ?? "Verbrenner") : null,
+        emergency_contact_name: txt(w.emergency_contact_name),
+        emergency_contact_phone: txt(w.emergency_contact_phone),
+        emergency_contact_relation: txt(w.emergency_contact_relation),
         is_laterale_fuehrung: bool(w.is_laterale_fuehrung, false),
         is_c_level: bool(w.is_c_level, false),
         entry_date: eintritt,
@@ -244,18 +251,15 @@ export async function laden(
         ),
     };
 
-    // Von Hand geschrieben statt über den Abfragebauer, wegen genau eines
-    // Wortes: OVERRIDING SYSTEM VALUE.
-    //
-    // personnel_number ist GENERATED ALWAYS AS IDENTITY — die Datenbank
-    // vergibt sie und weist einen eigenen Wert sonst ab. Für eine Übernahme
-    // aus einem Altsystem ist das die falsche Richtung: die Nummer steht auf
-    // Lohnzetteln, in Akten und auf Ausweisen. Ein Import, der sie neu
-    // würfelt, ist keine Übernahme.
+    // Weiterhin von Hand geschrieben, aber ohne OVERRIDING SYSTEM VALUE:
+    // personnel_number ist seit 20260811100000 keine Identitätsspalte mehr,
+    // sondern eine gewöhnliche Pflichtangabe — sie muss mit Loga und
+    // Interflex übereinstimmen und wird deshalb überall eingegeben, nicht
+    // vergeben. Für eine Identitätsspalte war das Schlüsselwort nötig; für
+    // eine gewöhnliche wäre es ein Fehler.
     const spalten = Object.keys(werte);
     const r = await sql<{ id: string; personnel_number: number }>`
       insert into employees (${sql.raw(spalten.map((s) => `"${s}"`).join(", "))})
-      overriding system value
       values (${sql.join(Object.values(werte).map((v) => sql.val(v)))})
       returning id, personnel_number
     `.execute(tx);
@@ -276,18 +280,9 @@ export async function laden(
   }
   bericht.Personen = personenZeilen.length;
 
-  // Den Zähler nachziehen. Ohne das vergibt die Datenbank für die nächste
-  // Neueinstellung eine Nummer, die der Import bereits verbraucht hat — und
-  // der eindeutige Index weist sie ab. Der Fehler träte erst Wochen später
-  // auf, beim ersten Eintritt nach der Übernahme.
-  if (personenZeilen.length > 0) {
-    await sql`
-      select setval(
-        pg_get_serial_sequence('employees', 'personnel_number'),
-        (select max(personnel_number) from employees)
-      )
-    `.execute(tx);
-  }
+  // Kein Fortschreiben eines Zählers mehr: es gibt keinen. Die Nummer wird
+  // bei jeder Einstellung eingegeben, und die Eindeutigkeit sichert der
+  // Index — beim Import wie im Assistenten.
 
   await einfuegen(tx, "position_assignments", besetzungen);