Wofür das Modul gedacht ist
Belegstatus ist Teil des aktiven Modul-Katalogs und deckt einen klaren Ausschnitt des Produktalltags ab.
Dropdown-Optionen und Standards für Belegstatus. Im tenantweiten Kontext sorgt der Bereich dafür, dass wiederkehrende Entscheidungen, Stammdaten oder Übersichten nicht in Nebensysteme ausweichen müssen.
Belegstatus 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.
Tenant sauber aufsetzen
Das Modul hilft dabei, organisatorische Regeln und Stammdaten an einer kontrollierten Stelle zu pflegen.
Verantwortung eingrenzen
Governance-Bereiche sollten nur wenige Personen pflegen, damit die Struktur stabil bleibt.
Rollouts belastbar machen
Eine klare Administrationsstruktur vereinfacht Onboarding, Rechtestruktur und spätere Produkterweiterungen.
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.
Dokumente
Dokumente ergänzt Belegstatus, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsProjekt-Zahlungen
Projekt-Zahlungen ergänzt Belegstatus, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsAusgaben
Ausgaben ergänzt Belegstatus, 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
Schmales Konfigurations-Modul mit einer einzigen Action (manage_document_status). RLS-only auf document_status_options INSERT/UPDATE/DELETE. KEIN API-Endpoint — Mutationen laufen direkt via PostgREST aus dem UI. scope=global, tenant-weite Konfiguration.
Entwickler-Info aufklappen (1)
Pure RLS-Verdrahtung — kein API-Pre-Check
Drei RLS-Policies (insert/update/delete) gates manage_document_status direkt. User ohne Permission sehen PostgREST-42501-Antworten beim Speichern, nicht klare 403-Strings. Bei UI-Tests entsprechend prüfen.
supabase/migrations/20251210234001_squash_baseline.sql:23796-23816