983 lines
28 KiB
Markdown
983 lines
28 KiB
Markdown
# TrafagSalesExporter Handoff
|
|
|
|
Stand: 2026-04-15
|
|
|
|
## Nachtrag 2026-04-17
|
|
|
|
Der dokumentierte Stand in diesem Handoff war bei der Waehrungslogik nicht mehr aktuell.
|
|
|
|
Inzwischen gilt:
|
|
|
|
- Kurstabellen fuer `CurrencyExchangeRates` sind im System vorhanden
|
|
- `Settings` enthaelt bereits eine Pflegeoberflaeche fuer Wechselkurse
|
|
- `ExchangeRateImportService` importiert ECB-Tageskurse nach `CurrencyExchangeRates`
|
|
- `NormalizeCurrencyCode` ist als Value-Transformation vorhanden
|
|
- `ConvertCurrency` ist als Record-Transformation vorhanden
|
|
- `Program.cs` registriert beide Strategien sowie `CurrencyExchangeRateService` und `ExchangeRateImportService`
|
|
|
|
Wichtig:
|
|
|
|
- die Roh-Auswertung im `Management Cockpit` rechnet Stand heute weiterhin bewusst **nicht** in CHF um
|
|
- dort bleibt der Umsatz weiterhin in `Sales Currency`
|
|
- die Waehrungsumrechnung ist aktuell Teil des allgemeinen Transformations-/Mapping-Systems, nicht der Cockpit-Rohsicht
|
|
|
|
Zusatzlich wurden am 2026-04-17 fehlende Unit-Tests fuer die Waehrungslogik nachgezogen:
|
|
|
|
- `CurrencyExchangeRateServiceTests`
|
|
- `ExchangeRateImportServiceTests`
|
|
- Erweiterungen in
|
|
- `TransformationStrategiesTests`
|
|
- `RecordTransformationServiceTests`
|
|
- `TransformationCatalogTests`
|
|
|
|
Aktueller Teststatus nach diesem Nachtrag:
|
|
|
|
```text
|
|
dotnet test .\TrafagSalesExporter.Tests\TrafagSalesExporter.Tests.csproj --verbosity minimal
|
|
```
|
|
|
|
Ergebnis:
|
|
|
|
- erfolgreich
|
|
- `31/31` Tests gruen
|
|
- bekannte Warnung bleibt:
|
|
- SAP HANA Architekturwarnung `MSB3270`
|
|
|
|
## Architekturpruefung 2026-04-17
|
|
|
|
Es wurde eine erneute Gesamtpruefung der Architektur gemacht, ausdruecklich ohne neue Implementierung.
|
|
|
|
### Gesamturteil
|
|
|
|
Die Grundrichtung ist weiterhin sinnvoll:
|
|
|
|
- klare Trennung der Quellsysteme `SAP`, `BI1`, `SAGE`, `MANUAL_EXCEL`
|
|
- zentrales fachliches Zielschema ueber `SalesRecord`
|
|
- zentrale technische Ablage ueber `CentralSalesRecords`
|
|
- separater Orchestrator fuer Standort- und Konsolidierungsexport
|
|
- Transformationssystem als eigener Layer
|
|
|
|
Aber:
|
|
|
|
- die Architektur ist **noch nicht stabil genug**, um sie als "fertig sauber" zu betrachten
|
|
- die groessten Risiken liegen aktuell nicht in SAP oder Waehrungen, sondern in
|
|
- Start-/Schema-Initialisierung
|
|
- Config-Import
|
|
- Verteilung von Logik zwischen Razor-Seiten und Services
|
|
|
|
### Wichtigste Architektur-Risiken
|
|
|
|
#### 1. Start-/Schema-Initialisierung ist fragil
|
|
|
|
`DatabaseInitializationService` mischt derzeit:
|
|
|
|
- `EnsureCreated`
|
|
- manuelle `ALTER TABLE`-Pflege
|
|
- FK-Reparaturlogik
|
|
- Seeding
|
|
- empfohlenes Regel-Seeding
|
|
|
|
Das ist funktional hilfreich, aber architektonisch gefaehrlich, weil:
|
|
|
|
- die App-Initialisierung dadurch viel implizite Datenmigration enthaelt
|
|
- Verhalten schwer vorhersehbar wird
|
|
- Fehler im Migrationspfad sofort produktive Daten treffen
|
|
|
|
Wichtiger konkreter Befund aus der Pruefung:
|
|
|
|
- beim Kopieren von `Sites_old` nach `Sites` ist die Spaltenreihenfolge im SQL inkonsistent
|
|
- dadurch koennen Werte wie `ManualImportFilePath`, `SapServiceUrl`, `SapEntitySet` verschoben gespeichert werden
|
|
- das ist eine reale Datenkorruptionsgefahr und kein reines Architekturthema
|
|
|
|
### 2. Config-Import ist destruktiv und nicht atomar
|
|
|
|
`ConfigTransferService.ImportJsonAsync` loescht aktuell zuerst grosse Teile der Konfiguration und Daten:
|
|
|
|
- Sites
|
|
- HanaServers
|
|
- Transformation Rules
|
|
- SAP-Konfiguration
|
|
- Wechselkurse
|
|
- sogar `CentralSalesRecords`
|
|
|
|
und baut danach mit mehreren `SaveChangesAsync()`-Zwischenschritten neu auf.
|
|
|
|
Risiko:
|
|
|
|
- wenn der Import in der Mitte scheitert, bleibt das System teilweise geloescht zurueck
|
|
- `CentralSalesRecords` gehoeren fachlich ohnehin nicht sauber in einen normalen Config-Import
|
|
|
|
### 3. Zu viel Fach- und Persistenzlogik in Razor-Seiten
|
|
|
|
`Settings.razor` und `Standorte.razor` machen aktuell sehr viel direkt:
|
|
|
|
- `DbContext` oeffnen
|
|
- Daten laden und speichern
|
|
- Konfigurationsimport/-export anstossen
|
|
- SAP-Refresh
|
|
- Upload-Handling
|
|
- Teile der Validierung / Persistenzlogik
|
|
|
|
Das funktioniert momentan, fuehrt aber langfristig zu:
|
|
|
|
- schwer testbarer UI-Logik
|
|
- verstreuten Regeln
|
|
- hoeherem Seiteneffekt-Risiko bei Erweiterungen
|
|
|
|
### 4. Vertrag zwischen Orchestrator und konsolidiertem Export ist unscharf
|
|
|
|
`ExportOrchestrationService` sammelt bei `ExportAllAsync` bereits `consolidatedRecords`, uebergibt sie weiter, aber `ConsolidatedExportService` ignoriert diesen Parameter und liest erneut aus `CentralSalesRecords`.
|
|
|
|
Das zeigt ein offenes Architekturthema:
|
|
|
|
- Soll die zentrale Datei aus dem Live-Exportlauf gebaut werden?
|
|
- oder immer nur aus dem persistenten Read Model `CentralSalesRecords`?
|
|
|
|
Aktuell ist beides halb vorhanden.
|
|
|
|
### 5. Reporting-/Cockpit-Logik ist noch nicht voll verallgemeinert
|
|
|
|
Bei der Pruefung wurde gesehen:
|
|
|
|
- `ManagementCockpitService` enthaelt noch hartcodierte Jahreslogik fuer `2025` und `2026`
|
|
- die Rohsicht bleibt bewusst ohne CHF-Umrechnung
|
|
|
|
Das ist fuer den aktuellen Stand akzeptabel, zeigt aber:
|
|
|
|
- Reporting ist noch kein voll abstrahierter fachlicher Layer
|
|
|
|
## Empfohlenes Sollbild
|
|
|
|
Die naechste Architektur-Stufe sollte in diese Richtung gehen:
|
|
|
|
### 1. Klare Schichten
|
|
|
|
- UI:
|
|
- Razor nur fuer Interaktion, Anzeige, Formularzustand
|
|
- Application:
|
|
- Use Cases / Commands / Queries fuer Export, Config, SAP-Refresh, Wechselkurse, Standortpflege
|
|
- Domain / Fachlogik:
|
|
- Transformationen, Mappingregeln, Waehrungsumrechnung, Cockpit-Berechnungen
|
|
- Infrastructure:
|
|
- HANA, SAP Gateway, SQLite, SharePoint, Dateisystem
|
|
|
|
### 2. Versionierte Migrationen statt manueller Start-Reparaturen
|
|
|
|
Statt immer mehr Reparaturlogik beim App-Start:
|
|
|
|
- Schema-Aenderungen versionieren
|
|
- Migrationspfade testbar machen
|
|
- Startlogik nur noch fuer minimale Bootstrap-Aufgaben behalten
|
|
|
|
### 3. Config-Import als atomarer Vorgang
|
|
|
|
Ziel:
|
|
|
|
- alles in einer Transaktion oder bewusst in klar getrennten Phasen
|
|
- kein halb geloeschter Zustand bei Fehlern
|
|
- `CentralSalesRecords` aus normalem Config-Import eher herausnehmen
|
|
|
|
### 4. Zentrale Export-Semantik entscheiden
|
|
|
|
Explizit festlegen:
|
|
|
|
- zentrale Datei immer aus `CentralSalesRecords`
|
|
oder
|
|
- zentrale Datei aus dem aktuellen Export-Snapshot
|
|
|
|
Danach die doppelte Semantik entfernen.
|
|
|
|
## Priorisierung aus Architektursicht
|
|
|
|
Wenn nach Stabilitaet priorisiert wird, dann in dieser Reihenfolge:
|
|
|
|
1. `DatabaseInitializationService` / Migrationspfad absichern
|
|
2. `ConfigTransferService.ImportJsonAsync` atomar und weniger destruktiv machen
|
|
3. Logik aus `Settings.razor` und `Standorte.razor` in Anwendungsservices verschieben
|
|
4. Export-Semantik fuer Konsolidierung vereinheitlichen
|
|
5. erst danach weitere Fachfeatures wie Cockpit-CHF, Budget, Gruppenlogik
|
|
|
|
## Kurzfazit
|
|
|
|
Die Architektur ist nicht schlecht. Das Grundmodell traegt.
|
|
|
|
Aber:
|
|
|
|
- sie ist noch nicht robust genug fuer ruhigen weiteren Ausbau ohne technische Konsolidierung
|
|
- die aktuelle Hauptgefahr liegt in Infrastruktur- und Persistenzlogik, nicht in den Fachfeatures
|
|
|
|
Fuer den naechsten Einstieg nach Absturz gilt daher:
|
|
|
|
1. zuerst diesen Architektur-Nachtrag lesen
|
|
2. dann `DatabaseInitializationService` und `ConfigTransferService` als Risikobloecke ansehen
|
|
3. neue Fachfeatures erst nach dieser technischen Konsolidierung beginnen
|
|
|
|
## Nachtrag HANA-/Standort-Workflow 2026-04-17
|
|
|
|
Nach der Architekturpruefung wurde der doppelte HANA-Workflow bereinigt.
|
|
|
|
### Altes Problem
|
|
|
|
Vorher gab es zwei konkurrierende Stellen fuer HANA-Konfiguration:
|
|
|
|
- oben eine eigene `HANA Server`-Verwaltung
|
|
- unten im Standortdialog noch einmal eine fast vollstaendige HANA-Verbindung
|
|
|
|
Dadurch war unklar:
|
|
|
|
- was die zentrale Wahrheit ist
|
|
- wann ein zentraler Server geaendert wird
|
|
- wann still ein separater Server pro Standort entsteht
|
|
|
|
### Neue Logik
|
|
|
|
Oben gilt jetzt:
|
|
|
|
- `HANA Server` ist zentrale HANA-Konfiguration pro Quellsystem
|
|
- aktuell relevant fuer:
|
|
- `BI1`
|
|
- `SAGE`
|
|
|
|
Unten im Standort gilt jetzt:
|
|
|
|
- Standort pflegt nur noch standortspezifische Daten
|
|
- `Schema`
|
|
- `TSC`
|
|
- `Land`
|
|
- `SourceSystem`
|
|
- optionale Username-/Password-Overrides
|
|
- die technische HANA-Verbindung kommt aus der zentralen Konfiguration des Quellsystems
|
|
|
|
### Technische Umsetzung
|
|
|
|
- `HanaServer` hat jetzt zusaetzlich `SourceSystem`
|
|
- `DatabaseInitializationService` stellt zentrale Eintraege fuer `BI1` und `SAGE` sicher
|
|
- bestehende verknuepfte HANA-Server werden dabei moeglichst auf `BI1` / `SAGE` gemappt
|
|
- `SiteExportService` baut HANA-Verbindungen jetzt aus der zentralen HANA-Konfiguration des Quellsystems
|
|
- `Settings.razor` testet BI1/SAGE nicht mehr ueber einen Beispiel-Standort, sondern ueber die zentrale HANA-Konfiguration
|
|
- `Standorte.razor` speichert im Standort fuer HANA-basierte Systeme keine eigene Vollverbindung mehr
|
|
|
|
### Wichtige Konsequenz
|
|
|
|
Fachlich gilt jetzt:
|
|
|
|
- oben = Standardkonfiguration pro Quellsystem
|
|
- unten = Standort + optionale Credential-Overrides
|
|
|
|
Das entspricht der gewuenschten Logik:
|
|
|
|
- gleiche BI1-/SAGE-Standorte koennen zentrale Verbindungswerte teilen
|
|
- Ausnahmen koennen weiter ueber Username-/Password-Overrides reagieren
|
|
|
|
### UI-Nachtrag
|
|
|
|
Die frueher doppelte und dadurch verwirrende UI wurde danach auch sichtbar bereinigt.
|
|
|
|
Aktueller UI-Stand:
|
|
|
|
- oben heisst der Bereich jetzt klar `Zentrale HANA-Konfiguration`
|
|
- im Standortdialog gibt es fuer HANA keine zweite technische Eingabestrecke mehr
|
|
- dort wird nur noch die aktive Zentralverbindung angezeigt
|
|
- Host, Port, SSL und technische Parameter werden explizit nach oben verwiesen
|
|
- der zentrale Verbindungstest in `Settings.razor` meldet jetzt sauber die zentrale HANA-Verbindung
|
|
|
|
## Nachtrag Quellsystem-Verwaltung 2026-04-17
|
|
|
|
Die bisher noch hart codierten Quellsystem-Listen wurden entfernt und durch echte Stammdaten ersetzt.
|
|
|
|
### Neuer Stand
|
|
|
|
- neues Modell `SourceSystemDefinition`
|
|
- Quellsysteme werden jetzt zentral in der DB gehalten statt in Razor-Arrays
|
|
- pro Quellsystem werden gepflegt:
|
|
- `Code`
|
|
- `DisplayName`
|
|
- `ConnectionKind`
|
|
- `IsActive`
|
|
- `CentralUsername`
|
|
- `CentralPassword`
|
|
|
|
### Neue GUI-Logik
|
|
|
|
- `Settings.razor` enthaelt jetzt eine pflegbare Quellsystem-Tabelle
|
|
- dort koennen Quellsysteme per GUI angelegt, bearbeitet und gespeichert werden
|
|
- Anschlussart ist nicht mehr implizit im Code, sondern pro Quellsystem konfigurierbar
|
|
- zentrale Zugangsdaten haengen jetzt am Quellsystem selbst
|
|
|
|
### Anschlussarten
|
|
|
|
Aktuell technisch vorgesehen:
|
|
|
|
- `HANA`
|
|
- `SAP_GATEWAY`
|
|
- `MANUAL_EXCEL`
|
|
|
|
Damit gilt:
|
|
|
|
- HANA-Konfiguration oben in `Standorte.razor` nur noch fuer Quellsysteme mit Anschlussart `HANA`
|
|
- Standort-Dropdown zieht seine Quellsysteme jetzt aus `SourceSystemDefinitions`
|
|
- Transformationsregeln ziehen ihre Quellsystem-Auswahl ebenfalls aus `SourceSystemDefinitions`
|
|
|
|
### Technische Umsetzung
|
|
|
|
- `AppDbContext` hat jetzt `DbSet<SourceSystemDefinition>`
|
|
- `DatabaseInitializationService` erzeugt und seedet `SourceSystemDefinitions`
|
|
- `SiteExportService` loest zentrale Credentials jetzt ueber `SourceSystemDefinition`
|
|
- `ConfigTransferService` exportiert/importiert jetzt auch `SourceSystemDefinitions`
|
|
|
|
### Verifikation
|
|
|
|
Nach dieser Umstellung geprueft:
|
|
|
|
```text
|
|
dotnet build .\TrafagSalesExporter.csproj -v minimal
|
|
dotnet test .\TrafagSalesExporter.Tests\TrafagSalesExporter.Tests.csproj --verbosity minimal
|
|
```
|
|
|
|
Ergebnis:
|
|
|
|
- Build erfolgreich
|
|
- Tests erfolgreich
|
|
- `31/31` Tests gruen
|
|
|
|
### Bereinigung der Legacy-Credentials
|
|
|
|
Danach wurden auch die alten zentralen Credential-Felder technisch bereinigt.
|
|
|
|
Aktueller Stand:
|
|
|
|
- `ExportSettings` enthaelt keine alten Felder mehr fuer `SapUsername`, `Bi1Username`, `SageUsername` usw.
|
|
- der Config-Export schreibt zentrale Zugangsdaten nur noch ueber `SourceSystemDefinitions`
|
|
- `ConfigTransferService` hat keinen aktiven Legacy-Credential-Pfad mehr
|
|
- die fruehere Temp-Datei `standorte_numbered.tmp` wurde entfernt
|
|
|
|
Wichtig:
|
|
|
|
- bestehende DB-Spalten koennen physisch noch vorhanden sein, sind aber kein aktiver Codepfad mehr
|
|
- fuehrende Wahrheit fuer zentrale Zugangsdaten ist jetzt ausschliesslich `SourceSystemDefinition`
|
|
|
|
### Schema-Bereinigung
|
|
|
|
Danach wurde auch die SQLite-Schemabereinigung nachgezogen.
|
|
|
|
Aktueller Stand:
|
|
|
|
- `DatabaseInitializationService` erkennt alte Credential-Spalten in `ExportSettings`
|
|
- wenn diese Legacy-Spalten noch existieren, wird `ExportSettings` beim Start auf das neue Schema rekonstruiert
|
|
- erhalten bleiben nur die noch gueltigen Felder:
|
|
- `DateFilter`
|
|
- `TimerHour`
|
|
- `TimerMinute`
|
|
- `TimerEnabled`
|
|
- `DebugLoggingEnabled`
|
|
- `LocalSiteExportFolder`
|
|
- `LocalConsolidatedExportFolder`
|
|
|
|
Damit gilt jetzt:
|
|
|
|
- alte zentrale SAP/BI1/SAGE-Credentials sind nicht nur logisch entfernt
|
|
- sie werden bei bestehender DB auch aktiv aus dem `ExportSettings`-Schema entfernt
|
|
|
|
### Letzte Bereinigung HANA-Credentials
|
|
|
|
Danach wurde auch die letzte doppelte Credential-Stelle in der HANA-Verwaltung entfernt.
|
|
|
|
Aktueller Stand:
|
|
|
|
- zentrale HANA-Konfiguration speichert nur noch technische Verbindungsdaten
|
|
- `Host`
|
|
- `Port`
|
|
- `DatabaseName`
|
|
- `UseSsl`
|
|
- `ValidateCertificate`
|
|
- `AdditionalParams`
|
|
- Username/Password werden nicht mehr in der zentralen HANA-UI gepflegt
|
|
- HANA-Verbindungstests in `Standorte.razor` verwenden jetzt die zentralen Credentials aus `SourceSystemDefinition`
|
|
- `SiteExportService` faellt bei HANA nicht mehr auf in `HanaServer` gespeicherte Credentials zurueck
|
|
- `ConfigTransferService` exportiert/importiert fuer `HanaServer` keine Username-/Password-Werte mehr
|
|
- `DatabaseInitializationService` bereinigt bei bestehender DB auch das `HanaServers`-Schema und entfernt die Altspalten `Username` / `Password`
|
|
|
|
Die fachliche Reihenfolge ist jetzt eindeutig:
|
|
|
|
1. zentrale Credentials aus `SourceSystemDefinition`
|
|
2. optionale Override-Credentials am `Site`
|
|
3. technische HANA-Verbindung aus der zentralen HANA-Konfiguration
|
|
|
|
### EF-/SQLite-Fix
|
|
|
|
Beim ersten Lauf nach der Schema-Bereinigung trat noch ein Mapping-Fehler auf:
|
|
|
|
- `SQLite Error 1: 'no such column: h.Password'`
|
|
|
|
Ursache:
|
|
|
|
- `HanaServers`-Schema war bereits ohne `Username` / `Password`
|
|
- das EF-Modell `HanaServer` hat diese Properties aber noch als normale Spalten behandelt
|
|
|
|
Fix:
|
|
|
|
- `HanaServer.Username` und `HanaServer.Password` sind jetzt `[NotMapped]`
|
|
- damit bleiben sie fuer Laufzeit-Verbindungsaufbau und Tests nutzbar
|
|
- EF erwartet sie aber nicht mehr als Datenbankspalten
|
|
|
|
## Nachtrag Zentrale SAP-Steuerung 2026-04-17
|
|
|
|
Der verbleibende Architekturbruch bei SAP wurde ebenfalls bereinigt.
|
|
|
|
### Neuer Stand
|
|
|
|
- `SourceSystemDefinition` enthaelt jetzt auch `CentralServiceUrl`
|
|
- zentrale SAP-Service-URL wird damit am Quellsystem gepflegt, nicht mehr primaer am Standort
|
|
- `Standorte.razor` behandelt `SapServiceUrl` jetzt als Override
|
|
- wenn kein Override gesetzt ist, zieht SAP die URL zentral aus dem Quellsystem
|
|
|
|
### UI
|
|
|
|
- `Settings.razor` hat fuer Quellsysteme jetzt eine Dialogbearbeitung statt nur Inline-Tabellenfelder
|
|
- dadurch ist das Quellsystem sauber editierbar
|
|
- fuer `SAP_GATEWAY` wird dort die zentrale SAP-Service-URL gepflegt
|
|
- `Standorte.razor` zeigt bei SAP jetzt:
|
|
- zentrale SAP Service URL
|
|
- optionales `SAP Service URL Override`
|
|
|
|
### Laufzeitlogik
|
|
|
|
- `SiteExportService` verwendet bei SAP die effektive URL aus
|
|
- Standort-Override
|
|
- sonst `SourceSystemDefinition.CentralServiceUrl`
|
|
- SAP-Verbindungstest in `Settings.razor` testet die zentrale URL direkt aus dem Quellsystem
|
|
- Dashboard zeigt fuer SAP jetzt ebenfalls die effektive zentrale bzw. ueberschriebene URL
|
|
|
|
### Verifikation
|
|
|
|
Nach der Umstellung geprueft:
|
|
|
|
```text
|
|
dotnet build .\TrafagSalesExporter.csproj -v minimal
|
|
dotnet test .\TrafagSalesExporter.Tests\TrafagSalesExporter.Tests.csproj --verbosity minimal
|
|
```
|
|
|
|
Ergebnis:
|
|
|
|
- Build erfolgreich
|
|
- Tests erfolgreich
|
|
- `31/31` Tests gruen
|
|
|
|
## Nachtrag 2026-04-16
|
|
|
|
Seit dem letzten Handoff wurden weitere Funktionen umgesetzt, die unten im alten Stand noch nicht voll enthalten sind.
|
|
|
|
## Zielbild
|
|
|
|
Die App wurde von einem reinen BI1/HANA-Exporter zu einer kombinierten Plattform erweitert:
|
|
|
|
- `BI1` und `SAGE` bleiben auf direktem HANA-Zugriff
|
|
- `SAP` laeuft separat ueber SAP Gateway / OData
|
|
- SAP-Quellen koennen gelesen, gejoint und auf das zentrale `SalesRecord`-Schema gemappt werden
|
|
- Standort-Exporte werden lokal als Excel geschrieben
|
|
- zusaetzlich werden Datensaetze in eine zentrale SQLite-Tabelle geschrieben
|
|
- ein konsolidierter Export liest aus dieser zentralen Tabelle
|
|
|
|
## Wichtigste umgesetzte Funktionen
|
|
|
|
### 1. Zentrale Credentials pro Quellsystem
|
|
|
|
Es gibt zentrale Zugangsdaten in `ExportSettings` fuer:
|
|
|
|
- `SAP`
|
|
- `BI1`
|
|
- `SAGE`
|
|
|
|
Zusaetzlich gibt es pro Standort optionale Overrides:
|
|
|
|
- `UsernameOverride`
|
|
- `PasswordOverride`
|
|
|
|
Aufloesungsreihenfolge:
|
|
|
|
1. Standort-Override
|
|
2. zentrale Credentials des Quellsystems
|
|
3. bei HANA zusaetzlich Fallback auf alten `HanaServer.Username/Password`
|
|
|
|
### 2. SAP von BI1/HANA getrennt
|
|
|
|
`SAP` nutzt nicht mehr den HANA-Pfad, sondern eine eigene Gateway/OData-Strecke.
|
|
|
|
Pro SAP-Standort gibt es:
|
|
|
|
- `SapServiceUrl`
|
|
- `SapEntitySet`
|
|
- `SapEntitySetsCache`
|
|
- `SapEntitySetsRefreshedAtUtc`
|
|
|
|
Refresh der SAP-Quellen erfolgt nur auf Knopfdruck.
|
|
|
|
Beispiel Service URL:
|
|
|
|
```text
|
|
http://travt762.sap.trafag.com:8000/sap/opu/odata/sap/ZPOWERBI_EINKAUF_SRV/
|
|
```
|
|
|
|
Wichtig:
|
|
|
|
- Service URL immer nur bis zum Service
|
|
- Entity Set separat auswaehlen
|
|
|
|
### 3. SAP-Quellen, Joins und Feldmappings
|
|
|
|
Fuer SAP gibt es mehrere neue Modelle:
|
|
|
|
- `SapSourceDefinition`
|
|
- `SapJoinDefinition`
|
|
- `SapFieldMapping`
|
|
|
|
Unterstuetzt wird:
|
|
|
|
- mehrere SAP-Quellen pro Standort
|
|
- Alias pro Quelle
|
|
- Primaerquelle
|
|
- Join-Definitionen
|
|
- Mapping von `Alias.Feldname` auf zentrales Schema
|
|
|
|
UI-Erweiterungen:
|
|
|
|
- `Quellen refreshen`
|
|
- `Felder aus Quellen laden`
|
|
- Join-Key-Auswahl aus Metadaten
|
|
- `Auto-Match` fuer gleiche Feldnamen zwischen Primaerquelle und anderen Quellen
|
|
|
|
### 4. Zentrale Datenspeicherung
|
|
|
|
Neue Tabelle:
|
|
|
|
- `CentralSalesRecords`
|
|
|
|
Verwendung:
|
|
|
|
- pro Standort werden alte zentrale Saetze dieses Standorts ersetzt
|
|
- konsolidierte Excel liest aus `CentralSalesRecords`
|
|
|
|
Wichtig:
|
|
|
|
- zentrale Excel wird nicht appendet
|
|
- sie wird aus dem aktuellen Zustand der zentralen Tabelle neu erstellt
|
|
|
|
### 5. Exportpfade
|
|
|
|
Neue Konfigurationsmoeglichkeiten:
|
|
|
|
Zentral in `Settings`:
|
|
|
|
- `LocalSiteExportFolder`
|
|
- `LocalConsolidatedExportFolder`
|
|
|
|
Pro Standort:
|
|
|
|
- `LocalExportFolderOverride`
|
|
|
|
Fallback wenn leer:
|
|
|
|
```text
|
|
./output
|
|
```
|
|
|
|
relativ zum App-Verzeichnis.
|
|
|
|
### 6. SharePoint
|
|
|
|
SharePoint-Upload ist optional.
|
|
|
|
Wenn keine vollstaendige SharePoint-Konfiguration vorhanden ist:
|
|
|
|
- Excel wird trotzdem lokal erzeugt
|
|
- kein Upload nach SharePoint
|
|
|
|
Benoetigte SharePoint-Werte:
|
|
|
|
- `Tenant ID`
|
|
- `Client ID`
|
|
- `Client Secret`
|
|
|
|
Das sind Entra App Registration Werte, nicht normale Benutzer-Credentials.
|
|
|
|
### 7. Config Import/Export
|
|
|
|
Es gibt JSON-Import/Export der Konfiguration mit Checkbox:
|
|
|
|
- mit Secrets
|
|
- ohne Secrets
|
|
|
|
Enthalten sind u. a.:
|
|
|
|
- SharePoint Config
|
|
- ExportSettings
|
|
- HanaServers
|
|
- Sites
|
|
- Transformation Rules
|
|
- SAP-Quellen
|
|
- SAP-Joins
|
|
- SAP-Mappings
|
|
|
|
### 8. Logging und Live-Status
|
|
|
|
Neue technische Logs ueber `AppEventLogs`.
|
|
|
|
Sichtbar:
|
|
|
|
- auf `/logs`
|
|
- im Dashboard als `Live-Status`
|
|
|
|
Geloggt werden u. a.:
|
|
|
|
- HANA-Query Start
|
|
- SAP Refresh
|
|
- SAP Reads
|
|
- Transformationen
|
|
- Excel-Erstellung
|
|
- zentrale Tabellenspeicherung
|
|
- Export erfolgreich / fehlgeschlagen
|
|
|
|
### 9. Excel oeffnen
|
|
|
|
Im Dashboard gibt es neben `Export` den Button:
|
|
|
|
- `Excel oeffnen`
|
|
|
|
Dieser nutzt `ExportLogs.FilePath`.
|
|
|
|
Voraussetzungen:
|
|
|
|
- letzter Export erfolgreich
|
|
- `FilePath` gespeichert
|
|
- Datei existiert lokal
|
|
|
|
### 10. Management Cockpit
|
|
|
|
Es gibt einen neuen Menuepunkt:
|
|
|
|
- `Management Cockpit`
|
|
|
|
Funktion:
|
|
|
|
- Auswahl vorhandener Excel-Dateien
|
|
- Analyse einer exportierten Standort-Datei
|
|
- Kennzahlen fuer Geschaeftsinhaber / Management
|
|
|
|
Aktuell enthalten:
|
|
|
|
- Umsatz
|
|
- geschaetzte Kosten
|
|
- geschaetzte Marge
|
|
- Rechnungsanzahl
|
|
- Kundenanzahl
|
|
- Top Kunden
|
|
- Top Produktgruppen
|
|
- Top Sales Owner
|
|
- Datenqualitaetshinweise
|
|
- automatische Management-Aussagen
|
|
|
|
### 11. Manueller Excel-Import pro Standort
|
|
|
|
Es gibt jetzt einen vierten `SourceSystem`-Typ:
|
|
|
|
- `MANUAL_EXCEL`
|
|
|
|
Gedanke:
|
|
|
|
- Standort ohne Netz-/Systemanbindung liefert nur Excel
|
|
- Datei wird im Standort hochgeladen
|
|
- Export liest diese Datei statt SAP/HANA
|
|
- Daten werden in `CentralSalesRecords` fuer diesen Standort ersetzt
|
|
- der zentrale Export liest weiter nur aus `CentralSalesRecords`
|
|
|
|
Neue Site-Felder:
|
|
|
|
- `ManualImportFilePath`
|
|
- `ManualImportLastUploadedAtUtc`
|
|
|
|
Wichtig:
|
|
|
|
- das ist kein Excel-zu-Excel-Merge
|
|
- die App importiert ins zentrale Schema und erzeugt danach die zentrale Datei neu
|
|
|
|
### 12. Dashboard erweitert
|
|
|
|
Im Dashboard gibt es jetzt zusaetzlich:
|
|
|
|
- separaten Bereich `Zentrale Datei`
|
|
- `Excel oeffnen` fuer die neueste zentrale Datei `Sales_All_*.xlsx`
|
|
- Button `Alle exportieren`
|
|
- Button `Zentrale Datei neu erzeugen`
|
|
|
|
Bedeutung:
|
|
|
|
- `Alle exportieren` liest alle Quellen neu und erzeugt danach die zentrale Datei
|
|
- `Zentrale Datei neu erzeugen` schreibt nur aus `CentralSalesRecords` eine neue zentrale Excel
|
|
|
|
### 13. Management Cockpit Roh-Auswertung aus Zentraldaten
|
|
|
|
Zusaetzlich zur dateibasierten Cockpit-Analyse gibt es jetzt eine Roh-Auswertung direkt aus `CentralSalesRecords`.
|
|
|
|
Aktuell umgesetzt:
|
|
|
|
- Auswahl Jahr
|
|
- optional Auswahl Monat
|
|
- Jahresumsatz
|
|
- Monatsumsatz
|
|
- Tagesumsatz im gewaehlten Monat
|
|
- Umsatz nach Quelle
|
|
- Umsatz nach Land
|
|
- Periodenabdeckung / Zeilen / Rechnungen / Standorte / Laender / Waehrungen
|
|
|
|
Bewusst noch nicht enthalten:
|
|
|
|
- kein Intercompany-Filter
|
|
- keine CHF-Umrechnung
|
|
- kein Budgetvergleich
|
|
- keine Spartenlogik
|
|
- keine Gruppenlogik
|
|
- keine Margenlogik
|
|
|
|
### 14. Transformationssystem erweitert
|
|
|
|
Das Transformationssystem kann jetzt zwei Ebenen:
|
|
|
|
- `Value` fuer einfache feldweise Regeln aus der GUI
|
|
- `Record` fuer komplexere C#-Strategien per Strategy Pattern
|
|
|
|
Umgesetzt:
|
|
|
|
- neues Feld `RuleScope` auf `FieldTransformationRule`
|
|
- dynamischer Strategiekatalog
|
|
- GUI liest verfuegbare Typen aus dem Katalog
|
|
- erste `Record`-Strategie: `FirstNonEmpty`
|
|
|
|
Beispiel:
|
|
|
|
- `TargetField = CustomerName`
|
|
- `TransformationType = FirstNonEmpty`
|
|
- `Argument = CustomerName|SupplierName|Name`
|
|
|
|
### 15. Schema-Lookup fuer HANA-Standorte
|
|
|
|
Im Standortdialog fuer HANA-basierte Standorte gibt es jetzt:
|
|
|
|
- Button `Schemas laden`
|
|
- Lookup mit gueltigen Schemas aus HANA
|
|
|
|
Die Liste wird nicht blind aus allen Schemas gelesen, sondern auf typische B1-Schemas eingeschraenkt, in denen z. B. Tabellen wie
|
|
|
|
- `OINV`
|
|
- `INV1`
|
|
- `ORIN`
|
|
- `RIN1`
|
|
- `OCRD`
|
|
- `OITM`
|
|
|
|
vorhanden sind.
|
|
|
|
Wichtig:
|
|
|
|
- manuelle Eingabe bleibt moeglich
|
|
- fuer `BI1` und `SAGE` werden beim Lookup die effektiven Credentials inkl. zentraler Zugangsdaten / Overrides verwendet
|
|
- das reduziert Fehler wie `invalid schema name`
|
|
|
|
### 16. Testabdeckung ausgebaut
|
|
|
|
Es gibt jetzt ein separates Testprojekt:
|
|
|
|
- `TrafagSalesExporter.Tests`
|
|
|
|
Automatisiert getestet werden aktuell:
|
|
|
|
- Transformationsstrategien
|
|
- `RecordTransformationService`
|
|
- `TransformationCatalog`
|
|
- `ManualExcelImportService`
|
|
- `ManagementCockpitService`
|
|
- `ConfigTransferService`
|
|
|
|
Wichtiger bereits gefundener Bug:
|
|
|
|
- deutsches Dezimalformat wie `1,50` wurde im manuellen Excel-Import falsch interpretiert
|
|
- Parsing wurde korrigiert
|
|
|
|
## Wichtige Dateien
|
|
|
|
### Modelle
|
|
|
|
- `Models/Site.cs`
|
|
- `Models/ExportSettings.cs`
|
|
- `Models/ExportLog.cs`
|
|
- `Models/CentralSalesRecord.cs`
|
|
- `Models/SapSourceDefinition.cs`
|
|
- `Models/SapJoinDefinition.cs`
|
|
- `Models/SapFieldMapping.cs`
|
|
- `Models/ManagementCockpitModels.cs`
|
|
- `Models/ConfigTransferPackage.cs`
|
|
- `Models/FieldTransformationRule.cs`
|
|
|
|
### Services
|
|
|
|
- `Services/SiteExportService.cs`
|
|
- `Services/ConsolidatedExportService.cs`
|
|
- `Services/CentralSalesRecordService.cs`
|
|
- `Services/SapGatewayService.cs`
|
|
- `Services/SapCompositionService.cs`
|
|
- `Services/ConfigTransferService.cs`
|
|
- `Services/AppEventLogService.cs`
|
|
- `Services/ManagementCockpitService.cs`
|
|
- `Services/DatabaseInitializationService.cs`
|
|
- `Services/ExportOrchestrationService.cs`
|
|
- `Services/ManualExcelImportService.cs`
|
|
- `Services/TransformationCatalog.cs`
|
|
- `Services/RecordTransformationService.cs`
|
|
- `Services/TransformationStrategies.cs`
|
|
|
|
### UI
|
|
|
|
- `Components/Pages/Standorte.razor`
|
|
- `Components/Pages/Settings.razor`
|
|
- `Components/Pages/Dashboard.razor`
|
|
- `Components/Pages/Logs.razor`
|
|
- `Components/Pages/ManagementCockpit.razor`
|
|
- `Components/Pages/Transformations.razor`
|
|
- `Components/Layout/NavMenu.razor`
|
|
|
|
### Tests
|
|
|
|
- `TrafagSalesExporter.Tests/TransformationStrategiesTests.cs`
|
|
- `TrafagSalesExporter.Tests/RecordTransformationServiceTests.cs`
|
|
- `TrafagSalesExporter.Tests/TransformationCatalogTests.cs`
|
|
- `TrafagSalesExporter.Tests/ManualExcelImportServiceTests.cs`
|
|
- `TrafagSalesExporter.Tests/ManagementCockpitServiceTests.cs`
|
|
- `TrafagSalesExporter.Tests/ConfigTransferServiceTests.cs`
|
|
|
|
## Datenbank / Migrationen
|
|
|
|
Viele Aenderungen laufen ueber `DatabaseInitializationService`.
|
|
|
|
Wichtige neue oder erweiterte Tabellen/Felder:
|
|
|
|
- `Sites`
|
|
- `UsernameOverride`
|
|
- `PasswordOverride`
|
|
- `SapServiceUrl`
|
|
- `SapEntitySet`
|
|
- `SapEntitySetsCache`
|
|
- `SapEntitySetsRefreshedAtUtc`
|
|
- `LocalExportFolderOverride`
|
|
- `ManualImportFilePath`
|
|
- `ManualImportLastUploadedAtUtc`
|
|
- `ExportSettings`
|
|
- zentrale SAP/BI1/SAGE Credentials
|
|
- `LocalSiteExportFolder`
|
|
- `LocalConsolidatedExportFolder`
|
|
- `DebugLoggingEnabled`
|
|
- `FieldTransformationRules`
|
|
- `RuleScope`
|
|
- `ExportLogs`
|
|
- `FilePath`
|
|
- neue Tabellen:
|
|
- `AppEventLogs`
|
|
- `CentralSalesRecords`
|
|
- SAP-Konfigtabellen
|
|
|
|
## Letztes Hauptproblem und Loesung
|
|
|
|
### Export hing nach zentraler Speicherung
|
|
|
|
Der Export blieb zuletzt nach
|
|
|
|
- `Zentrale Tabelle: 20106 Datensaetze gespeichert.`
|
|
|
|
haengen.
|
|
|
|
Die eigentliche Ursache war am Ende nicht mehr der Batch-Insert selbst, sondern ein kaputter SQLite-Schemazustand:
|
|
|
|
- mindestens eine Tabelle referenzierte per FK noch `main.Sites_old`
|
|
- dadurch scheiterte `SaveChangesAsync()` spaeter beim Schreiben in `AppEventLogs` oder `ExportLogs`
|
|
- die alte Tabelle `Sites_old` existierte nicht mehr
|
|
|
|
Beobachteter Fehler:
|
|
|
|
- `SQLite Error 1: 'no such table: main.Sites_old'`
|
|
|
|
## Umgesetzte Korrekturen
|
|
|
|
- `Components/Pages/Dashboard.razor`
|
|
- Live-Status pollt waehrend laufendem Export nicht mehr permanent `AppEventLogs`
|
|
- stattdessen Anzeige ueber den In-Memory-Status aus `ExportOrchestrationService`
|
|
- `Program.cs`
|
|
- SQLite `Default Timeout` von `10` auf `60` erhoeht
|
|
- `Services/CentralSalesRecordService.cs`
|
|
- nach abgeschlossenem Batch-Insert wird explizit `Zentrale Tabelle aktualisiert` gesetzt
|
|
- `Services/DatabaseInitializationService.cs`
|
|
- automatische Reparaturlogik fuer Tabellen, deren `CREATE TABLE`-SQL noch `Sites_old` referenziert
|
|
- betroffene Tabellen werden beim Start neu aufgebaut und Daten rueberkopiert
|
|
|
|
Danach wurde der Export erfolgreich getestet und geht jetzt wieder durch.
|
|
|
|
## Was bei einer naechsten Stoerung zuerst zu pruefen ist
|
|
|
|
1. Tritt beim App-Start die Schema-Reparatur sauber durch?
|
|
2. Gibt es noch weitere Tabellen mit FK-Referenz auf `Sites_old`?
|
|
3. Erst danach wieder Insert-/Commit-Batches der zentralen Speicherung untersuchen
|
|
|
|
## Build-Status
|
|
|
|
Letzter Build:
|
|
|
|
```text
|
|
dotnet build TrafagSalesExporter.sln
|
|
```
|
|
|
|
Ergebnis:
|
|
|
|
- erfolgreich
|
|
- bekannte Warnungen bleiben:
|
|
- SAP HANA Architekturwarnung `MSB3270`
|
|
- MudBlazor Analyzer `Dense`
|
|
|
|
## Nachtrag 2026-04-17 UI-Klarstellung HANA vs. SAP
|
|
|
|
- `Components/Pages/Standorte.razor`
|
|
- Bereich oben heisst jetzt bewusst `Zentrale HANA-Technik`
|
|
- Hinweistext stellt klar: dort erscheinen nur Quellsysteme mit Anschlussart `HANA`
|
|
- `SAP` wird zentral unter `Settings -> Quellsysteme` gepflegt und gehoert nicht in diese Box
|
|
- der irrefuehrende Button `Server hinzufuegen` wurde entfernt
|
|
- neue HANA-Zeilen entstehen aus den Quellsystem-Stammdaten, nicht mehr aus einer zweiten UI-Erfassung
|
|
- Dialogtitel fuer HANA wurde auf reine Bearbeitung der zentralen Technik reduziert
|
|
|
|
Fachliche Regel jetzt:
|
|
|
|
- `Quellsysteme` verwalten die zentralen Systeme und deren Anschlussart
|
|
- `Standorte` zeigen fuer HANA nur noch die technische Zentralverbindung
|
|
- `SAP` wird nicht mehr implizit in der HANA-Box erwartet
|
|
|
|
## Nachtrag 2026-04-17 Pruefung Config-Import/Export
|
|
|
|
Der aktuelle Config-Transfer wurde nach den Umbauten nochmals geprueft.
|
|
|
|
Status:
|
|
|
|
- Das aktuelle Import-/Exportformat passt zum neuen Modell.
|
|
- `SourceSystemDefinitions` werden mit `ConnectionKind`, `CentralServiceUrl`, `CentralUsername`, `CentralPassword` importiert/exportiert.
|
|
- `HanaServers` enthalten nur noch technische HANA-Verbindungsdaten und keine Credentials mehr.
|
|
- Standort-Overrides fuer Username/Password sowie SAP Service URL gehen weiterhin mit.
|
|
- Die vorhandenen `ConfigTransferServiceTests` laufen grün.
|
|
|
|
Weiterhin offene Architekturpunkte:
|
|
|
|
- `ConfigTransferService.ImportJsonAsync` ist weiterhin destruktiv und nicht atomar.
|
|
- Erst werden bestehende Daten geloescht, danach wird in mehreren Schritten neu aufgebaut.
|
|
- Wenn der Import in der Mitte scheitert, bleibt ein teilweiser Zustand zurueck.
|
|
- Altformat-Risiko bei `ConnectionKind`:
|
|
- Wenn ein aelteres JSON bereits `SourceSystemDefinitions` enthaelt, aber noch ohne `ConnectionKind`, faellt der DTO-Default auf `HANA`.
|
|
- Dadurch koennte ein altes `SAP` beim Import falsch als `HANA` landen.
|
|
|
|
Fazit:
|
|
|
|
- Fuer Exporte aus dem aktuellen Stand ist der Config-Transfer konsistent.
|
|
- Fuer aeltere JSON-Staende braucht der Import noch eine explizite Migrations-/Fallback-Logik.
|