struct-i-vio
StartseiteDokumentationModuleProjekt-Zahlungen
Finanzen & Controlling · Projekt-Teilbereich

Projekt-Zahlungen: wofür der Bereich im Projektkontext gedacht ist.

Zahlungseingänge und -ausgänge auf Projektebene verwalten. Das Modul erscheint innerhalb eines einzelnen Projekts und wirkt damit unmittelbar im Projektkontext.

  • Projekt-Zahlungen erklärt kompakt, wofür der Bereich gedacht ist und wann er im Arbeitsalltag relevant wird.
  • Der Bereich spielt in der Praxis besonders mit Cash-Flow und Transaktionen 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

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

Zahlungseingänge und -ausgänge auf Projektebene verwalten. Im Projektkontext bedeutet das, dass der Bereich nicht isoliert funktioniert, sondern direkt an Team, Status und weitere Projektbereiche anknüpft.

Projekt-Zahlungen hängt fachlich an Cash-Flow. Dadurch ist für Nutzer sofort klar, in welchem größeren Ablauf das Modul seinen Platz hat.

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

Projekt-Zahlungen 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.

Container

Cash-Flow

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

Details
Global

Transaktionen

Transaktionen ergänzt Projekt-Zahlungen, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.

Details
Projekt-Teilbereich

Rechnungen

Rechnungen ergänzt Projekt-Zahlungen, 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.
Projekt-Zahlungen ist fachlich an Cash-Flow angebunden. Die Gruppe kann sichtbar sein, obwohl einzelne Detailrechte enger gesetzt bleiben.
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

Empirisch erhobene Befunde aus Stage-2-Isolations-Probe inkl. 4-Schichten-Enforcement-Scan. Auffälliges Modul: 4 von 8 Permissions sind effektiv nicht via App erreichbar (vestigial / unbound). Sehr typisch _all/scoped-Paar-Muster mit OR-Verknüpfung in den RLS-Policies.

Entwickler-Info aufklappen (4)

⚠ KRITISCHHälfte des Moduls ist Schema-Intent ohne App-Wiring

unallocate, unallocate_all, delete und delete_all wirken in normalen App-Flows nicht. unallocate / unallocate_all liegen nur auf einer RLS-DELETE-Policy auf project_payment_allocations — die App nutzt aber UPDATE-status="cancelled" via cancel_project_payment_allocation und unallocate_project_payment, beide RPCs prüfen allocate (NICHT unallocate). delete prüft eine RPC, die in keiner TS-Datei aufgerufen wird. delete_all hat überhaupt keine Verdrahtung.

  • RPC: cancel_project_payment_allocation (prüft allocate)
  • RPC: unallocate_project_payment (prüft allocate)
  • RPC: unassign_transaction_from_project (prüft delete — aber nirgends aufgerufen)
  • scripts/probes/probe-project-payments-module.js

⚠ KRITISCHBackdoor zu fact_transactions für Projekt-Mitglieder

project_payments.view (project-scoped) öffnet die SELECT-Policy fact_transactions_project_member_select. Wer view für ein Projekt hat, sieht damit auch die Bank-Transaktionen mit project_id = X — selbst ohne guv_transactions.view_transactions. Klassischer cross-module-backdoor.

  • RLS: public.fact_transactions :: fact_transactions_project_member_select

Saubere _all/scoped Verdrahtung bei view + allocate

view / view_all und allocate / allocate_all folgen 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.

  • RLS: project_payments_select, project_payment_allocations_select
  • RLS: project_payment_allocations_insert/_update

⚡ MERKWÜRDIGNaming-Mismatch: cancel-allocation prüft allocate, nicht unallocate

pages/api/project-payments/cancel-allocation.ts und unallocate.ts rufen RPCs auf, die intern allocate prüfen. Das ist konsistent (wer Zuweisungen erstellt, darf sie auch zurücknehmen), aber das Vorhandensein einer eigenen unallocate-Permission erweckt den Eindruck von feiner-granularer Steuerung — die nicht existiert.

  • pages/api/project-payments/cancel-allocation.ts:36
  • pages/api/project-payments/unallocate.ts
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.