Ai/TrafagSalesExporter/NEXT_STEPS_2026-04-15.md

# Next Steps

Stand: 2026-04-15

## Nachtrag 2026-04-29 B1-Belegwaehrungsfelder

Der HANA/B1-Export zieht jetzt zusaetzliche Belegwaehrungsfelder:

- `DocCur`
- `DocTotalFC`
- `DocTotal`
- `VatSumFC`
- `VatSum`
- `DocRate`
- `OADM.MainCurncy`

Neue Zielfelder:

- `DocumentCurrency`
- `DocumentTotalForeignCurrency`
- `DocumentTotalLocalCurrency`
- `VatSumForeignCurrency`
- `VatSumLocalCurrency`
- `DocumentRate`
- `CompanyCurrency`

Zusaetzlich gilt jetzt:

- `StandardCostCurrency` kommt im HANA-Pfad aus `OADM.MainCurncy`
- `Sales_All_*.xlsx` enthaelt die neuen Spalten
- `CentralSalesRecords` enthaelt die neuen Spalten
- bestehende SQLite-DBs werden beim Start um die Spalten erweitert
- Manual-Excel-Import kann die neuen Spalten lesen

### Wichtig fuer Auswertungen

Die neuen `DocumentTotal*`- und `VatSum*`-Werte sind Belegkopfwerte und werden in der positionsbasierten Datei pro Position wiederholt.

Power BI:

- nicht positionsweise summieren
- zuerst nach Beleg deduplizieren, z. B. `TSC` + `DocumentType` + `Invoice Number`
- danach Belegkopfwerte summieren

Positionswerte wie `Sales Price/Value`, `Quantity` und `Standard cost` bleiben fuer positionsbasierte Summen geeignet.

### Verifikation

Geprueft:

```text
dotnet build .\TrafagSalesExporter.csproj --verbosity minimal
dotnet test .\TrafagSalesExporter.Tests\TrafagSalesExporter.Tests.csproj --verbosity minimal
```

Ergebnis:

- Build erfolgreich
- Tests erfolgreich
- `48/48` Tests gruen

## Nachtrag 2026-04-29 Clean-Code-/DI-Befund

Aktueller Architektur- und DI-Zustand nach den letzten Umbauten:

Gesamturteil:

- die App ist deutlich besser strukturiert als zu Beginn
- die Grundarchitektur ist brauchbar bis gut und fuer pragmatischen produktiven Einsatz geeignet
- Dependency Injection wird grundsaetzlich sinnvoll genutzt
- Clean Code ist mittel bis gut, aber noch nicht durchgehend konsequent

Was positiv ist:

- Kernservices laufen weitgehend ueber Interfaces und DI
- `DataSourceAdapter`-Pattern trennt `HANA`, `SAP_GATEWAY` und `MANUAL_EXCEL`
- `SiteExportService` ist dadurch deutlich schlanker als frueher
- UI-nahe Page-Services wurden eingefuehrt
- viele Razor-Seiten sind nicht mehr direkt `DbContext`-lastig
- `Scoped` fuer Page-Services und `Singleton` fuer gemeinsame Infrastruktur/Orchestrierung ist bewusst gewaehlt
- Tests decken wichtige Fachlogik ab, u. a. Transformationen, ConfigTransfer, DatabaseInitialization und ManagementCockpit

Was noch nicht ideal ist:

- `DatabaseInitializationService` bleibt ein produktiver Reparatur-/Migrationsblock und ist kein sauberes versioniertes Migrationssystem
- `Settings.razor` und `Standorte.razor` enthalten weiterhin relativ viel UI-/Workflow-Logik
- `ManagementCockpitService`, `ConfigTransferService` und Teile der Initialisierung sind noch sehr breit
- konsolidierter Export hat historisch noch Semantikreste zwischen Live-Snapshot und `CentralSalesRecords`
- Secrets/Zugangsdaten sind noch nicht ideal geloest
- zentraler Retry-/Resilience-Layer fuer SAP/HANA/SharePoint fehlt
- Auth ist jetzt pragmatisch mit User/Admin geschnitten, aber noch nicht fein nach `Viewer`, `Exporter`, `Admin`, `Finance`

Sinnvolle spaetere Clean-Code-Schritte:

