Wofür das Modul gedacht ist
Unternehmenstopf ist Teil des aktiven Modul-Katalogs und deckt einen klaren Ausschnitt des Produktalltags ab.
Margenübersicht, Umbuchungen und zentrale Finanzverantwortung. Im tenantweiten Kontext sorgt der Bereich dafür, dass wiederkehrende Entscheidungen, Stammdaten oder Übersichten nicht in Nebensysteme ausweichen müssen.
Unternehmenstopf 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.
Finanzstatus im Blick halten
Unternehmenstopf 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.
Budget
Budget ergänzt Unternehmenstopf, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsUmbuchungen
Umbuchungen ergänzt Unternehmenstopf, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsTransaktionen
Transaktionen ergänzt Unternehmenstopf, 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-Probes inklusive 4-Schichten-Enforcement-Scan (Code + RPC-Bodies + RLS-Policies + Views). Diese Hinweise sind für Admins gedacht, die Berechtigungen feinjustieren, und für Entwickler, die das Modul erweitern.
Entwickler-Info aufklappen (6)
⚡ MERKWÜRDIGview_fund ist RLS-only enforced — kein API-Gate, redundante 2nd-Line-Defense
Die Action wird weder im API-Code noch in irgendeiner SECURITY-DEFINER-Funktion geprüft. Sie ist ausschliesslich auf RLS-SELECT-Policies der Tabellen company_funds und company_fund_transactions verdrahtet. Das eigentliche Sichtbarkeits-Tor zum Topf liegt jedoch eine Ebene davor im API-Handler: /api/budget/overview?type=company prüft hartcodiert project_overview.view_financials_all und antwortet bei Verweigerung mit HTTP 403 — die RLS wird in dem Fall nie angefasst. view_fund wirkt damit nur in dem Edge-Case, dass jemand view_financials_all hat aber view_fund nicht: dann liefert die API HTTP 200 mit leeren Daten. Toggle wirkt also nur scheinbar unabhängig.
pages/api/budget/overview.ts:217-223 (API-Gate)RLS: public.company_funds_select, public.company_fund_transactions_selectscripts/probe-view-fund-permission.js
⚡ MERKWÜRDIGview_all_requests ist RLS-only enforced — alleinige Verteidigungslinie
Auch diese Action wird weder im API noch in einem RPC geprüft. Sie sitzt allein auf der RLS-SELECT-Policy von budget_transfer_requests. Folge: GET /api/budget/transfer-requests antwortet immer mit HTTP 200, aber wer die Permission nicht hat sieht eine leere Liste — kein 403. Im Gegensatz zu view_fund gibt es hier keinen redundanten API-Gate; view_all_requests ist die einzige Verteidigung.
RLS: public.budget_transfer_requests :: budget_transfer_requests_select_allpages/api/budget/transfer-requests.ts (kein can_perform_action für view_all_requests)scripts/probes/probe-company-fund-module.js
⚠ KRITISCHUnternehmenstopf-Sicht ist an "alle Projekt-Finanzen" gekoppelt
Wer den Unternehmenstopf einsehen soll, braucht zwingend project_overview.view_financials_all. Der Endpoint /api/budget/overview?type=company prüft hartcodiert diese Action. Es gibt aktuell keine Möglichkeit, Topf-Sicht ohne globalen Projekt-Finanz-Einblick zu vergeben — eine versteckte UND-Verknüpfung zwischen den beiden Modulen.
pages/api/budget/overview.ts:217-223lib/permission-dependencies.ts (cross_module-Regel)
approve_request setzt manage_fund voraus
Ein Genehmiger ohne manage_fund kann zwar im UI auf "Genehmigen" klicken, die Folgebuchung schlägt jedoch fehl. Beide Permissions müssen gemeinsam vergeben werden.
lib/permission-dependencies.ts (MANUAL_PERMISSION_DEPENDENCIES)
link_transaction / unlink_transaction / transfer_to_project: RPC-enforced, keine Couplings
Diese drei Actions werden in SECURITY-DEFINER-RPCs geprüft (link_transaction_to_company_fund, unlink_transaction_from_company_fund, transfer_from_company_to_project). Bei Verweigerung antworten sie mit success:false und HTTP 400 statt 403. Stage-2-Probe bestätigt: keine versteckten Couplings — Position-Level reicht eigenständig.
scripts/probes/probe-company-fund-module.js
manage_fund: API-enforced, keine Couplings
pages/api/budget/return-to-company.ts:32 prüft can_perform_action explizit am Handler-Eingang und antwortet bei Verweigerung mit HTTP 403. Standalone — keine zusätzlichen Berechtigungen erforderlich.
pages/api/budget/return-to-company.ts:32