Zum Hauptinhalt springen

Mehrarbeit nach §3 ArbZG genehmigen

In Deutschland erlaubt §3 ArbZG eine Verlängerung der Tagesarbeitszeit auf bis zu 10 Stunden, wenn der Arbeitgeber die Mehrarbeit genehmigt. SpeamCore bildet diese Genehmigung als eigenen Workflow ab. Diese Anleitung zeigt Ihnen als HR-Leitung, wie Sie pending Approvals abarbeiten.

Wann mache ich das?​

  • Wöchentlich als Routine — vorzugsweise nach den Stempel-Korrekturen der Mitarbeiter (Freitag/Montag).
  • Bei Notification — wenn die Compliance-Engine pending Approvals erzeugt, gibt es einen Notification-Popup (siehe Compliance-Notification-System).
  • Vor Lohn-Vorbereitung — alle pending Approvals müssen entschieden sein, bevor Stunden für die Lohnabrechnung exportiert werden.

So genehmigen oder lehnen Sie Mehrarbeit ab​

Liste der pending Approvals öffnen

In der Sidebar Mehrarbeit-Genehmigungen (Aufrufpfad /work-time-overtime-approvals). Sie sehen die Liste aller Tage mit Cap-Überschreitung mit Spalten:

  • Mitarbeiter — wer hat die Stunden gestempelt
  • Datum — der betroffene Tag
  • Geleistet — workedMinutes (Brutto-Arbeitszeit, z. B. 11h 30min)
  • Cap — maxAllowedMinutes (i.d.R. 10h = 600 min)
  • Overflow — wie viel über dem Cap (z. B. 1h 30min)
  • Status — pending / approved / rejected
  • Source-Check — Verweis auf EmployeeComplianceCheck-ID (für Audit)

Filter setzen auf Status = pending für die offenen Fälle.

Vor der Entscheidung — Kontext prüfen

Bevor Sie genehmigen oder ablehnen, prüfen Sie kurz den Kontext:

  1. Aufträge an dem Tag — über den Mitarbeiter-Detail-Tab Zeiterfassung schauen, welche Workorders gestempelt wurden. War es ein Notfall-Einsatz?
  2. Frühere Genehmigungen — Filter auf den Mitarbeiter setzen, sehen wie oft schon Mehrarbeit anfiel. Häufungen sind Warnsignal.
  3. 6-Monats-Durchschnitt — §3 ArbZG verlangt, dass im 6-Monats-Durchschnitt 8h/Tag nicht überschritten werden. Bei häufigen Approvals: prüfen ob die Wochenstunden grundsätzlich zu hoch sind.

Genehmigen (`approved`)