1. `ManagementCockpitService` in kleinere Query-, Aggregation- und Currency-Komponenten teilen
2. `Settings.razor` und `Standorte.razor` weiter Richtung Page-/Application-Services entlasten
3. `DatabaseInitializationService` langfristig durch versionierte Migrationen ersetzen
4. Auth-Policies fachlich feiner schneiden, z. B. `Viewer`, `Exporter`, `Admin`, `Finance`
5. Retry/Timeout/Failure-Handling fuer externe Systeme zentralisieren
6. Secret-Store-Konzept umsetzen

## Nachtrag 2026-04-29 Authentifizierung / AD

Die App wurde nach IT-Rueckmeldung gegen anonymen Zugriff abgesichert.

Neuer Stand:

- globale Authentifizierungspflicht
- produktiv vorgesehen: Windows Authentication / Active Directory
- Zugriff und Adminrechte ueber AD-Gruppen
- kein eigener App-Login
- kein versteckter produktiver Backdoor
- lokaler Development-Bypass nur bei `ASPNETCORE_ENVIRONMENT=Development`

Neue/angepasste Dateien:

- `Program.cs`
- `Security/SecurityOptions.cs`
- `Security/SecurityPolicies.cs`
- `Security/DevelopmentAuthenticationHandler.cs`
- `Components/Routes.razor`
- `Components/_Imports.razor`
- `Components/Layout/NavMenu.razor`
- `Components/Layout/MainLayout.razor`
- `Components/Pages/Settings.razor`
- `Components/Pages/Standorte.razor`
- `Components/Pages/Transformations.razor`
- `appsettings.json`
- `appsettings.Development.json`

Aktuelle Default-Gruppen:

- `TRAFAG\TrafagSalesExporter-Users`
- `TRAFAG\TrafagSalesExporter-Admins`

### Noch mit IT zu klaeren

1. Exakte AD-Domain-/Gruppennamen bestaetigen
2. AD-Gruppen anlegen oder bestehende Gruppen verwenden
3. IIS-Zielumgebung festlegen
4. Auf IIS Windows Authentication aktivieren
5. Auf IIS Anonymous Authentication deaktivieren
6. Sicherstellen, dass produktiv nicht `ASPNETCORE_ENVIRONMENT=Development` gesetzt ist
7. Test mit einem normalen User und einem Admin-User durchfuehren

### Fachliche Rollenentscheidung

Aktuell:

- Admin:
  - `Settings`
  - `Standorte`
  - `Transformations`
- berechtigter User:
  - Dashboard
  - Management Cockpit
  - Logs

Noch zu entscheiden:

- ob `Logs` ebenfalls Admin-only sein soll
- ob Export-Buttons im Dashboard nur fuer eine eigene Rolle `Exporter` sichtbar sein sollen
- ob Management Cockpit fuer alle berechtigten User oder nur fuer Management/Finance-Gruppen sichtbar sein soll

### Verifikation

Geprueft:

```text
dotnet build .\TrafagSalesExporter.csproj --verbosity minimal
dotnet test .\TrafagSalesExporter.Tests\TrafagSalesExporter.Tests.csproj --verbosity minimal
```

Ergebnis:

- Build erfolgreich
- Tests erfolgreich
- `48/48` Tests gruen
- Auth-Policy-Tests fuer AccessGroup, AdminGroup und Development-Admin vorhanden
- lokaler Development-Auth-Start geprueft: `http://localhost:55416` antwortet mit HTTP `200`

## Nachtrag 2026-04-29 Management Cockpit

Seit dem 2026-04-17 wurden im `Management Cockpit` weitere Auswertmoeglichkeiten umgesetzt und nachtraeglich aus dem aktuellen Code rekonstruiert.

Aktueller neuer Stand:

- Summenfeld ist waehbar statt fest auf Umsatz:
  - `Sales Price/Value`
  - `Quantity`
  - `Standard cost`
  - `Quantity * Standard cost`
- Anzeige-Waehrung ist waehbar:
  - `EUR`
  - `USD`
  - `Original`
