Wofür das Modul gedacht ist
Rechnungen ist Teil des aktiven Modul-Katalogs und deckt einen klaren Ausschnitt des Produktalltags ab.
Rechnungsverwaltung im Projektkontext. Im Projektkontext bedeutet das, dass der Bereich nicht isoliert funktioniert, sondern direkt an Team, Status und weitere Projektbereiche anknüpft.
Rechnungen 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.
Finanzstatus im Blick halten
Rechnungen 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.
Cash-Flow
Cash-Flow ergänzt Rechnungen, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsProjekt-Zahlungen
Projekt-Zahlungen ergänzt Rechnungen, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsRechnungsstellung
Rechnungsstellung ergänzt Rechnungen, 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
Klassische Rechnungs-Domäne (finance_basic, einfacher Vorgänger zu invoices_pro). 4 _all/scoped-Paare. Eigenheit: edit_invoice deckt einen breiten Lifecycle (Upload, Custom-Fields, Trash-Purge/Restore) — 7 API-Callsites in unterschiedlichsten Endpoints.
Entwickler-Info aufklappen (4)
edit_invoice ist sehr breit angelegt
edit_invoice ist nicht nur "Rechnung bearbeiten", sondern deckt auch: Beleg-Upload, Custom-Field-Edit, Storage-signed-upload-url, Trash-Purge, Trash-Restore. Die Permission steuert effektiv den ganzen Beleg-Lifecycle. Bei der Vergabe bedacht werden: wer edit_invoice bekommt, kann auch Belege purgen und restoren.
pages/api/invoices/[id].ts:96pages/api/invoices/[id]/upload.ts:145, 237pages/api/invoices/[id]/custom-fields.ts:46pages/api/storage/signed-upload-url.ts:185pages/api/trash/purge.ts:81pages/api/trash/restore.ts:81
Cross-Modul-Coupling zu AI-Tasks
view_invoices wird auch aus pages/api/tasks/* heraus aufgerufen (linkable-entities, links). Die AI-Aufgaben-Integration prüft view_invoices, um verlinkbare Rechnungen anzuzeigen. Tasks-Modul hängt indirekt an invoices.view_invoices.
pages/api/tasks/index.ts:51pages/api/tasks/[id]/links/index.ts:39pages/api/tasks/linkable-entities.ts:67
Stage-1-Couplings (bestehend)
view_invoices und create_invoice brauchen projects.view_all_projects (Endpoint lädt Zielprojekt). Plus auto-generic edit-before-delete für delete_invoice.
Asymmetrisches API-Pre-Check-Pattern (analog project_expenses)
view_invoices, create_invoice, edit_invoice, delete_invoice (scoped) haben API-Pre-Checks. Die _all-Varianten teilweise auch (edit_all, delete_all in 6+ Callsites), teilweise rein RLS (view_all, create_all). Konsistenz hier weniger sauber als in invoices_pro.