Files
IBKRTrader/docs/konzepte/KONZEPT-Modul-Accounting.md
T
RichardandClaude Opus 5 e1546bd1b1 Fruehjahrsputz: toter Code, ungenutzte Symbole, Dokumentenstand
Alles Entfernte war nachweislich ohne Aufrufer. Build, 198/198 Tests, Smoke-UI
und Daemon-Prueflauf sind vor und nach jedem Schritt gruen.

Code:
  - AIModelService: Platzhalter, der immer 0.5 lieferte. Im DI registriert,
    aber nie irgendwo injiziert. Ordner Core/AI faellt mit weg.
  - CtApiWrapper + CtMeta: JSON-Modelle fuer einen {data,meta}-Umschlag, den
    CapitolTrades nicht mehr liefert. Der Scraper deserialisiert seit laengerem
    direkt List<CtTrade>.
  - IBKRGatewayService: DisconnectAsync, InitBrokerageSessionAsync und
    SearchStocksBySymbolAsync. Der Dienst selbst bleibt - er versorgt
    Instrument-Sync, Kurshistorie und den Watchdog-Heartbeat.
  - Je eine Methode ohne Aufrufer: BudgetService.GetAvailableBudgetAsync,
    TradeHistoryService.GetRecentTradesAsync, CongressRepository.
    GetAllTradeIdsAsync und .ResetHistoryImportAsync, IbkrMapping.DefaultPortFor,
    SecretProtection.IsEncrypted.
  - CongressRepository bekam damit einen LoggingService injiziert, den es nicht
    mehr benutzt - Abhaengigkeit samt Konstruktorparameter raus.

Ressourcen:
  - 17 Symbole der WinForms-Oberflaeche entfernt. Das Wildcard-Muster im csproj
    nahm sie in die Binaerdatei auf, ViewIcons.cs bildet aber nur sieben
    Schluessel ab. Resources/ enthaelt jetzt genau die sieben.

NuGet-Allowlist:
  - Dapper und HtmlAgilityPack sind seit R3 bzw. R1 aus dem Projekt raus,
    Microsoft.WindowsDesktop.* seit L5. Muster entfernt.
  - MySqlConnector und Newtonsoft.Json stehen NUR transitiv in den
    Projektdateien und wurden zuerst mitentfernt - ein Restore in einen leeren
    Paket-Ordner scheiterte darauf mit NU1100. Beide wieder aufgenommen, jetzt
    mit Begruendung, damit der naechste Aufraeumlauf nicht dieselbe Falle tritt.

Dokumente an den tatsaechlichen Stand angeglichen:
  - ARCHITECTURE: R2 fuehrte die Umstellung auf IHostedService als offen, obwohl
    R4 sie erledigt hat. L6 und die Deploymentcenter-Phase fehlten ganz.
  - DC-Konzept: Schritte 0-8 standen auf "dieser Durchlauf", sind aber umgesetzt.
    Jetzt je Schritt der wirkliche Stand - inklusive der beiden Halbfertigen:
    Update-PRUEFUNG laeuft, das Anwenden hat keinen Aufrufer; die
    Release-Pipeline steht, ist aber nie gelaufen. P5 ist eingetreten.
  - Accounting und Supervisor trugen keinen Umsetzungsvermerk, obwohl beide
    Module gebaut sind. Vermerk nach dem Muster des Linux-Konzepts ergaenzt,
    mit dem, was jeweils offen bleibt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 12:25:03 +02:00

5.2 KiB
Raw Blame History

Konzept: Modul „Accounting" (Buchhaltung/Reporting aller Konten)

UMGESETZT (Modulgerüst). Das Modul steht: acc_-Schema mit Migration InitialAccounting, AccountingIngestService (append-only, idempotent über IdempotencyKey), AccountingClassifier, AccountingEngine, FxConverter, AccountingReportService sowie CSV- und PDF-Export. Die Ingest-Quellen liegen hinter Interfaces mit Offline-Null-Stubs — das Modul läuft vollständig und bucht dabei korrekt nichts.

Weiterhin offen ist genau die Zielland-Arbeit aus §6 — vor allem der Live-Flex-Abruf, ohne den keine echten Buchungen entstehen, und die Steuerschicht, deren Jurisdiktion nicht festgelegt ist. Das Modul ist damit lauffähig, aber noch nicht in Betrieb.

Stand: 2026-07-30 Ziel: Vollständige, von unserer Trading-DB unabhängige, buchhalterisch korrekte Erfassung ALLER Kontobewegungen der IBKR-Konten. Periodische (meist monatliche), vor einer Steuerbehörde nachvollziehbare Aufstellungen — je Konto ODER über alle Konten, für frei wählbare Zeiträume. BWA-artige Kennzahlen-Übersicht in der UI. Export als CSV und PDF. Kein Handel; reines Ingest-/Reporting-Modul.

Vorbild: gleichnamiges Modul in PolytraderSharp (Polymarket). Hier auf IBKR-Aktien übertragen.