- betragliche Werte werden ueber `CurrencyExchangeRateService` umgerechnet
- nicht-betragliche Werte wie `Quantity` bleiben ohne Waehrung
- fehlende Wechselkurse werden gezaehlt und in der UI/Hinweisen sichtbar
- zentrale Roh-Auswertung kann weitere Summenfelder als Zusatzspalten in Jahres-, Monats- und Tageswerten anzeigen
- dateibasierte Excel-Analyse nutzt ebenfalls Summenfeld und Anzeige-Waehrung

Betroffene Dateien:

- `Components/Pages/ManagementCockpit.razor`
- `Models/ManagementCockpitModels.cs`
- `Services/IManagementCockpitService.cs`
- `Services/ManagementCockpitPageService.cs`
- `Services/ManagementCockpitService.cs`
- `TrafagSalesExporter.Tests/ManagementCockpitServiceTests.cs`

Neue Tests:

- Umrechnung zentraler Werte in EUR
- Wechselkurs-Cache pro Waehrung/Ziel/Datum
- Mengen-Auswertung ohne Waehrungsumrechnung
- Zusatzwerte in Zeitreihen

### Jetzt sinnvoll zu pruefen

1. `dotnet test .\TrafagSalesExporter.Tests\TrafagSalesExporter.Tests.csproj --verbosity minimal`
2. Management Cockpit in der App oeffnen
3. zentrale Auswertung mit `Sales Price/Value` in `EUR` pruefen
4. zentrale Auswertung mit `Quantity` pruefen und bestaetigen, dass keine Waehrung angezeigt wird
5. Zusatzfelder `Quantity` und `Quantity * Standard cost` in Jahres-/Monatswerten pruefen
6. Dateianalyse einer exportierten Excel mit unterschiedlichen Summenfeldern pruefen
7. fachlich klaeren, ob `CHF` neben `EUR` und `USD` als Anzeige-Waehrung angeboten werden soll
8. fachlich klaeren, ob fehlende Wechselkurse als `0` in Zielwaehrung korrekt sind oder separat ausgewiesen werden sollen

## Nachtrag 2026-04-17 Refactoring-Fortschritt

Mehrere frueher als hoch priorisiert markierte Architekturpunkte sind inzwischen bereits umgesetzt.

Erledigt:

- DataSourceAdapter-Pattern fuer `HANA`, `SAP_GATEWAY`, `MANUAL_EXCEL`
- `SiteExportService` deutlich verschlankt
- Page-Services auf `Scoped`
- `DatabaseInitializationService` in Schema-/Seed-/Orchestrator-Bloecke getrennt
- `Dashboard`, `Logs` und `Transformations` von direktem `DbContext`-Zugriff befreit
- HANA-SQL-Injection-Pfad geschlossen
- blockierende `.GetAwaiter().GetResult()`-Aufrufe im HANA-Pfad entfernt

Neuer verifizierter Stand:

- `dotnet build .\TrafagSalesExporter.csproj --verbosity minimal` erfolgreich
- `dotnet test .\TrafagSalesExporter.Tests\TrafagSalesExporter.Tests.csproj --verbosity minimal`
- `36/36` Tests gruen

### Neue Top-Prioritaeten ab jetzt

#### 1. Adapter- und Resolver-Tests nachziehen

Prio hoch.

Warum:

- das neue `DataSourceAdapter`-Pattern ist architektonisch wichtig
- genau dieser neue Schnitt hat aktuell noch keine gezielten Unit-Tests

Sinnvoll waeren:

- `DataSourceAdapterResolver`-Tests
- `HanaDataSourceAdapter`-Tests
- `SapGatewayDataSourceAdapter`-Tests
- `ManualExcelDataSourceAdapter`-Tests

#### 2. Retry-/Robustheitslayer

Prio hoch.

Vor allem fuer:

- SharePoint
- SAP Gateway
- HANA-nahe Netzpfade

Aktuell brechen diese Integrationen bei transienten Problemen zu direkt ab.

#### 3. Secret-Store-Konzept

Prio hoch bis mittel.

Aktuell liegen Zugangsdaten weiterhin in der App-/DB-Konfiguration.
Langfristig sollte entschieden werden:

- Windows Credential Manager
- DPAPI / verschluesselte Ablage
- externer Secret Store

#### 4. `DatabaseInitializationService` weiter haerten, aber nicht mehr blind gross refactoren

Prio mittel.

Der schlimmste Architekturteil ist deutlich besser als vorher.
Weitere Arbeit dort sollte jetzt nur noch zielgerichtet passieren:

