Wofür das Modul gedacht ist
Finmap Einstellungen ist Teil des aktiven Modul-Katalogs und deckt einen klaren Ausschnitt des Produktalltags ab.
API-Token, Banking-Auswahl und den Finmap-Sync inklusive Pause und Fortsetzen pro Mandant verwalten. Im tenantweiten Kontext sorgt der Bereich dafür, dass wiederkehrende Entscheidungen, Stammdaten oder Übersichten nicht in Nebensysteme ausweichen müssen.
Finmap Einstellungen 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.
Bestehende Finmap-Verbindung weiterpflegen
API-Token, aktive Bankings und der aktuelle Sync-Status bleiben an einer Stelle sichtbar, damit Finmap als laufende Quelle kontrollierbar bleibt.
Synchronisierung bewusst pausieren
Der Sync kann angehalten werden, ohne bestehende Finmap-Transaktionen zu verlieren. So kommen keine neuen Buchungen mehr nach, während die Historie erhalten bleibt.
Quellwechsel vorbereiten
Gerade bei der Umstellung auf finAPI oder ergänzenden CSV-Import hilft die Pause-Funktion dabei, Überschneidungen beim laufenden Import bewusst zu vermeiden.
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.
Banking-Integrationen
Banking-Integrationen ergänzt Finmap Einstellungen, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsTransaktionen
Transaktionen ergänzt Finmap Einstellungen, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsFinanzen
Finanzen ergänzt Finmap Einstellungen, 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
Empirisch erhobene Befunde aus Stage-2-Isolations-Probe inkl. 4-Schichten-Enforcement-Scan. Sehr ähnliches Muster zu banking_settings: API + RLS in Defense-in-Depth, keine eigene UI-Page, Tab-Komponente in /guv/transactions.
Entwickler-Info aufklappen (4)
⚠ KRITISCHModul hat keine eigene UI-Page — als Tab in /guv/transactions
In dim_modules ist route=NULL. Die Finmap-Konfiguration (Token, Sync-Intervall, Banking-Auswahl) rendert als Tab-Komponente FinmapSettings IM /guv/transactions-Page. Diese Page ist gegated auf hasAccess('guv_transactions') — Modul-Visibility. Konsequenz: Wer finmap_settings.* hat aber das guv_transactions-Modul nicht sehen darf, kommt nie an die Finmap-Konfiguration. Der Backend-Permission-Toggle ist live, aber praktisch unerreichbar — exakt das Problem, das auch banking_settings teilt.
pages/guv/transactions.tsx:165 (Gate-Check hasAccess('guv_transactions'))pages/guv/transactions.tsx:20 (FinmapSettings import)pages/guv/transactions.tsx:167 (canAction('finmap_settings', 'manage'))dim_modules.finmap_settings.route = NULL
view: API-Permission + RLS auf 2 SELECT-Policies
Das API-Gate steht in settings.ts:32 und sync-status.ts:31. RLS-SELECT-Policies finmap_tenant_bankings_read und finmap_tenant_tokens_read prüfen die gleiche Permission. Defense-in-Depth: Verweigerung wirkt sofort als 403 (API), aber selbst bei API-Bypass würde RLS leere Listen zurückgeben.
pages/api/finmap/settings.ts:32pages/api/finmap/sync-status.ts:31RLS: finmap_bankings_read, finmap_tokens_read
manage: API-Permission + RLS auf 6 mutation-Policies
API-Pre-Check in settings.ts:56,137 (Token-Set, sync_active toggle, sync_interval_hours), bankings.ts:32 (Bank-Auswahl). RLS auf finmap_tenant_bankings INSERT/UPDATE/DELETE und finmap_tenant_tokens INSERT/UPDATE/DELETE — symmetrisch zu view. Standalone — keine Cross-Module-Coupling auf Backend-Ebene.
pages/api/finmap/settings.ts:56pages/api/finmap/bankings.ts:32
Kein fact_transactions-Schreib-Coupling (anders als banking_settings)
Der eigentliche Finmap-Sync (der dann Transaktionen anlegen würde) läuft über eine Edge-Function (supabase/functions/finmap-sync). Die hier untersuchten Settings-Endpoints schreiben NICHT in fact_transactions. Daher gibt es bei finmap_settings — anders als bei banking_settings.csv_import oder banking_settings.sync — keine versteckte Cross-Module-Kopplung an guv_transactions.sync_transactions.
pages/api/finmap/settings.ts (config-only, kein fact_transactions write)supabase/functions/finmap-sync (Edge-Function — nicht im API-Probe-Scope)