Zum Hauptinhalt springen

Mitarbeiter-Vertrag-Urlaube (EmployeeContractVacation)

Im FE-Master gibt es **keine eigenständige `/employee-contract-vacations`-Route**. Die Junction wird über das **Vertrag-Detail eines Mitarbeiters** bedient (Tab Urlaubs-Kontingente in `EmployeeContract`-Form). Der Frontmatter-Endpoint hier bezieht sich auf die BE-API.

Zweck

EmployeeContractVacation ist die Junction-Tabelle zwischen EmployeeContract und VacationType. Pro Mitarbeiter-Vertrag können mehrere Urlaubs-Kontingente konfiguriert werden — z. B. „20 Tage gesetzlicher Mindesturlaub" + „5 Tage Schwerbehinderten-Zusatz" + „6 Tage Tarif-Mehrurlaub".

Bei Vertrags-Finalisierung werden die VacationType-Stamm-Werte als Snapshot in den Junction-Eintrag übernommen — nachträgliche Änderungen am VacationType wirken nicht auf bereits aktive Verträge zurück (siehe Snapshot-Pattern).

Voraussetzungen

- Mitarbeiter mit aktivem Vertrag (siehe [Employee-Contracts](/employee-contracts)) - VacationType-Stammdaten gepflegt (siehe [Vacation-Types](/vacation-types)) - Berechtigung `view:EmployeeContractVacation`, `create/update/delete` typisch HR-SB / HR-L

Berechtigungen (CASL)

Frontend-Page-Guard: view:FE_EmployeeContractVacation, view:EmployeeContractVacation

API-Datenzugriff: view, create, update, delete auf EmployeeContractVacation

Datenmodell

FeldTypBedeutung
idUUIDPrimary Key
employeeContractIdUUIDFK auf EmployeeContract
nameStringBezeichnung des Kontingents (z. B. „Gesetzlicher Mindesturlaub")
daysNumberAnzahl Tage (Halbtage als .5 erlaubt)
vacationTypeIdUUID nullableFK auf VacationType — Quelle für Verfalls-/Abgeltungs-Regeln
proofDocumentIdUUID nullableNachweis-Dokument (Pflicht z. B. bei category=statutory + Schwerbehinderten-Zusatz)
dynamicTopUpTotalDaysNumber nullableDynamischer Top-Up-Modus: dieses Item gleicht beim Auflösen den Gesamtanspruch des Vertrags auf den angegebenen Wert (Arbeitstage) aus. Sinnvoll bei Mehrurlaub neben altersabhängigen Statutory-Items (JArbSchG)
typeenum DEPRECATEDmandatory | severelyDisabled | voluntary | other — wird in Folge-Migration entfernt; bitte vacationTypeId verwenden

Snapshot-Felder (readonly, gesetzt bei Vertrags-Finalisierung)

FeldQuelle
vacationTypeKeySnapshotVacationType.key zum Snapshot-Zeitpunkt
vacationTypeNameSnapshotVacationType.name
categorySnapshotVacationType.category
expiryRuleSnapshotVacationType.expiryRule
carryoverDeadlineSnapshotVacationType.carryoverDeadline
compensableOnTerminationSnapshotVacationType.compensableOnTermination
compensableOnSicknessSnapshotVacationType.compensableOnSickness
requiresHinweispflichtSnapshotVacationType.requiresHinweispflicht
replacesCategorySnapshotVacationType.replacesCategory

Warum Snapshot? Wenn HR-Leitung später den VacationType anpasst (z. B. Verfallsregel ändern), bleiben bestehende Verträge stabil mit den Konditionen, die zum Vertrags-Zeitpunkt galten. Nur neue Verträge bekommen die neuen Werte. (Klassisches Snapshot-Pattern.)

Dynamic-Top-Up — wofür?

dynamicTopUpTotalDays löst ein typisches Problem bei altersgestaffelten Statutory-Items (JArbSchG):

Beispiel: Ein 17-jähriger Auszubildender hat nach JArbSchG §19 Anspruch auf 25 Tage gesetzlich. Wird im November 18, fällt der erhöhte Statutory-Anspruch auf 20 Tage. Trotzdem hat der Mandant tariflich 30 Tage Gesamt-Urlaub zugesagt.

Mit Dynamic-Top-Up:

  • Statutory-Item: altersgestaffelt 25 → 20 Tage (engine-berechnet)
  • Top-Up-Item mit dynamicTopUpTotalDays = 30: gleicht auf 30 aus → solange Statutory 25 ist, sind es 5 Top-Up-Tage; sobald Statutory auf 20 fällt, sind es 10 Top-Up-Tage

Konsequenz: Der Gesamt-Anspruch bleibt stabil bei 30 Tagen, das System rechnet die Verschiebung dynamisch.

API-Endpoints

MethodeEndpointZweck
GET/api/employee-contract-vacationsListe, typisch gefiltert ?filter[employeeContractId]=...
GET/api/employee-contract-vacations/:idDetail
POST/api/employee-contract-vacationsNeu anlegen
PATCH/api/employee-contract-vacations/:idÄndern (vor Vertrags-Finalisierung)
DELETE/api/employee-contract-vacations/:idLöschen

Verknüpfungen

  • EmployeeContract — Eltern-Datensatz, ein Vertrag hat 1..n Vacation-Items
  • VacationType — Stamm-Quelle der rechtlichen Regeln
  • Absences — beim Anlegen einer Abwesenheit wird auf das passende EmployeeContractVacation-Kontingent abgebucht
  • Snapshot-Pattern — siehe /konzepte/snapshot-pattern

Versionshinweise

  • 2026-05 (Welle 98): Initiale Doku basiert auf Migration 20260430102445-initial-employee-contract-vacation-model.js + Modell employeeContractVacation.model.ts. Eingeführt mit der VacationType-Erweiterung; ersetzt schrittweise das deprecated type-Enum.