- Regressionstests fuer konkrete Legacy-/Repair-Zustaende
- spaeter moeglichst versionierte Migrationen

#### 5. MudBlazor-Analyzer-Warnungen bereinigen

Prio mittel.

Nicht kritisch fuer Produktion, aber sinnvoll fuer sauberen Build:

- `Logs.razor`
- `Transformations.razor`
- `Standorte.razor`

### Was im Vergleich zu frueher nicht mehr Top-Prioritaet ist

Nicht mehr ganz oben:

- generisches weiteres Page-Service-Refactoring um des Refactorings willen
- noch mehr strukturelles Verschieben ohne Risikoreduktion

Der wirtschaftlich sinnvolle Fokus liegt jetzt eher auf:

- Absicherung
- Robustheit
- Integrationsstabilitaet

## Nachtrag 2026-04-17

Der Punkt `CHF-Umrechnung / Wechselkurse` ist nicht mehr komplett offen.

Der aktuelle Ist-Stand ist:

- `CurrencyExchangeRateService` ist implementiert
- `ExchangeRateImportService` importiert ECB-Kurse
- `NormalizeCurrencyCode` und `ConvertCurrency` sind im Transformationssystem registriert
- fehlende Unit-Tests dafuer wurden am 2026-04-17 ergaenzt

Neuer Teststand:

- `dotnet test .\TrafagSalesExporter.Tests\TrafagSalesExporter.Tests.csproj --verbosity minimal`
- erfolgreich
- `31/31` Tests gruen

Was fuer Waehrungen trotzdem noch offen bleibt:

- fachlicher Einsatz der `ConvertCurrency`-Regeln in echten Standortkonfigurationen pruefen
- UI-Flow fuer Wechselkurspflege in `Settings.razor` manuell gegenpruefen
- ECB-Import einmal real ueber die UI bzw. App-Funktion pruefen
- bestaetigen, fuer welche Sichten CHF die Zielwaehrung sein soll
- Management-Cockpit-Rohsicht nur dann auf CHF umstellen, wenn fachlich gewuenscht

## Architektur-Nachtrag 2026-04-17

Nach einer separaten Architekturpruefung wurden die naechsten Schritte neu priorisiert.

Wichtig:

- neue Fachfeatures sind aktuell **nicht** der erste Engpass
- zuerst muessen die Architektur-Risiken in Initialisierung, Config-Import und UI-Service-Schnitt bereinigt werden

### Neue Top-Prioritaeten

#### 1. `DatabaseInitializationService` absichern

Prio sehr hoch.

Gruende:

- Startlogik enthaelt manuelle Schema-Migrationen
- FK-Reparaturen laufen produktiv beim App-Start
- dort wurde ein konkretes Risiko fuer verschobene Spaltenwerte beim `Sites_old`-Kopierpfad erkannt

Vor weiterer Fachentwicklung:

- Initialisierungspfad genau pruefen
- SQL-Kopierlogik validieren
- moeglichst Richtung versionierte Migrationen bewegen

#### 2. `ConfigTransferService.ImportJsonAsync` neu denken

Prio sehr hoch.

Aktuelles Problem:

- Import loescht sehr viel und baut danach stueckweise neu auf
- nicht atomar
- potenziell teilzerstoerter Zustand bei Fehlern
- `CentralSalesRecords` werden mitimportiert/mitgeloescht, obwohl sie eher Laufzeitdaten als Konfiguration sind

Ziel:

- atomarer Import
- saubere Trennung zwischen Konfiguration und Betriebsdaten

#### 3. Razor-Seiten entlasten

Prio hoch.

Betroffen vor allem:

- `Components/Pages/Settings.razor`
- `Components/Pages/Standorte.razor`

Ziel:

- DB- und Fachlogik aus UI-Code in Services / Application-Layer verschieben
- Seiten nur noch fuer Interaktion und Formularzustand

#### 4. Konsolidierten Export semantisch klaeren

Prio mittel.

Offene Frage:

- zentrale Datei aus laufendem Snapshot
  oder
- zentrale Datei immer aus `CentralSalesRecords`

Aktuell ist die Verantwortung unscharf.

#### 5. Reporting verallgemeinern

