struct-i-vio
StartseiteDokumentationModuleBudget
Finanzen & Controlling · Projektmodul

Budget: wofür der Bereich im Projektkontext gedacht ist.

Projekt-Budgetverwaltung und Budgetanträge. Das Modul erscheint innerhalb eines einzelnen Projekts und wirkt damit unmittelbar im Projektkontext.

  • Budget erklärt kompakt, wofür der Bereich gedacht ist und wann er im Arbeitsalltag relevant wird.
  • Der Bereich spielt in der Praxis besonders mit Unternehmenstopf und Umbuchungen zusammen.
  • Bei finanznahen Modulen sollten Sichtbarkeit und Freigaben bewusster gesetzt werden als bei reinen Lesebereichen.
Zur ModulübersichtRollen & Berechtigungen lesen
Direkt zu
Modulzweck

Wofür das Modul gedacht ist

Budget ist Teil des aktiven Modul-Katalogs und deckt einen klaren Ausschnitt des Produktalltags ab.

Projekt-Budgetverwaltung und Budgetanträge. Im Projektkontext bedeutet das, dass der Bereich nicht isoliert funktioniert, sondern direkt an Team, Status und weitere Projektbereiche anknüpft.

Budget ist als eigenständiger Produktbaustein gedacht. Gerade deshalb lohnt sich ein Blick darauf, wie der Bereich mit Rollen, Datenkontext und angrenzenden Modulen zusammenspielt.

Das Modul erscheint innerhalb eines einzelnen Projekts und wirkt damit unmittelbar im Projektkontext.
Praxisbezug

Typische Einsatzfälle

Diese Situationen zeigen, wann der Bereich in einem sauberen Rollout oder im laufenden Betrieb konkret Mehrwert liefert.

Finanzstatus im Blick halten

Budget 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.

Modulverbindungen

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.

Global

Unternehmenstopf

Unternehmenstopf ergänzt Budget, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.

Details
Projektmodul

Umbuchungen

Umbuchungen ergänzt Budget, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.

Details
Container

Cash-Flow

Cash-Flow ergänzt Budget, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.

Details
Sichtbarkeit

Berechtigungen und Sichtbarkeit

Die öffentliche Dokumentation beschreibt die Logik auf Produktniveau - nicht als technische Policy-Liste, sondern als Rollout-Leitfaden.

Die Sichtbarkeit orientiert sich in der Regel am Projektkontext, an Projektmitgliedschaft und an projektbezogenen Zusatzrollen.
Finanznahe, freigaberelevante oder buchungsnahe Aktionen sollten nur Rollen mit Management-, Finanz- oder klar delegierter Projektverantwortung erhalten.
Empfohlener Einsatz

Best Practices

So bleibt der Bereich bei Einführung und Nutzung anschlussfähig an den restlichen Produktfluss.

Budget-, Zahlungs- und Rechnungsprozesse nicht isoliert denken, sondern mit Projektkontext, Zuständigkeiten und Freigaben zusammen aufsetzen.
Nur die Rollen erweitern, die wirtschaftliche Entscheidungen tatsächlich treffen oder vorbereiten müssen.
Abweichungen regelmäßig mit GuV-, Cash-Flow- oder Budgetsicht abgleichen, statt erst im Monatsabschluss zu reagieren.
Tiefer einsteigen

Entwickler Info

Schmales 5-Action-Modul: 1 view-Pair (_all/scoped) + 3 self-service-Permissions auf budget_transfer_requests (request_funding, edit_own_request, cancel_own_request). Approve-Pfad lebt im company_fund-Modul (Cross-Modul-Workflow analog zu absences_requests).

Entwickler-Info aufklappen (4)

⚠ KRITISCHview_budget gates dim_projects.actual_budget

Die dim_projects-View blendet das actual_budget-Feld aus, wenn der User weder view_budget noch view_budget_all hat (squash:19226). Das wirkt sich auf alle Listen-Endpoints aus, die actual_budget mitselektieren — der Wert kommt als NULL durch, ohne dass ein expliziter Permission-Check im API-Layer steht. Plus: project_budget_transactions_select hat OR-Klausel (view_budget_all OR view_budget).

  • supabase/migrations/20251210234001_squash_baseline.sql:19226 (View-Filter)
  • supabase/migrations/20251210234001_squash_baseline.sql:24952 (RLS auf project_budget_transactions)
  • supabase/migrations/20251210234001_squash_baseline.sql:7178 (get_project_budget_safe RPC)

Self-Service-Antrags-Workflow (analog zu absences_requests)

request_funding/edit_own_request/cancel_own_request bilden einen Self-Service-Workflow auf budget_transfer_requests. RLS prüft jeweils requested_by = current_employee + Permission, edit/cancel zusätzlich status = pending. Genehmigte oder abgelehnte Anträge sind unveränderlich. Die Genehmigung erfolgt im company_fund-Modul via approve_request — Cross-Modul-Workflow.

  • supabase/migrations/20251210234001_squash_baseline.sql:23437-23473
  • pages/api/budget/transfer-requests.ts

edit/cancel_own_request: PL-Bypass deaktiviert

allow_project_lead ist sowohl für edit_own_request als auch cancel_own_request auf false gesetzt. Selbst Projektleiter bekommen diese Permissions NICHT automatisch — das ist ungewöhnlich für ein Project-Modul (sonst sind PL-Bypässe weit verbreitet). Bewusste Design-Entscheidung: Eigene Anträge bearbeiten/zurückziehen ist eine reine Self-Service-Funktion, keine Lead-Funktion.

Reine RLS-Verdrahtung — keine API-Pre-Checks

/api/budget/transfer-requests POST/PATCH hat keinen can_perform_action-Check für request_funding/edit/cancel. Die Endpoints vertrauen RLS vollständig. User ohne Permission sehen PostgREST-42501-Antworten beim INSERT/UPDATE/DELETE.

Vorherige Seite

Module

Der öffentliche Modulkatalog von struct-i-vio mit einer eigenen Docs-Seite für jeden aktiven Produktbaustein.

Jetzt loslegen

struct-i-vio im eigenen Setup testen

Wenn Sie den Einstieg konkret planen, können Sie direkt einen eigenen Arbeitsbereich anlegen.