Wofür das Modul gedacht ist
Planung ist Teil des aktiven Modul-Katalogs und deckt einen klaren Ausschnitt des Produktalltags ab.
Monatliche Projektplanung für Einflüsse, Abflüsse, MA-Dispo und Budget-Forecast. Im Projektkontext bedeutet das, dass der Bereich nicht isoliert funktioniert, sondern direkt an Team, Status und weitere Projektbereiche anknüpft.
Planung hängt fachlich an Cash-Flow. Dadurch ist für Nutzer sofort klar, in welchem größeren Ablauf das Modul seinen Platz hat.
Typische Einsatzfälle
Diese Situationen zeigen, wann der Bereich in einem sauberen Rollout oder im laufenden Betrieb konkret Mehrwert liefert.
Forecast früh erkennen
Im Cockpit werden Planwerte, Ist-Kosten und Budget-Forecast monatlich zusammengedacht, damit kritische Monate früh sichtbar werden.
Einflüsse und Abflüsse planbar halten
Wiederkehrende oder einmalige Zahlungsströme lassen sich mit Zeitraum, Rhythmus und Wachstum pro Intervall strukturiert hinterlegen.
MA-Dispo mit Kosten koppeln
Geplante Stunden und interne Sätze zeigen, wie sich personelle Disposition auf Nettoverlauf und verfügbares Budget auswirkt.
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.
Cash-Flow
Cash-Flow ergänzt Planung, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsBudget
Budget ergänzt Planung, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsTerminplan
Terminplan ergänzt Planung, 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
Eines der saubersten Module — konsistente _all/scoped-Verdrahtung über zwei Domänen (Cash-Flow-Plan + Personal-Plan). 4 Permission-Paare, alle API+RLS verdrahtet.
Entwickler-Info aufklappen (5)
Saubere Symmetrie über zwei Domänen
Cash-Flow (project_planning_cash_flow) und Staffing (project_planning_staffing) haben jeweils ein view+manage-Paar mit _all/scoped-Variante. Konsistent verdrahtet, kein TRULY UNBOUND, keine Backdoors. RLS-Policies sind symmetrisch zu API-Pre-Checks (cash-flow.ts:114/120/153/159 + staffing.ts:112/118/151/157).
pages/api/projects/[id]/planning/cash-flow.tspages/api/projects/[id]/planning/staffing.tsRLS: project_planning_cash_flow + project_planning_staffing
manage-Permissions decken INSERT+UPDATE+DELETE
manage_plan/_all und manage_staffing/_all sind keine "edit"-Permissions, sondern volle CRUD-Permissions. Eine Permission gates alle Mutations. Pragmatisch für ein Plan-Modul (Pläne werden typischerweise von einer Person verwaltet), aber asymmetrisch zur sonstigen edit/create/delete-Granularität anderer Module.
Cross-Modul-Coupling zu AI-Tasks
view_plan + view_plan_all werden auch aus pages/api/tasks/* aufgerufen (linkable-entities, links, index). Gleiches Muster wie invoices.view_invoices: Tasks-Modul hängt indirekt an dieser Permission. Nicht in MANUAL_PERMISSION_DEPENDENCIES — sollte als Stage-1-Regel ergänzt werden.
pages/api/tasks/index.ts:75pages/api/tasks/[id]/links/index.ts:63pages/api/tasks/linkable-entities.ts:91
view_plan: API + RPC + RLS (defence in depth)
view_plan und view_plan_all triggern die RPC get_project_planning_overview, die aggregierte Plan-Übersicht zurückgibt. Plus klassische RLS auf den zugrunde liegenden Tabellen. Drei Verteidigungs-Schichten — selten in der App.
RPC: get_project_planning_overview
Stage-1-Couplings (bestehend)
view_plan und view_staffing brauchen projects.view_all_projects (Endpoint lädt Zielprojekt). Plus auto-generic view-before-edit-Regeln zwischen view/manage.