Prio mittel.

Erst nach den Infrastrukturthemen:

- hartcodierte Jahreslogik im Cockpit entfernen
- fachlich entscheiden, ob und wo CHF-Rohsicht gebraucht wird

### Praktische Reihenfolge fuer den naechsten Wiedereinstieg

Wenn nach erneutem Absturz oder Kontextverlust weitergemacht wird:

1. `HANDOFF_2026-04-15.md` lesen, speziell die Architekturpruefung vom 2026-04-17
2. `DatabaseInitializationService` als ersten Risikoblock ansehen
3. `ConfigTransferService.ImportJsonAsync` als zweiten Risikoblock ansehen
4. erst danach wieder an Cockpit / CHF / weitere Fachfeatures gehen

## Nachtrag HANA-/Standort-Workflow 2026-04-17

Der doppelte HANA-Workflow wurde inzwischen bereits bereinigt.

Neuer Stand:

- oben zentrale HANA-Konfiguration pro Quellsystem `BI1` / `SAGE`
- unten im Standort keine eigene wirksame Voll-HANA-Konfiguration mehr
- HANA-basierte Standorte ziehen ihre technische Verbindung aus der zentralen Quellsystem-Konfiguration
- Standort bleibt fuer fachliche Daten und optionale Credential-Overrides zustaendig
- die frueher doppelte HANA-UI im Standortdialog ist inzwischen auch sichtbar entfernt
- der Verbindungstest in `Settings.razor` prueft und meldet jetzt die zentrale HANA-Verbindung klar

### Was dazu noch praktisch geprueft werden sollte

- `Standorte`-Seite im UI manuell durchklicken
- pruefen, ob `BI1`- und `SAGE`-Standort beim Speichern sauber auf die zentrale HANA-Konfiguration zeigen
- pruefen, ob Aenderung oben bei zentraler HANA-Konfiguration in nachfolgenden Exporten wirklich greift

### Anschlussarbeiten

- `ConfigTransferService` spaeter auf das neue zentrale HANA-Modell fachlich nachziehen und kritisch pruefen
- `DatabaseInitializationService` weiter konsolidieren, damit die Zuordnung alter HANA-Daten langfristig robuster wird

## Nachtrag Quellsystem-Verwaltung 2026-04-17

Die bisher hart codierten Quellsystem-Listen wurden ersetzt.

Neuer Stand:

- `SourceSystemDefinition` ist jetzt die zentrale Stammdatenquelle fuer Quellsysteme
- `Settings.razor` hat jetzt eine GUI zur Pflege von Quellsystemen
- `Standorte.razor` zieht seine Quellsystem-Auswahl aus diesen Stammdaten
- `Transformations.razor` zieht die Systemauswahl ebenfalls aus diesen Stammdaten
- zentrale Credentials haengen jetzt am Quellsystem selbst
- HANA-Zentralverbindungen werden nur noch fuer Quellsysteme mit Anschlussart `HANA` gezeigt
- alte zentrale Credential-Felder in `ExportSettings` sind aus dem aktiven Codepfad entfernt
- `ExportSettings` wird beim Start auch schematisch auf das neue Feldset bereinigt
- HANA speichert zentral keine eigenen Credentials mehr; dort bleiben nur technische Verbindungsdaten
- `HanaServer.Username` / `Password` sind nur noch Laufzeitfelder und nicht mehr im EF-Schema gemappt
- SAP Service URL wird jetzt zentral im Quellsystem gepflegt; der Standort haelt nur noch ein optionales Override
- Quellsysteme werden jetzt per Dialog bearbeitet statt nur ueber Inline-Tabellenfelder

### Was dazu noch praktisch geprueft werden sollte

- in `Settings` ein neues Quellsystem per GUI anlegen
- pruefen, ob es danach in `Standorte` und `Transformations` sofort auswählbar ist
- pruefen, ob deaktivierte Quellsysteme in neuen Standort-/Regelanlagen nicht mehr normal angeboten werden
- pruefen, ob Aenderung der Anschlussart von `HANA` auf `SAP_GATEWAY` oder `MANUAL_EXCEL` fachlich sauber wirkt
- pruefen, ob bestehende BI1/SAGE/SAP-Daten nach Startmigration korrekt in `SourceSystemDefinitions` stehen
- pruefen, ob Konfiguration-Export/Import ohne die alten Credential-Felder sauber mit `SourceSystemDefinitions` arbeitet
- pruefen, ob zentrale SAP Service URL ohne Override sauber fuer Refresh, Export und Dashboard greift
- pruefen, ob SAP Service URL Override am Standort die zentrale URL erwartungsgemaess uebersteuert

