# Next Steps Stand: 2026-04-15 ## 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