Richard/IBKRTrader

Fork 0

Files

T

RichardandClaude Opus 5 c176b05ea1

Build & Test / build (ubuntu-latest) (push) Waiting to run

Details

Build & Test / build (windows-latest) (push) Waiting to run

Details

L6: IBKRTrader.App.Avalonia -> IBKRTrader.App; letzte WinForms-Spuren raus

Das Suffix ".Avalonia" gab es nur, weil daneben ein WinForms-IBKRTrader.App
stand. Das ist seit L5 weg, also faellt auch das Suffix. Git erkennt alle
Dateien als Umbenennung; Assembly, Wurzel-Namensraum und die
avares://-Ressourcen-URI sind mitgezogen.

Nebeneffekt der Umbenennung: die global::Avalonia-Qualifizierungen entfallen.
Sie waren noetig, weil der Namensraum IBKRTrader.App.Avalonia das
Avalonia-Paket verdeckt hat - ein Ueberbleibsel genau der Namensgebung, die
jetzt weg ist.

Inhaltlich falsch gewordene Aussagen berichtigt - das waren die eigentlichen
Ueberbleibsel, nicht die Kommentare:
- .agents/rules/grundregeln.md schrieb weiterhin "C# .NET 10 WinForms",
  RichTextBox-Logging, LauncherForm und PropertyGrid vor. Das ist die Regel,
  nach der kuenftig gearbeitet wird - sie haette die Portierung Stueck fuer
  Stueck rueckgaengig gemacht. Jetzt: Avalonia, keine Plattform-Suffixe, die
  11er-Pinnung mit Begruendung, dazu die beiden Regeln, die uns in L1b am
  meisten gekostet haben (UTC persistieren + AppTimeZone statt DateTime.Now;
  jede Formatierung mit ausdruecklichem IFormatProvider).
- Core: LogEntry ("wird in RichTextBox geschrieben"), IWorker/WorkerEngine/
  WorkerInfo ("DataGridView-Zeile"/"-Binding"), ModuleView ("die
  WinForms-Shell castet auf Form").
- Doku: ARCHITECTURE (Modul-Ui-Ordner, "designbare Forms mit Initialize"),
  KONZEPT-Modul-Accounting ("UI (WinForms, ein Fenster mit Tabs)").

BEWUSST STEHEN GEBLIEBEN sind die Kommentare, die WinForms nur als
Begruendung nennen - warum LoggingService ein Ereignis hat statt einer
RichTextBox, warum ModuleView Func<object> liefert, warum es benannte
Record-Zeilentypen gibt, warum die Einstellungsmaske aus Attributen entsteht.
Das ist die Herleitung des heutigen Entwurfs; ohne sie sieht spaeter jede
dieser Stellen nach Umstaendlichkeit ohne Grund aus.

KONZEPT-Linux-Portierung.md bekommt einen Statusvermerk: umgesetzt, die
Pfadangaben im Fundstellenverzeichnis beziehen sich auf den alten Aufbau.
Zwei Abweichungen von der Schaetzung sind dort festgehalten - der geringere
Aufwand dank der PolytraderSharp-Vorlage, und dass die dort empfohlene
InvariantGlobalization ein Fehler gewesen waere.

Verifiziert: Build 0 Fehler/0 Warnungen, 193 Tests gruen, Smoke-UI
konstruiert alle 7 Ansichten + Launcher + Dialog, Daemon-Prueflauf OK,
publish -r linux-x64 fuer beide Einstiegspunkte fehlerfrei.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-07 21:16:48 +02:00

4.5 KiB

Raw Permalink Blame History

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

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

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.
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.
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: Endsaldo−Anfang = 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.

4.5 KiB Raw Permalink Blame History Unescape Escape