Wofür das Modul gedacht ist
Soll-Stunden ist Teil des aktiven Modul-Katalogs und deckt einen klaren Ausschnitt des Produktalltags ab.
Soll-Stunden, Zielwerte und Monatsregeln verwalten. Im tenantweiten Kontext sorgt der Bereich dafür, dass wiederkehrende Entscheidungen, Stammdaten oder Übersichten nicht in Nebensysteme ausweichen müssen.
Soll-Stunden ist als eigenständiger Produktbaustein gedacht. Gerade deshalb lohnt sich ein Blick darauf, wie der Bereich mit Rollen, Datenkontext und angrenzenden Modulen zusammenspielt.
Typische Einsatzfälle
Diese Situationen zeigen, wann der Bereich in einem sauberen Rollout oder im laufenden Betrieb konkret Mehrwert liefert.
Self-Service entlasten
Mitarbeitende können wiederkehrende Personalthemen direkt im passenden Ablauf bearbeiten.
Genehmigungspfade klären
Anträge, Korrekturen und Zielwerte bleiben transparent, sobald die zuständigen Rollen sauber gesetzt sind.
Kapazität planbar machen
Das Modul ist besonders wertvoll, wenn Abwesenheit, Soll-Werte und Stunden gemeinsam gedacht werden.
Wie das Modul mit anderen Bereichen zusammenspielt
struct-i-vio ist als zusammenhängende Plattform gedacht. Diese Module liegen fachlich am nächsten bei diesem Bereich.
Abwesenheit
Abwesenheit ergänzt Soll-Stunden, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsStunden
Stunden ergänzt Soll-Stunden, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsMitarbeiterverwaltung
Mitarbeiterverwaltung ergänzt Soll-Stunden, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsBerechtigungen und Sichtbarkeit
Die öffentliche Dokumentation beschreibt die Logik auf Produktniveau - nicht als technische Policy-Liste, sondern als Rollout-Leitfaden.
Best Practices
So bleibt der Bereich bei Einführung und Nutzung anschlussfähig an den restlichen Produktfluss.
Entwickler Info
Symmetrisches Lock/Unlock-Paar für Abwesenheits-Monatsabschluss. Beide Permissions teilen sich denselben API-Endpoint und denselben SECURITY-DEFINER-RPC, der je nach action-Parameter (lock/unlock) eine der beiden Permissions prüft.
Entwickler-Info aufklappen (2)
Saubere Lock/Unlock-Symmetrie
pages/api/employee-soll/month-lock.ts:72 (lock) und :77 (unlock) prüfen die jeweilige Permission via can_perform_action. Die RPC set_absence_month_lock führt die Mutation in absence_month_locks aus. RLS ist symmetrisch verdrahtet (drei Policies pro Action: insert_lock_tenant / update_lock_tenant / delete_tenant für close, plus die unlock-Varianten).
pages/api/employee-soll/month-lock.ts:72-77RPC: set_absence_month_lockRLS: 6 Policies auf absence_month_locks
reopen ist strenger als close
Konvention: close darf jeder HR-Berechtigte, reopen nur HR-Lead. Grund: nachträgliche Änderungen in einem abgeschlossenen Monat können Auswirkungen auf bereits ausgezahlte Löhne haben.