Wofür das Modul gedacht ist
Umbuchungen ist Teil des aktiven Modul-Katalogs und deckt einen klaren Ausschnitt des Produktalltags ab.
Budget-Umbuchungen zwischen Projekten nachvollziehbar steuern. Im Projektkontext bedeutet das, dass der Bereich nicht isoliert funktioniert, sondern direkt an Team, Status und weitere Projektbereiche anknüpft.
Umbuchungen 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
Umbuchungen 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 Umbuchungen, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsUnternehmenstopf
Unternehmenstopf ergänzt Umbuchungen, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsCash-Flow
Cash-Flow ergänzt Umbuchungen, 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. Sehr saubere Verdrahtung — eines der wenigen Module ohne versteckte Couplings oder vestigiale Permissions. Klassisches _all/scoped-Paar-Muster.
Entwickler-Info aufklappen (3)
Saubere _all/scoped Verdrahtung — keine Cross-Module-Couplings
Beide Permission-Paare (create_transfer/_all und view_project_transfers/view_transfers_all) folgen exakt dem etablierten Pattern: das _all-Suffix gewährt globalen Bypass, die scoped-Variante prüft pp.project_id. Beide werden in den RLS-Policies via OR kombiniert — Admin braucht nur eines der beiden zu vergeben. Die RPC transfer_between_projects spiegelt dieselbe OR-Logik.
RLS: public.budget_transfers :: budget_transfers_insert + _selectRPC: transfer_between_projects
view_project_transfers gates Source ODER Ziel
Ein Projekt-zu-Projekt-Transfer ist sichtbar, sobald der User Mitglied IM QUELL- ODER IM ZIELPROJEKT ist. Das ist absichtlich — beide Seiten brauchen Audit-Sicht über eingehende und ausgehende Mittel. Konsequenz: die Permission gewährt eine breitere Sicht als nur "Mein Projekt".
RLS-Klausel: source_project_id OR target_project_id
budget_transfers ist append-only
UPDATE und DELETE sind durch RLS-Policies mit USING:false komplett gesperrt. Einmal angelegte Transfers können nicht editiert oder gelöscht werden — Korrektur erfolgt durch einen Gegenbuchungs-Transfer.
RLS: budget_transfers_update_never (USING: false)RLS: budget_transfers_delete_never (USING: false)