Add AD auth and B1 currency fields

TrafagSalesExporter/HANDOFF_2026-04-15.md

@@ -2,6 +2,171 @@
 
 Stand: 2026-04-15
 
+## Nachtrag 2026-04-29 B1-Belegwaehrungsfelder aus HANA
+
+Der HANA/B1-Export wurde um Beleg- und Hauswaehrungsfelder erweitert.
+
+Grund:
+
+- `p.StockPrice` muss fachlich in der B1-Hauswaehrung bewertet werden
+- die Hauswaehrung kommt aus `OADM.MainCurncy`
+- bisher wurde `StandardCostCurrency` aus `p.Currency` bzw. `h.DocCur` abgeleitet
+- fuer Power-BI-/Cockpit-Gegenpruefung muessen Belegwaehrung, Hauswaehrung, Netto-/Steuerbetraege und Kurs sichtbar sein
+
+Neue Felder in `SalesRecord` und `CentralSalesRecord`:
+
+- `DocumentCurrency`
+- `DocumentTotalForeignCurrency`
+- `DocumentTotalLocalCurrency`
+- `VatSumForeignCurrency`
+- `VatSumLocalCurrency`
+- `DocumentRate`
+- `CompanyCurrency`
+
+B1-Feldmapping:
+
+- `DocumentCurrency` = `OINV/ORIN.DocCur`
+- `DocumentTotalForeignCurrency` = `OINV/ORIN.DocTotalFC`
+- `DocumentTotalLocalCurrency` = `OINV/ORIN.DocTotal`
+- `VatSumForeignCurrency` = `OINV/ORIN.VatSumFC`
+- `VatSumLocalCurrency` = `OINV/ORIN.VatSum`
+- `DocumentRate` = `OINV/ORIN.DocRate`
+- `CompanyCurrency` = `OADM.MainCurncy`
+- `StandardCostCurrency` = `OADM.MainCurncy`
+
+Technische Umsetzung:
+
+- `HanaQueryService` liest `OADM` jetzt per `CROSS JOIN`
+- Invoice- und Credit-Note-Query liefern die neuen Felder
+- bei Gutschriften werden Dokument- und Steuerbetraege mit negativem Vorzeichen uebernommen
+- `CentralSalesRecords`-Schema wurde erweitert
+- bestehende SQLite-DBs erhalten die neuen Spalten per `DatabaseSchemaMaintenanceService`
+- `CentralSalesRecordService` persistiert und liest die neuen Felder
+- `ExcelExportService` schreibt die neuen Spalten in Standort- und `Sales_All_*.xlsx`-Dateien
+- `ManualExcelImportService` kann die neuen Spalten wieder einlesen
+- `ConfigTransferService` erhaelt die neuen Felder beim Remapping zentraler Laufzeitdaten
+
+Wichtig fuer Power BI:
+
+- die neuen `DocumentTotal*`- und `VatSum*`-Felder sind Belegkopfwerte
+- sie werden in der positionsbasierten Excel pro Positionszeile wiederholt
+- diese Felder duerfen daher nicht blind positionsweise summiert werden
+- fuer Belegkopfsummen in Power BI zuerst nach `DocumentType`, `Invoice Number`, `TSC` und ggf. `Land` deduplizieren
+- positionsbasierte Auswertungen sollen weiterhin mit positionsbezogenen Feldern wie `Sales Price/Value`, `Quantity` oder `Standard cost` arbeiten
+
+Verifikation:
+
+- `dotnet build .\TrafagSalesExporter.csproj --verbosity minimal` erfolgreich
+- `dotnet test .\TrafagSalesExporter.Tests\TrafagSalesExporter.Tests.csproj --verbosity minimal` erfolgreich
+- `48/48` Tests gruen
+- `ManualExcelImportServiceTests` pruefen die neuen Excel-Spalten
+- `CentralSalesRecordServiceTests` pruefen Persistenz und Ruecklesen der neuen B1-Felder
+
+## Nachtrag 2026-04-29 Clean-Code-/DI-Befund
+
+Der aktuelle Code ist DI-orientiert und deutlich besser strukturiert als zu Beginn des Refactorings, aber noch nicht durchgehend ein Clean-Code-Ideal.
+
+Positiv:
+
+- Services werden weitgehend ueber Interfaces und DI verdrahtet
+- `DataSourceAdapter` trennt die Quellsysteme
+- Page-Services reduzieren direkte DB-Logik in mehreren Razor-Seiten
+- `Scoped` fuer UI-nahe Services und `Singleton` fuer gemeinsame Infrastruktur/Orchestrierung ist bewusst gewaehlt
+- Testabdeckung fuer zentrale Fachlogik ist vorhanden und waechst
+
+Weiterhin offene Clean-Code-Risiken:
+
+- `DatabaseInitializationService` ist weiterhin produktiver Reparatur-/Migrationspfad
+- `Settings.razor` und `Standorte.razor` enthalten noch viel Workflow-/UI-Logik
+- `ManagementCockpitService` und `ConfigTransferService` sind breit und sollten spaeter weiter aufgeteilt werden
+- Retry-/Robustheitslayer fuer externe Systeme fehlt
+- Secret-Store fehlt
+- Auth-Rollenmodell ist aktuell pragmatisch, aber noch grob
+
+Bewertung:
+
+- Architektur: brauchbar bis gut
+- DI: grundsaetzlich sauber
+- Clean Code: mittel bis gut, mit klaren Altlasten
+
+Dieser Befund wurde bewusst nur dokumentiert. Die strukturelle Bereinigung wird spaeter priorisiert.
+
+## Nachtrag 2026-04-29 Authentifizierung / AD-Zugriffsschutz
+
+Nach Rueckmeldung der IT wurde ein Zugriffsschutz fuer die Blazor-App eingebaut.
+
+Vorher konnte jeder Benutzer mit Netzwerkzugriff auf die App-URL die Anwendung oeffnen. Das war kritisch, weil die App Verkaufsdaten, Standort-/Quellsystemkonfiguration, SharePoint-Konfiguration, Config Import/Export und Secrets bzw. Zugangsdatenfelder beruehrt.
+
+Neuer Stand:
+
+- die App ist grundsaetzlich authentifizierungspflichtig
+- produktives Ziel ist Windows Authentication / Active Directory
+- Berechtigungen laufen ueber AD-Gruppen
+- es gibt keine eigene Benutzer-/Passwortverwaltung in der App
+- es gibt keinen versteckten produktiven Backdoor
+
+Neue Security-Dateien:
+
+- `Security/SecurityOptions.cs`
+- `Security/SecurityPolicies.cs`
+- `Security/DevelopmentAuthenticationHandler.cs`
+
+Geaenderte zentrale Dateien:
+
+- `Program.cs`
+- `Components/Routes.razor`
+- `Components/_Imports.razor`
+- `Components/Layout/NavMenu.razor`
+- `Components/Layout/MainLayout.razor`
+- `appsettings.json`
+- `appsettings.Development.json`
+
+Aktuelles Rollenmodell:
+
+- `Security:AccessGroups` steuert Zugriff auf die App
+- `Security:AdminGroups` steuert Admin-Berechtigung
+- Default-Gruppen sind `TRAFAG\\TrafagSalesExporter-Users` und `TRAFAG\\TrafagSalesExporter-Admins`
+- echte Gruppennamen muessen von der IT bestaetigt oder angepasst werden
+
+Admin-geschuetzte Seiten:
+
+- `Settings`
+- `Standorte`
+- `Transformations`
+
+Dashboard, Management Cockpit und Logs bleiben fuer berechtigte angemeldete Benutzer sichtbar.
+
+Development:
+
+- `appsettings.Development.json` aktiviert bei `ASPNETCORE_ENVIRONMENT=Development` einen lokalen Development-Auth-Handler
+- Default-User: `DEV\\TrafagDeveloper`
+- `DevelopmentUserIsAdmin=true`, damit lokal weiter programmiert werden kann
+- produktiv darf die App nicht mit `Development` laufen
+
+IIS-/IT-Hinweise:
+
+1. Windows Authentication aktivieren
+2. Anonymous Authentication deaktivieren
+3. `ASPNETCORE_ENVIRONMENT` produktiv nicht auf `Development` setzen
+4. AD-Gruppen fuer Benutzer und Admins anlegen oder bestehende Gruppen eintragen
+5. `Security:AccessGroups` und `Security:AdminGroups` in produktiver Konfiguration korrekt setzen
+
+Verifikation:
+
+```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`
+- bekannte MudBlazor-Analyzer-Warnungen zu `Dense` bleiben
+
 ## Nachtrag 2026-04-29 Management-Cockpit-Auswertung
 
 Seit dem letzten dokumentierten Stand vom 2026-04-17 wurde das `Management Cockpit` weiter ausgebaut. Dieser Abschnitt rekonstruiert den aktuellen Stand aus dem Code, weil die Aenderungen nach einem PC-Absturz nicht direkt nachdokumentiert wurden.