## Nachtrag 2026-04-16

Seit dem letzten Stand kamen mehrere groessere Erweiterungen dazu. Die offenen Punkte unten muessen deshalb im neuen Kontext gelesen werden.

## 0. Neuer Ist-Stand

Zusaetzlich zum alten Stand ist jetzt vorhanden:

- manueller Standort-Import ueber `MANUAL_EXCEL`
- Dashboard mit `Alle exportieren`, `Zentrale Datei neu erzeugen` und zentralem `Excel oeffnen`
- Roh-Auswertung im `Management Cockpit` direkt aus `CentralSalesRecords`
- erweitertes Transformationssystem mit `Value`- und `Record`-Regeln
- HANA-Schema-Lookup im Standortdialog
- Testprojekt mit aktuell 18 gruenden Tests

## 1. Status

Der Export geht jetzt wieder durch.

Die zuletzt gefundene Hauptursache war nicht mehr ein reiner SQLite-Lock beim Batch-Insert, sondern ein kaputter FK-Schemazustand in der bestehenden DB:

- SQLite referenzierte in mindestens einer Tabelle noch `main.Sites_old`
- dadurch scheiterte `SaveChangesAsync()` beim Schreiben z. B. in `AppEventLogs` oder `ExportLogs`
- sichtbarer Effekt: Export blieb nach `Zentrale Tabelle: ... Datensaetze gespeichert.` haengen

## 2. Umgesetzter Fix

Umgesetzt wurde:

- Dashboard-Live-Status liest waehrend laufendem Export nicht mehr staendig aus `AppEventLogs`, sondern nutzt den In-Memory-Status des `ExportOrchestrationService`
- SQLite `Default Timeout` in `Program.cs` auf `60` erhoeht
- `CentralSalesRecordService` setzt nach den Batches explizit `Zentrale Tabelle aktualisiert`
- `DatabaseInitializationService` repariert beim App-Start automatisch Tabellen, deren FK-SQL noch `Sites_old` referenziert

Betroffene Dateien:

- `Program.cs`
- `Components/Pages/Dashboard.razor`
- `Services/CentralSalesRecordService.cs`
- `Services/DatabaseInitializationService.cs`

## 3. Was noch getestet werden sollte

Kurz gegenpruefen:

- Export eines Standorts erneut
- `Excel oeffnen` nach erfolgreichem Export
- `Export erfolgreich` inkl. `Pfad=...`
- Dashboard-Live-Status setzt sich nach Abschluss sauber zurueck
- `Alle exportieren`
- `Zentrale Datei neu erzeugen`
- zentrale Datei im Dashboard oeffnen

## 3a. Manuellen Excel-Import pruefen

Zu testen:

- Standort auf `MANUAL_EXCEL` stellen
- Excel im Standort hochladen
- Standort exportieren
- pruefen, ob `CentralSalesRecords` fuer diesen Standort ersetzt wurden
- pruefen, ob der zentrale Export den Standort korrekt enthaelt

Dateien:

- `Components/Pages/Standorte.razor`
- `Services/ManualExcelImportService.cs`
- `Services/SiteExportService.cs`

## 3b. HANA-Schema-Lookup pruefen

Zu testen:

- bei `BI1`-Standort `Schemas laden`
- bei `SAGE`-Standort `Schemas laden`
- wird ein plausibles B1-Schema angeboten?
- funktioniert danach Export ohne manuelle Schema-Eingabe?
- zeigt England / Spezialstandort jetzt schneller, wenn Schema oder Rechte nicht passen?

Dateien:

- `Components/Pages/Standorte.razor`
- `Services/HanaQueryService.cs`

## 4. Falls wieder ein Fehler auftritt

In dieser Reihenfolge pruefen:

