Der vollständige Zustandsraum
Fünf produktive Zustände bilden den Anstellungs-Lebenszyklus ab. Probezeit wird nicht als eigener State, sondern als Datenfeld am Vertrag geführt — sie ist eine Eigenschaft der Anstellung, kein Lebenszyklus-Schritt:
Die Vertragsdaten leben in einer dedizierten Entität arbeitsvertraege mit FK auf den Arbeitnehmer. Das erlaubt Anschlussverträge derselben Person sowie die Koexistenz mit terminierten Vorgänger-Workflows. Probezeit-Ende wird als generated column berechnet — Datenkonsistenz auf DB-Ebene erzwungen.
Sub-Workflow arbeitsvertragsabschluss mit Review-Schritt
Der wichtigste Sub-Workflow ist die Vertragserstellung. Sie läuft in fünf Zuständen und enthält eine Review-Schleife, die rückwärts erreichbar bleibt:
Zwei Eigenheiten gegenüber einem üblichen Vertrags-Workflow:
- Review-State zwischen Render und Signatur. Nach dem PDF-Render landet der Workflow in
entwurf_unterschriftsreif— der Verwalter sichtet das Ergebnis, bevor die Signaturkette startet. Tippfehler oder falsche Stundenlöhne werden hier abgefangen, nicht erst im signierten Vertrag. - „Vertragsentwurf bearbeiten” auch aus der Unterzeichnungsphase. Wenn der Arbeitnehmer beim Lesen noch Änderungen wünscht, kann der Verwalter aus
unterzeichnung_arbeitgeberzurück nachvertragsentwurfspringen. Vorlagen, Parameter, Wochenstunden, Lohn — alles editierbar; das alte PDF wird beim nächsten Render überschrieben.
PDF-Render-Pipeline
Der Editor läuft als Fullscreen-Overlay über dem Workflow-Drawer mit Param-Panel links und WYSIWYG-Editor rechts. Beim Klick auf „Vertrag speichern” rendert der Server die finale PDF aus drei Datenquellen:
Die Counterparty-Auflösung läuft komplett automatisch: {{arbeitnehmer.name}}, {{arbeitnehmer.geburtsdatum}}, {{arbeitnehmer.adresse}}, {{arbeitgeber.name}}, {{arbeitgeber.adresse}} und ähnliche Handlebars-Variablen werden aus den Stammdaten + den Tenant-Briefkopf-Einstellungen befüllt. Vertragsdaten wie {{vertrag.beginn}}, {{vertrag.monatslohn_brutto}}, {{vertrag.stunden_woche}} kommen aus der Vertrags-Tabelle. Freie Parameter wie Urlaubstage oder Steuerklasse werden im Editor-Param-Panel gepflegt und überschreiben Defaults.
Beispiel: Hausmeister H., Midijob 1.200 € / Monat, 8 Std/Woche
Herr H. wird als Hausmeister für drei Liegenschaften eingestellt, Midijob im Übergangsbereich. So sieht der Lebenszyklus aus der Master-Perspektive aus:
Drei Jahre Anstellung, vier Sub-Workflows, ein durchgängiger Audit-Trail. Die Personalakte ist im Workflow-Cockpit als Zeitachse sichtbar — inklusive Abmahnung als Voraussetzung für die spätere verhaltensbedingte Kündigung.
Probezeit-Frist als Async-Guard
Der wichtigste Frist-Mechanismus ist der Probezeit-Guard. Beim Auslösen einer Kündigung berechnet der Server vor dem Zustandsübergang zwei Werte:
probezeitAktiv— wahr, wenn das Eingangsdatum der Kündigung kleiner-gleichprobezeit_ende_amist. Dann gilt die 2-Wochen-Frist nach § 622 Abs. 3 BGB.arbeitgeberFristEingehalten— bei Arbeitgeber-Kündigung außerhalb der Probezeit gestaffelt nach Betriebszugehörigkeit (< 2 Jahre → 1 Monat, 2–4 Jahre → 1 Monat, 5–7 Jahre → 2 Monate, 8–9 Jahre → 3 Monate, 10–11 Jahre → 4 Monate, 12–14 Jahre → 5 Monate, 15–19 Jahre → 6 Monate, ab 20 Jahre → 7 Monate, jeweils zum Monatsende).
Beide Werte werden vor dem actor.send-Call ins Event-Payload geschrieben. Verletzt das geplante Arbeitsende die Frist, wird der Zustandsübergang pruefen_und_bestaetigen blockiert und der Verwalter sieht einen Hinweis: „Die arbeitsrechtliche Kündigungsfrist (§ 622 BGB) ist noch nicht eingehalten. Bitte prüfen Sie das Arbeitsende-Datum, die Kündigungsart und die Betriebszugehörigkeit oder lehnen Sie die Kündigung ab.”
Technisch erzwungene Compliance
Der Arbeitsvertrags-Workflow erzwingt drei Compliance-Eigenschaften, die in der täglichen Personalverwaltung häufig schwierig sind: Frist-Sicherheit (kein verfrühter Vertragsende-Termin durch Fristfehler), Vorlagen-Treue (jedes Vertragsdokument entsteht aus der zentralen Vorlagenbibliothek mit revisionssicherem Render-Stand) und Abmahnungs-Voraussetzungen (vor einer verhaltensbedingten Kündigung sind dokumentierte Abmahnungen im selben Workflow sichtbar — keine isolierten Excel-Listen).
Migration M261 legt die Workflow-Definitionen für alle sechs Maschinen an, M263 die Sub-Workflow-Bindings (Vertragsabschluss, Lohnanpassung, Stundenanpassung, Abmahnung, Kündigung), M264 die PDF-Datei-Referenz am Vertrag und M265 den Review-State entwurf_unterschriftsreif. Die operative Personalakte ergänzt sich aus dem aufgabe_status-Workflow für tagesaktuelle Tätigkeiten — die Trennung zwischen Anstellungs- und Aufgaben-Workflow bleibt sauber.
Phase 2 — Dokumente, Signatur, Stundenzettel, Gehalt, WEG
Auf der Master-Maschine aus Phase 1 setzen fünf produktive Erweiterungen auf, die ohne Eingriff in die XState-Maschinen umgesetzt wurden — alle bestehenden Tests bleiben grün, das Verhalten der Maschinen unverändert.
Versionierte Multi-Dokumente-Pipeline
Die ursprüngliche Skalar-Spalte am Vertrag wird durch eine eigene Tabelle ersetzt, in der pro Vertrag beliebig viele Dokumente versioniert abgelegt werden. Jedes Dokument hat eine Kategorie (Entwurf, Signatur Arbeitgeber, Signatur Arbeitnehmer, unterzeichneter Vertrag, Abmahnung, Kündigung, Arbeitszeugnis, Lohnabrechnung, Stundenzettel, sonstiges), eine eigene version_nr-Sequenz pro Kategorie und einen Workflow-Anker. Im Workflow-Drawer ist die Entwurfs-Historie als Liste mit Download-Links sichtbar — jede Re-Edit-Schleife produziert eine neue Version, das alte PDF bleibt erhalten. Ein Skribble-Envelope-Bezug ist bereits im Schema verankert, sodass spätere Signaturen direkt einer Dokumenten-Version zugeordnet werden können.
Qualifizierte elektronische Signatur via Skribble
Beide Signatur-States akzeptieren parallel zum Papier-Pfad eine elektronische Signatur. Klick auf „Per Skribble unterschreiben lassen” lädt das aktuelle Vertrags-PDF, erstellt einen Skribble-Envelope mit AES-Signaturstufe und versendet ihn an die hinterlegte E-Mail (Arbeitgeber-E-Mail aus den Mandanten-Einstellungen, Arbeitnehmer-E-Mail aus den Stammdaten). Der Webhook-Empfänger schließt den Workflow-Schritt automatisch ab, sobald Skribble den Status completed meldet. Voraussetzung für den Produktiv-Betrieb sind die Skribble-API-Zugangsdaten in den Mandanten-Secrets.
Monats-Stundenzettel aus Hausmeister-Erledigungen
Hausmeister-Erledigungen können seit Phase 2 mit dauer_minuten und einer Verknüpfung zum Arbeitnehmer erfasst werden. Eine Datenbank-View aggregiert pro Monat die Summe der Minuten und die Anzahl der Einsätze. Im Workflow-Drawer pro Vertrag erscheint ein Stundenzettel-Tab mit Monatswähler, Erledigungs-Liste und Brutto-Hochrechnung (Stunden × Stundenlohn, ohne SV/LSt). Der „Stundenzettel als PDF”-Button rendert einen DIN-5008-Brief mit Tabelle der Einsätze und legt ihn versioniert in der Dokumenten-Pipeline ab. Die Trennung zur echten Gehaltsabrechnung nach § 108 GewO ist bewusst — diese ist Compliance-Projekt für eine Folge-Phase.
SEPA-Credit-Transfer für Gehaltszahlungen
Im Gehaltszahlungs-Tab pro Vertrag legt der Verwalter eine Zahlung für einen konkreten Monat an (Betrag, Verwendungszweck, Auftraggeber-Bankkonto). Eine Eindeutigkeits-Regel auf Datenbank-Ebene verhindert doppelte Zahlungen pro Monat. Der Empfänger-Datensatz (Name, IBAN, BIC) wird als Snapshot kopiert — eine spätere Stammdaten-Änderung beim Arbeitnehmer ändert eine bereits angelegte Zahlung nicht.
Bewusst nicht implementiert ist die direkte Bank-API-Anbindung (Payment Initiation Service). Der Verwalter lädt die XML-Datei im Online-Banking seiner Bank selbst hoch und behält die Kontrolle über die Auslösung — analog zur SEPA-Lastschrift-Pipeline für Mietzahlungen. Eine künftige Erweiterung um Sammelläufe ist im XML-Builder bereits angelegt.
WEG-Anstellung mit Eigentümerbeschluss
Bei einer Anstellung im Rahmen einer WEG-Verwaltung gibt es im Wizard eine Checkbox „WEG-Anstellung — benötigt Eigentümerbeschluss”. Ist sie aktiv, wird ein Selektor mit allen angenommenen Beschlüssen des Mandanten eingeblendet — der Verwalter wählt den Beschluss aus, der die Anstellung autorisiert. Das Backend prüft den Status (angenommen / in_umsetzung / umgesetzt) und lehnt die Anlage ab, falls der Beschluss noch nicht durch ist. Eine Pre-Step-Mechanik im Workflow selbst wurde bewusst nicht eingebaut — der Beschluss läuft in seinem eigenen ETV-Lebenszyklus, der Vertrag referenziert nur. Lohnkosten können danach mit einem Klick als Position in einen konkreten Wirtschaftsplan eingespielt werden — Jahres-Brutto-Hochrechnung aus Stundenlohn × Wochenstunden × 52 oder Monatslohn × 12, Umlageschlüssel MEA als Default, idempotenter Upsert über die Verlinkung wirtschaftsplan_positionen.source_arbeitsvertrag_id.
Die fünf Phase-2-Erweiterungen sind durchgängig produktiv (Migrationen 266–270), die XState-Maschinen unverändert. Skribble erfordert API-Zugangsdaten in den Mandanten-Secrets; die SEPA-Pipeline erfordert einen gepflegten Creditor-Identifier in den Mandanten-Einstellungen.