Wenn die Mehrarbeit gerechtfertigt ist (Notfall, Großauftrag, Anlagen-Inbetriebnahme bei Kunde):

  1. Eintrag in der Liste anklicken — Detail-Sicht.
  2. Button Genehmigen klicken.
  3. Optional: Begründung eintragen — empfohlen für die Akte (z. B. „Notfall-Einsatz BMA-Inbetriebnahme Müller GmbH, kein anderer Techniker verfügbar").
  4. Bestätigen.

Was passiert technisch:

  • Status wechselt auf approved
  • decidedByEmployeeId wird auf Ihre Employee-ID gesetzt
  • decidedAt bekommt aktuellen Timestamp
  • decisionReason speichert Ihre Begründung
  • Im Saldo des Mitarbeiters wird die volle workedMinutes angerechnet — die Mehrarbeit erscheint als eigene Saldo-Position „Genehmigte Mehrarbeit" (nicht im Standard-Saldo verwischt)

API-Endpoint: POST /api/work-time-overtime-approvals/:id/approve

Ablehnen (`rejected`)

Wenn die Mehrarbeit nicht gerechtfertigt war (z. B. Mitarbeiter hat zu lange im Büro gesessen ohne Auftrags-Notwendigkeit, oder die Tageshöchstgrenze entstand durch falsches Stempeln):

  1. Eintrag anklicken — Detail-Sicht.
  2. Button Ablehnen klicken.
  3. Begründung ist Pflicht — z. B. „Stempel-Fehler: Mitarbeiter hat vergessen Mittagspause auszustempeln, korrigiert" oder „Keine betriebliche Notwendigkeit, keine genehmigte Verlängerung".
  4. Bestätigen.

Was passiert technisch:

  • Status wechselt auf rejected
  • Saldo wird nur bis maxAllowedMinutes (10h Cap) angerechnet — die Mehrarbeit fällt aus dem Saldo
  • Mitarbeiter sieht in seiner Wochen-Übersicht den abgelehnten Status mit Ihrer Begründung

API-Endpoint: POST /api/work-time-overtime-approvals/:id/reject

Nach der Entscheidung — was passiert?

Nach Genehmigung / Ablehnung:

  • Mitarbeiter sieht den neuen Status in der eigenen Wochen-Übersicht (siehe Eigene Arbeitszeit-Übersicht)
  • Saldo-Popover in der Home-Ansicht zeigt die §3-ArbZG-Cap-Anteile separat
  • PDF-Time-Overview-Report enthält pro Tag den genehmigten/abgelehnten Status (eigene Card)
  • Audit-Trail über die Record-Revision des WorkTimeOvertimeApproval-Eintrags — wer hat wann was entschieden, mit Begründung

Idempotenz — was wenn die Zeiten nachträglich geändert werden?​

Wenn ein Mitarbeiter seine Stempel-Zeiten nach der Genehmigung noch einmal ändert (z. B. weil eine Pause nachgetragen wird), läuft die Engine erneut:

  • Falls die Cap-Überschreitung nicht mehr besteht: der Approval-Eintrag bleibt erhalten (Audit), wird aber nicht mehr ins Saldo eingerechnet.
  • Falls die Cap-Überschreitung kleiner geworden ist: der bestehende Eintrag wird upgesertet — neue workedMinutes/overflowMinutes, Status bleibt erhalten.
  • Falls die Cap-Überschreitung größer geworden ist: gleicher Eintrag wird aktualisiert mit neuen Minuten-Werten, Status bleibt erhalten.

Konsequenz: Eine bereits genehmigte Mehrarbeit wird nicht nachträglich entzogen — auch wenn die Stunden später korrigiert werden. Das schützt den Mitarbeiter vor unbemerkter Saldo-Korrektur.

Backfill — Mehrarbeit für historische Tage nachtragen​

Wenn ein Tag in der Vergangenheit nachträglich einen §3-Überlauf bekommt — z. B. weil Stempel-Zeiten korrigiert oder nachgepflegt wurden, bevor die Compliance-Engine den Tag erneut auswerten kann — kann der zugehörige WorkTimeOvertimeApproval-Eintrag manuell über die Backfill-API erzeugt werden:

POST /api/work-time-overtime-approvals/backfill
{
  "employeeId": "<uuid>",          // Pflicht
  "date": "2026-04-15",            // Pflicht (YYYY-MM-DD)
  "decision": "approved",          // optional — direkt entscheiden
  "reason": "Notfall-Einsatz BMA"   // Pflicht bei decision = rejected
}

Verhalten des Endpoints:

  • Der Service berechnet die Tagesarbeitszeit für {employeeId, date} aus den vorhandenen Zeit-Trackings.
  • Ist die reine Arbeitszeit ≤ Cap (i. d. R. 10 h), gibt es keinen Überlauf — der Aufruf schlägt mit entsprechender Meldung fehl. Kein leerer Approval-Record wird angelegt.
  • Andernfalls wird der WorkTimeOvertimeApproval-Eintrag angelegt oder aktualisiert.
  • Mit decision setzt der Service status, decidedByEmployeeId und decidedAt sofort.
  • Ohne decision läuft der Record im Status pending und kommt in den normalen Workflow.

Im UI ist der Backfill derzeit nicht direkt erreichbar. Falls Sie historische Tage nachpflegen müssen, geben Sie Mitarbeiter-ID und Datum an Admin/IT weiter — der Aufruf läuft dann per API-Tool oder Postman.

Wann brauche ich Backfill?

  • Korrekturen lange nach dem Stichtag, an denen die Engine den Tag bereits abgehakt hatte.
  • Aufträge, die zur Cap-Überschreitung führten, wurden erst spät einem Mitarbeiter zugewiesen (Tour-Umverteilung).
  • Audit-Anforderung — fehlende Approval-Records aus Compliance-Sicht nachholen.

Stolpersteine​

Verwandte Tutorials​