Wofür das Modul gedacht ist
Finanzen ist Teil des aktiven Modul-Katalogs und deckt einen klaren Ausschnitt des Produktalltags ab.
GuV-Übersicht, Finanzplanung, USt-Auswertung und Managementsicht auf den tenantweiten Bestand. Im tenantweiten Kontext sorgt der Bereich dafür, dass wiederkehrende Entscheidungen, Stammdaten oder Übersichten nicht in Nebensysteme ausweichen müssen.
Finanzen 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.
Finanzentwicklung verdichten
Die GuV führt Managementsicht, Forecast und zentrale Finanzkennzahlen in einer gemeinsamen Oberfläche zusammen.
Umsatzsteuer pro Zeitraum verfolgen
Die integrierte USt-Auswertung zeigt vereinnahmte Umsatzsteuer, bezahlte Vorsteuer und den Saldo nach Woche, Monat, Quartal oder Jahr inklusive kumulierter Zahllast für die interne Einordnung.
Mit Buchungen sauber abgleichen
Steuerwerte lassen sich mit Steuersatz-Aufschlüsselung und einem Filter für nur gemappte Buchungen fachlich kontrollieren, bevor Rückfragen oder Meldungen anstehen.
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.
Transaktionen
Transaktionen ergänzt Finanzen, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsFinmap Einstellungen
Finmap Einstellungen ergänzt Finanzen, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsBanking-Integrationen
Banking-Integrationen ergänzt Finanzen, 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
Empirisch erhobene Befunde aus Stage-2-Isolations-Probe inkl. 4-Schichten-Enforcement-Scan. Alle vier Actions sind RLS-only enforced — die API-Endpoints (forecast.ts, positions.ts, dashboard.ts, tax-analysis.ts) gaten ausschließlich auf Modul-Visibility (hasModulePermission). Aktionsspezifische Differenzierung lebt vollständig in der Datenbank.
Entwickler-Info aufklappen (5)
⚡ MERKWÜRDIGAlle 4 Actions sind RLS-only — kein API-Pre-Check pro Action
Der API-Layer prüft nur "kann der User das guv-Modul sehen?" (hasModulePermission). Verweigerung dieser Modul-Visibility liefert HTTP 403. Aber wer das Modul sieht, kommt durch zur DB — und nur dort entscheidet die jeweilige Action-Permission via RLS. Eine Verweigerung auf Action-Ebene führt nicht zu 403, sondern zu RLS-Violation (HTTP 500) bei Mutationen oder leeren Listen bei SELECT.
pages/api/guv-transactions/forecast.ts:22 (Modul-Visibility-Gate)pages/api/guv-transactions/positions.ts:25 (Modul-Visibility-Gate)
view_forecast: RLS auf fact_budget_forecast SELECT — kein Backdoor
Einzige SELECT-Policy verweist exakt auf view_forecast. Keine alternativen OR-Klauseln, kein Cross-Module-Bypass. Saubere 1:1-Verdrahtung.
RLS: public.fact_budget_forecast :: fact_budget_forecast_select
⚡ MERKWÜRDIGimport_forecast ist ein abgeschwächtes edit_forecast (zwei INSERT-Policies, OR-Logik)
Auf fact_budget_forecast existieren ZWEI INSERT-Policies — fact_budget_forecast_insert (mit edit_forecast) und fact_budget_forecast_insert_import (mit import_forecast). PostgreSQL evaluiert sie mit OR: jede der beiden Permissions ALLEIN reicht für ein INSERT. import_forecast deckt aber nur INSERT ab, nicht UPDATE/DELETE — die liegen ausschließlich auf edit_forecast. Praktisch heisst das: wer import_forecast hat, kann Forecast-Zeilen anlegen, aber nicht ändern oder löschen. Der gleiche POST-Endpoint /api/guv-transactions/forecast bedient beide Permissions — kein gesonderter Import-Endpoint. Wer import_forecast als "nur Bulk-Import"-Permission ansieht, irrt: das Frontend kann einzelne Zeilen genauso anlegen, solange das WITH_CHECK eine der beiden Policies passt.
RLS: fact_budget_forecast_insert (edit_forecast)RLS: fact_budget_forecast_insert_import (import_forecast)pages/api/guv-transactions/forecast.ts (POST handler bedient beide)
⚡ MERKWÜRDIGmanage_positions deckt INSERT/UPDATE/DELETE auf dim_guv_positions
Lesen der Positionen erfordert dagegen NUR die Modul-Visibility (can_view_module_ui). Es gibt keine separate view_positions-Permission. Wer also das guv-Modul sehen kann, sieht alle Positionen — Verfeinern auf "darf nur ausgewählte sehen" ist mit dem aktuellen Schema nicht möglich.
RLS: public.dim_guv_positions :: guv_positions_select (uses can_view_module_ui)RLS: guv_positions_insert / _update / _delete (manage_positions)
edit_forecast: drei RLS-Policies (INSERT/UPDATE/DELETE) — keine Cross-Module-Coupling
Die Policies stehen rein auf fact_budget_forecast, kein Verweis auf andere Module/Tables. Standalone-Permission. Mutations am Endpoint enden bei RLS-Violation in einem 500 mit der generischen Message "Fehler beim Speichern der Prognosen" — kein 403-Signal.
pages/api/guv-transactions/forecast.ts:96 (upsertForecasts)