1. Exakte Fehlermeldung aus `AppEventLogs` bzw. Console notieren
2. Pruefen, ob die Reparaturlogik beim Start gelaufen ist
3. Pruefen, ob noch weitere Tabellen mit veralteter FK-Referenz existieren
4. Erst danach wieder am Batch-/Commit-Pfad der zentralen Speicherung arbeiten

## 5. SAP-Funktionalitaet kurz gegenpruefen

Zu testen:

- `Quellen refreshen`
- `Felder aus Quellen laden`
- `Auto-Match`
- SAP-Export eines Standorts

Dateien:

- `Components/Pages/Standorte.razor`
- `Services/SapGatewayService.cs`
- `Services/SapCompositionService.cs`

## 6. Management Cockpit pruefen

Zu testen:

- vorhandene Excel-Datei auswaehlbar
- Analyse laeuft
- Kennzahlen plausibel
- Roh-Auswertung aus `CentralSalesRecords` laeuft
- Jahr/Monat-Filter funktionieren
- Summen nach Quelle / Land plausibel

Dateien:

- `Components/Pages/ManagementCockpit.razor`
- `Services/ManagementCockpitService.cs`

## 6a. Fachlich bewusst noch offen

Noch nicht final umsetzen ohne Rueckmeldung Fachseite:

- Intercompany-Filter
- fachliche Nutzung der CHF-Umrechnung in Cockpit / Reports
- Budgetvergleich
- Gruppenlogik
- Spartenlogik
- Margenlogik

Diese Punkte sollen spaeter moeglichst dynamisch auf dem neuen Transformations-/Mapping-Ansatz aufsetzen, aber aktuell nicht hart geraten werden.

## 6b. Naechste sinnvolle Testkandidaten

Wenn weiter in Tests investiert wird, sind die naechsten Kandidaten:

- `ExportOrchestrationService`
- spaeter End-to-End-Tests fuer den Wechselkurs-/Transformationspfad
- spaeter evtl. SQLite-nahe Integrationstests fuer `DatabaseInitializationService`

Aktueller Teststatus:

- `dotnet test .\TrafagSalesExporter.Tests\TrafagSalesExporter.Tests.csproj --verbosity minimal`
- erfolgreich
- `31/31` Tests gruen

## 7. Referenzdatei

Fuer den vollstaendigen Kontext zuerst lesen:

- `HANDOFF_2026-04-15.md`

## 8. Letzte bereinigte UI-Irritation

Stand 2026-04-17:

- In `Standorte` wurde die obere Box auf `Zentrale HANA-Technik` geklaert.
- Dort gibt es keinen `Server hinzufuegen`-Pfad mehr.
- Grund: zentrale HANA-Eintraege werden aus `Quellsystemen` mit Anschlussart `HANA` abgeleitet.
- `SAP` gehoert fachlich nicht in diese Box, sondern in `Settings -> Quellsysteme`.

Wichtig fuer den naechsten Wiedereinstieg:

- Wenn ein Benutzer fragt `wo ist SAP?`, ist die richtige Antwort: nicht in der HANA-Box, sondern in der zentralen Quellsystem-Verwaltung.
- Wenn ein HANA-System oben fehlt, zuerst `Settings -> Quellsysteme` pruefen und dort Anschlussart `HANA` setzen.

## 9. Config-Transfer erneut geprueft

Stand 2026-04-17:

- Der aktuelle Config-Import/-Export passt zum neuen Datenmodell.
- Zentral verwaltete Quellsysteme, SAP-Zentral-URL, HANA-Technik ohne HANA-Credentials und Standort-Overrides werden korrekt im Transferformat abgebildet.
- Die vorhandenen `ConfigTransferServiceTests` bestaetigen den aktuellen Rundlauf.

Fuer den naechsten Wiedereinstieg wichtig:

- Das aktuelle Format ist fuer heutige Exporte konsistent.
- `ImportJsonAsync` ist aber weiterhin nicht atomar und loescht zuerst produktive Konfiguration.
- Zusaetzlich gibt es ein Altformat-Risiko:
  - aeltere JSONs mit `SourceSystemDefinitions`, aber ohne `ConnectionKind`, koennen wegen DTO-Default falsch als `HANA` interpretiert werden.

Naechste saubere Haertung fuer dieses Thema:

- Config-Import transaktional machen
- Legacy-Fallback fuer fehlendes `ConnectionKind` einbauen