Wofür das Modul gedacht ist
LV-Positionen ist Teil des aktiven Modul-Katalogs und deckt einen klaren Ausschnitt des Produktalltags ab.
Leistungsverzeichnis für Mengen, Leistungen und budgetnahe Steuerung. Im Projektkontext bedeutet das, dass der Bereich nicht isoliert funktioniert, sondern direkt an Team, Status und weitere Projektbereiche anknüpft.
LV-Positionen ist als eigenständiger Produktbaustein gedacht. Gerade deshalb lohnt sich ein Blick darauf, wie der Bereich mit Rollen, Datenkontext und angrenzenden Modulen zusammenspielt.
Typische Einsatzfälle
Diese Situationen zeigen, wann der Bereich in einem sauberen Rollout oder im laufenden Betrieb konkret Mehrwert liefert.
Projektvorgabe fuer neue LV-Positionen setzen
Im Projekt kann im Feld Standard-MwSt fuer LV-Positionen bewusst zwischen Vererbung und Projekt-Override gewechselt werden. So wird der passende Satz direkt im Projektkontext festgelegt.
Tenant-Standard zentral pflegen
Wenn Projekte keinen Override setzen, zieht der Bereich den Wert zentral aus Administration > App-Einstellungen > Projekte > Standard-MwSt LV (%). Das schafft einen gemeinsamen Ausgangspunkt fuer neue LV-Positionen.
Einzelpositionen bei Bedarf abweichend erfassen
Beim Anlegen einer LV-Position wird der aufgeloeste Satz nur vorbelegt. Eine einzelne Position kann weiterhin bewusst mit einem anderen Prozentsatz gespeichert werden.
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.
Budget
Budget ergänzt LV-Positionen, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsRechnungsstellung
Rechnungsstellung ergänzt LV-Positionen, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsÜbersicht
Übersicht ergänzt LV-Positionen, 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
Größtes Modul der App (18 Actions). Dreigliedrig: LV-Positionen + Kostenanpassungen + Mengenerweiterungen, plus internal_transfer und save_export_config_team. Drei interessante Schema-Eigenheiten dokumentiert unten.
Entwickler-Info aufklappen (5)
⚠ KRITISCHBackdoor: cost_adjustments scoped Sicht ohne action-key
cost_adjustments_select_project gates über eine pure project_members EXISTS-Subquery, OHNE can_perform_action. Es existiert KEINE view_cost_adj scoped-Variante — nur view_cost_adj_all (global). Konsequenz: jeder Projekt-Member liest die Mehr-/Minderkosten des Projekts ohne explizite view-Permission. Asymmetrisch zu quantity_extensions, wo der scoped Pfad sauber über view_project_lv gates.
RLS: public.cost_adjustments :: cost_adjustments_select_projectVergleich: quantity_extensions_select_project nutzt sauber view_project_lv
view_project_lv ist Träger der Mengenerweiterungs-Sicht
quantity_extensions_select_project nutzt view_project_lv (statt einer eigenen view_quantity_ext-Permission). Pragmatisch: wer LV sieht, sieht auch Erweiterungen. Saubere kontextuelle Coupling — unterschiedlich zu cost_adj, das auf Membership fällt.
RLS: quantity_extensions_select_project
⚡ MERKWÜRDIGlv_position_assignees_select hat keine action-permission
Die SELECT-Policy auf lv_position_assignees prüft NUR tenant_id — keine action-Permission. Jeder im Tenant sieht alle Zuweisungen, unabhängig von Projekt-Mitgliedschaft. Mutations (INSERT/UPDATE/DELETE) sind über edit_lv gegated. Möglicherweise absichtlich, da Zuweisungen nicht sensitiv sind — sollte aber bewusst entschieden sein.
RLS: public.lv_position_assignees :: lv_position_assignees_select
⚡ MERKWÜRDIGconfirm_extension ist Trigger-enforced — UI-Gate fehlt
check_quantity_extension_status_change ist ein Trigger auf quantity_extensions. Wer die Permission nicht hat, sieht den "Bestätigen"-Knopf trotzdem im UI; das DB-UPDATE wirft erst beim Speichern eine Exception. Schöner wäre ein Frontend-Gate.
DB Trigger: check_quantity_extension_status_change
Stage-1-Couplings (bereits in MANUAL_PERMISSION_DEPENDENCIES)
create_quantity_ext und confirm_extension brauchen view_project_lv (view-before-edit). view_project_lv selbst braucht projects.view_all_projects. Plus generische view-before-edit / edit-before-delete-Regeln zwischen den 18 Actions.