Wofür das Modul gedacht ist
Ausgaben ist Teil des aktiven Modul-Katalogs und deckt einen klaren Ausschnitt des Produktalltags ab.
Projektausgaben im Cash-Flow-Kontext. Im Projektkontext bedeutet das, dass der Bereich nicht isoliert funktioniert, sondern direkt an Team, Status und weitere Projektbereiche anknüpft.
Ausgaben hängt fachlich an Cash-Flow. Dadurch ist für Nutzer sofort klar, in welchem größeren Ablauf das Modul seinen Platz hat.
Typische Einsatzfälle
Diese Situationen zeigen, wann der Bereich in einem sauberen Rollout oder im laufenden Betrieb konkret Mehrwert liefert.
Finanzstatus im Blick halten
Ausgaben macht wirtschaftliche Signale dort sichtbar, wo Entscheidungen vorbereitet werden.
Freigaben sauber führen
Gerade bei Zahlungen, Budgets oder Rechnungen sorgt das Modul für nachvollziehbare Schritte statt lose Absprachen.
Mit dem Projektkontext arbeiten
Finanzmodule entfalten ihren Wert, wenn Projektstatus, Belege, Zahlungen und Verantwortlichkeiten zusammenspielen.
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.
Cash-Flow
Cash-Flow ergänzt Ausgaben, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsBudget
Budget ergänzt Ausgaben, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsProjekt-Zahlungen
Projekt-Zahlungen ergänzt Ausgaben, 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
Saubere _all/scoped-Verdrahtung mit interessantem asymmetrischem Pattern: NUR die _all-Varianten haben API-Pre-Checks, die scoped-Varianten sind RLS-only. Effizient (ein RPC-Aufruf statt zwei), aber Verweigerung des scoped-Pfads liefert leere Listen statt 403.
Entwickler-Info aufklappen (3)
Asymmetrisches Pattern: API-Pre-Check nur für _all-Varianten
pages/api/expenses/* prüfen via can_perform_action nur die _all-Action-Keys. Für die scoped-Varianten verlässt sich der API auf RLS — die _project- und _all-Policies sind via OR im RLS-Layer kombiniert. Wer die _all-Permission hat, geht durch den API-Gate UND den RLS-OR-Pfad. Wer nur die scoped-Permission hat, scheitert am API-Gate (403 falls explizit geprüft) oder kommt durch RLS (für GET-Pfade ohne API-Pre-Check).
pages/api/expenses/index.ts:235pages/api/expenses/create.ts:214pages/api/expenses/update.ts:35pages/api/expenses/[id].ts:38, 46
edit_project_expenses gates Anhänge — nicht die Auslage selbst
Das scoped edit-Permission liegt auf expense_attachments INSERT/UPDATE/SELECT — nicht auf expenses UPDATE direkt. Hauptzweck: Beleg-Verwaltung. Die Auslage selbst wird via expenses_update_project oder _all aktualisiert (das bei den entsprechenden API-Pfaden direkt geprüft wird).
Auto-generierte view-before-edit / edit-before-delete Regeln
Die Stage-1-Engine generiert für project_expenses automatisch view-before-edit und edit-before-delete-Regeln je _all und scoped (siehe lib/permission-dependencies.ts expandGenericDependencies-Mechanismus).