refactoring

TrafagSalesExporter/NEXT_STEPS_2026-04-15.md

@@ -27,6 +27,147 @@ Was fuer Waehrungen trotzdem noch offen bleibt:
 - 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.
@@ -183,3 +324,37 @@ Aktueller Teststatus:
 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