0. Leitprinzipien

  1. Unabhängige Quelle = IBKR-Kontoauszug, NICHT unsere DB. Das Modul erhebt die Buchungsgrundlage ausschließlich über eigene Abrufe des IBKR Activity Flex Query (XML) und speichert sie roh + normalisiert in eigenen acc_-Tabellen. Der Flex Web Service (Token + Query-Id) braucht keine laufende TWS-Socket-Verbindung. Unsere eigenen Trade-Logs dienen nur dem optionalen Abgleich, nie als Buchungsgrundlage.
  2. Nachvollziehbarkeit / Audit. Jeder Buchungssatz führt über TransactionId (IBKR tradeID / transactionID) und den unveränderlichen IdempotencyKey auf einen prüfbaren Nachweis zurück. Der Roh-Ingest ist append-only; Abrechnungen sind daraus reproduzierbar.
  3. Lesend / idempotent. Überlappende Wiederholungs-Abrufe buchen nichts doppelt (Unique-Index auf IdempotencyKey, Upsert statt Insert).

1. Architektur-Einbettung

Projekt src/IBKRTrader.Modules.Accounting/ als IModule (Name="Accounting", DbPrefix="acc_"), Registrierung in Program.cs. Referenziert nur den Core. Eigener AccountingDbContext, eigene UI (ein Fenster mit Tabs), eigene Settings-Sektion.

2. Datenbeschaffung

  • Activity Flex Query = primärer Kontoauszug: <Trade> (Käufe/Verkäufe: Preis, Menge, Kommission, Währung, FX-Rate zur Basiswährung, tradeID) und <CashTransaction> (Dividenden, Quellensteuer, Zinsen, Ein-/Auszahlungen, Gebühren).
  • Backfill + Inkrementell: Erstlauf lädt die volle Historie, danach nur Neues ab dem letzten bekannten Zeitpunkt mit Sicherheits-Lookback (Standard 24 h).
  • Idempotenz-Schlüssel je Satz: TRD|<Typ>|<tradeID> bzw. CASH|<Typ>|<transactionID>.
  • Balance-Anker: gemeldeter Kontosaldo je Abruf als Soll-Ist-Kontrollpunkt.
  • Der Abruf liegt hinter Interfaces (IStatementSource/IBalanceAnchorSource/IAccountingAccountSource) mit Offline-Null-Stubs — das Modul läuft ohne Live-Anbindung vollständig (bucht dann korrekt nichts). Der Live-Flex-Abruf ist Zielland-Arbeit.

3. Persistenz (acc_-Tabellen, append-only)

Tabelle Inhalt
acc_ledger Normalisierte, unveränderliche Buchungssätze (Typ, Vorzeichen=Cash-Wirkung, native + Basiswährung, TransactionId, IdempotencyKey unique)
acc_ingest_runs Abruf-Protokoll je Konto (Von/Bis, #neu/#Duplikate, Balance-Anker-Δ)
acc_raw Rohdaten-Snapshots je Batch (Nachweis)
acc_fx_rates amtliche USD→EUR-Tageskurse (EZB) je Datum

4. Logik (pur, unit-getestet — Logic/)

  • AccountingClassifier — Flex-Zeile → Buchungssatz (Typ, Vorzeichen, Idempotenz-Key). Ein-/Auszahlung per Vorzeichen (kombinierte IBKR-Kategorie).
  • AccountingEngine — Periodenabrechnung (Anfangs-/Endsaldo, Einlagen/Entnahmen, Handelsvolumen, Dividenden, Zinsen, Fees, Quellensteuer, Netto-Handelsergebnis Cash-Basis) + Monatsvergleich. Invariante: EndsaldoAnfang = Ergebnis + Einzahlungen Auszahlungen.
  • FxConverter — USD→EUR (Nearest-on-or-before). CsvExporter (RFC-4180, kulturinvariant). PdfExporter (PDFsharp/MigraDoc, MIT).
  • Realisierte GuV nutzt den Core-RealizedPnlEngine (FIFO) — kein Duplikat.

5. UI (Avalonia, ein Fenster mit Registerkarten)

Übersicht/BWA (KPI-Kacheln + Monatsvergleich, Zeitraum-/Konto-/Währungswahl), Ledger (filterbar), Steuer (Platzhalter, s. u.), Abrechnung/Export (CSV/PDF), Abruf/Status (Ingest-Läufe, Soll-Ist, manueller Trigger). DB-Zugriff nur auf Interaktion (Smoke-UI-sicher).

6. Bewusst offen / Zielland-Arbeit

  • Live-IBKR-Flex-Abruf (Token/Query-Id) + Balance-Anker → echte Buchungen (heute Null-Stub).
  • Steuerschicht: Jurisdiktion (DE-Kapitalertragsteuer / US Form 8949) noch nicht festgelegt. Der neutrale Ledger + die Abrechnung gelten unabhängig davon; die Steuer-UI/Engine ist als klar abgetrennter, später füllbarer Platzhalter angelegt. Keine Steuerberatung.
  • EZB-FX-Ingest (acc_fx_rates füllen) → EUR-Ansicht; USD (Basis) ist sofort verfügbar.