§3 ArbZG — Höchstarbeitszeit, Cap, Mehrarbeits-Genehmigung
Das deutsche Arbeitszeitgesetz (ArbZG) regelt unter anderem die maximale Tagesarbeitszeit. SpeamCore unterstützt Mandanten, die diese Pflicht technisch durchsetzen wollen — mit Live-Cap, Genehmigungs-Workflow und PDF-Reporting. Diese Seite erklärt das Konzept.
Die rechtliche Grundlage (Kurzfassung)
§3 ArbZG sagt im Kern:
- Werktägliche Arbeitszeit höchstens 8 Stunden (Standard)
- Verlängerung auf 10 Stunden möglich, wenn:
- innerhalb von 6 Kalendermonaten oder 24 Wochen im Durchschnitt 8 Stunden werktäglich nicht überschritten werden, und
- der Arbeitgeber die Verlängerung genehmigt / dokumentiert
Das ist die Grundlage für das, was in SpeamCore „§3 ArbZG-Cap" heißt: bei aktivem Setting wird ein Tag mit >10h als pflicht-genehmigungs-bedürftig markiert; ohne Genehmigung wird die Mehrarbeit nicht angerechnet.
Mehr Details siehe Konfiguration in Labor-Law DE.
Architektur-Überblick
Komponenten im Detail
1. Tenant-Setting enforceMaxWorkingHours
Pro Mandant per Settings-Modul aktivierbar:
false(Default): keine Cap-Durchsetzung — Zeit-Buchungen werden 1:1 angerechnet, auch bei 12-Stunden-Tagen. Sinnvoll für Mandanten ohne deutsches Recht oder mit eigener Lösung.true: SpeamCore prüft pro Tag, ob die Tageshöchstgrenze überschritten wird, und erzeugt bei Bedarf einenWorkTimeOvertimeApproval-Eintrag.
Das Setting wird in workTimeBalance.service.ts über isEnforceMaxWorkingHoursEnabled() ausgelesen (kein Cache, pro Engine-Lauf abgefragt).
2. Labor-Law-Config
Pro Land sind die Höchstgrenzen in api.speamcore.com/src/config/laborLaw/ konfiguriert:
| Land | maxDailyWorkMinutes (Standard) | maxDailyWorkMinutesExtended (mit Ausgleich) | Referenz |
|---|---|---|---|
| DE | 480 (8h) | 600 (10h) ← Cap | ArbZG §3, §4 |
| AT | siehe AT.ts | siehe AT.ts | Arbeitszeitgesetz AT |
| CH | 540 (9h) | 600 (10h) | ArG Art. 15 |
Die Werte werden in der Compliance-Engine als capMinutes (Default maxDailyWorkMinutesExtended ?? 600) verwendet.
3. WorkTimeOvertimeApproval-Modell
Pro Tag mit Cap-Überschreitung ein Eintrag in der Tabelle:
| Feld | Bedeutung |
|---|---|
employeeId | Mitarbeiter |
date | Tag (DATEONLY) |
workedMinutes | Brutto-Arbeitsminuten an dem Tag (vor Cap) |
maxAllowedMinutes | Gesetzliche Tageshöchstgrenze (i.d.R. 600 = 10h) |
overflowMinutes | workedMinutes - maxAllowedMinutes |
status | pending | approved | rejected |
decidedByEmployeeId | Wer hat entschieden (HR-Leitung) |
decidedAt | Wann entschieden |
decisionReason | Begründung (Pflicht bei Ablehnung) |
sourceCheckId | Verweis auf EmployeeComplianceCheck (maxDailyHoursExceeded) |
Idempotenz: Wenn die Engine erneut läuft (z. B. nach nachträglichen Zeit-Korrekturen), wird der bestehende Eintrag aktualisiert (Minuten-Felder), der Status bleibt erhalten — Audit-Trail.
4. Saldo-Logik (resolveCountableMinutesForDay)
Pro Tag berechnet der workTimeOvertimeApproval.service die anrechenbaren Minuten:
| Approval-Status | anrechenbare Minuten |
|---|---|
| kein Overflow | workedMinutes (volle Anrechnung) |
approved | workedMinutes (volle Anrechnung — Mehrarbeit wird gezählt) |
rejected | maxAllowedMinutes (Cap — Überstunden werden nicht angerechnet) |
pending | maxAllowedMinutes (default-konservativ — sobald Entscheidung fällt, neu berechnet) |
none (Setting nicht aktiv) | workedMinutes (Setting nicht aktiv → keine Cap-Logik) |
Konsequenz für den Mitarbeiter: Solange die Mehrarbeit pending ist, wird sie im Saldo als nicht-angerechnet behandelt. Erst nach Genehmigung kommt sie als eigene Saldo-Position dazu.
Sichtbarkeit im UI
Mitarbeiter (eigene Arbeitszeit)
In der Mitarbeiter-Zeit-Übersicht wird ein Tag mit pending §3 ArbZG-overflow rot markiert (eigene Spalte). Der Mitarbeiter sieht:
- An welchen Tagen die Tageshöchstgrenze überschritten wurde
- Status der Mehrarbeit (pending / approved / rejected)
- Bei rejected: Begründung
- Im Saldo-Popover Cap-Anteile gesondert ausgewiesen
Mehr in Eigene Arbeitszeit-Übersicht.
HR-Leitung (Mehrarbeit genehmigen)
HR-Leitung mit update:WorkTimeOvertimeApproval und do:Approve / do:Reject sieht alle pending Approvals und kann pro Eintrag:
- Approve mit
POST /api/work-time-overtime-approvals/:id/approve - Reject mit
POST /api/work-time-overtime-approvals/:id/reject+decisionReason
Mehr in Mehrarbeit genehmigen (HR-Leitung).
Admin / Compliance-Konfiguration
Admin kann das Tenant-Setting enforceMaxWorkingHours in den Settings-Stammdaten aktivieren / deaktivieren. Auswirkung: ab dem Aktivieren-Zeitpunkt prüft die Engine die Cap-Grenze; bestehende pending Approvals bleiben bestehen.
PDF-Report
Im Time-Overview-Report ist eine eigene §3 ArbZG-Card integriert (Konfig: feat(report): §3 ArbZG-cap in tagesuebersicht abgebildet). Die Card zeigt pro Mitarbeiter + Zeitraum:
- Tage mit Cap-Überschreitung
- Status (pending / approved / rejected) je Tag
- Genehmigte Mehrarbeit als eigene Zeile (eindeutig vom Standard-Saldo getrennt)
- Source of Truth: die Approvals — der Report aggregiert nur, rechnet nicht selbst.
Compliance-Engine-Trigger
Der WorkTimeOvertimeApproval-Eintrag wird nicht in Echtzeit beim Stempeln erzeugt, sondern:
- Live-Hook beim Speichern einer Zeit-Buchung (
workTimeBalance.service-Hook → triggert Engine-Lauf für den betroffenen Tag) - Täglicher Cron (
runDailyComplianceChecksum 02:00) — verarbeitet rückwirkend alle Mitarbeiter - Manueller Trigger durch HR-Leitung über die Compliance-Notification-Sweep-Aktion
So bleibt der Datenstand auch bei nachträglichen Korrekturen konsistent.
Verwandte Doku
- Mehrarbeit genehmigen (HR-Leitung) — operativer Workflow
- Eigene Arbeitszeit-Übersicht — Mitarbeiter-Sicht mit roter Markierung
- WorkTime-Overtime-Approvals — Modul-Doku
- Compliance-Checks — übergeordnete Compliance-Engine
- Multi-Mandanten — Tenant-Setting-Mechanismus