Finanzen & Controlling · Projekt-Teilbereich

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

Erweiterte Rechnungsstellung mit Positionen, Ketten und PDF-Generierung. Das Modul erscheint innerhalb eines einzelnen Projekts und wirkt damit unmittelbar im Projektkontext.

  • Rechnungsstellung erklärt kompakt, wofür der Bereich gedacht ist und wann er im Arbeitsalltag relevant wird.
  • Der Bereich spielt in der Praxis besonders mit Rechnungen und Projekt-Zahlungen zusammen.
  • Bei finanznahen Modulen sollten Sichtbarkeit und Freigaben bewusster gesetzt werden als bei reinen Lesebereichen.
Modulzweck

Wofür das Modul gedacht ist

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

Erweiterte Rechnungsstellung mit Positionen, Ketten und PDF-Generierung. Im Projektkontext bedeutet das, dass der Bereich nicht isoliert funktioniert, sondern direkt an Team, Status und weitere Projektbereiche anknüpft.

Rechnungsstellung 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

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

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

Eines der saubersten Module — sehr konsistente _all/scoped-Verdrahtung mit API+RLS-Schicht über alle 6 Action-Familien. Plus standalone manage_settings (Trigger-enforced) und ein Sonderfall bei generate_pdf (RLS-only, kein API-Gate).

Entwickler-Info aufklappen (5)

6 saubere _all/scoped-Paare mit API+RLS-Schicht

view, create, edit, delete, generate_pdf und manage_chains folgen jeweils dem etablierten Pattern. RLS auf invoices, invoice_items, invoice_attachments und invoice_chains gegated jeweils per OR-Klausel über _all + scoped. API-Endpoints prüfen beide Permission-Keys vor dem DB-Zugriff. Klassisches Defense-in-Depth.

  • pages/api/invoices-pro/index.ts:38-43 (view-Pre-Check) + :129-134 (create)
  • pages/api/invoices-pro/[id]/index.ts:58-63, :107-112, :203-208
  • RLS: invoice_items, invoices, invoice_attachments, invoice_chains

⚡ MERKWÜRDIGgenerate_pdf hat KEINEN direkten API-Pre-Check

Während alle anderen Actions im Code via can_perform_action geprüft werden, taucht generate_pdf nirgends in TS-Files auf. Die Permission gates ausschliesslich über RLS-SELECT-Policies invoices_pro_pdf_project und _all. Wahrscheinlich Service-Role-Render mit RLS als einzige Hürde. Wer view_invoices_pro hat aber generate_pdf nicht, sieht den Invoice-Record nicht — der PDF-Renderer bekommt leere Daten und erzeugt eine kaputte/leere PDF, statt mit 403 zu antworten.

  • RLS: public.invoices :: invoices_pro_pdf_all + invoices_pro_pdf_project

manage_chains: eine Permission deckt INSERT+UPDATE+DELETE

Anders als bei den invoice_pro-Actions (wo create/edit/delete getrennt sind), regiert manage_chains alle drei Mutations auf invoice_chains. Pragmatisch — Chains werden typischerweise von der gleichen Person verwaltet — aber asymmetrisch zur sonstigen Granularität des Moduls.

manage_settings: Trigger-enforced + Stage-1-Coupling

manage_settings ist Trigger-enforced via check_invoice_settings_permission RPC (boolean) auf invoice_settings. Plus die bestehende Stage-1-Regel: setzt view_invoices_pro voraus (Settings sind im Invoices-Pro-Bereich erreichbar).

Stage-1-Regeln (bestehend)

manage_settings → view_invoices_pro. delete_invoice_pro / _all → edit_invoice_pro / _all (generic edit-before-delete).