ah-admin/AH-Oil-Trader
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Netto-Rechnung aus den ECHTEN Steuer-Buchungen statt geschaetzt

Browse Source 
Der seit 05.08. dokumentierte Defekt ist behoben. _add_net rechnete
net_pnl = total_pnl - gross_win * 26,375 % und unterstellte, die
Quellensteuer sei endgueltig verloren. Sie wird aber taeglich per
"Tax settlement" erstattet - real zu 99 %.

all: vorher net_pnl -2.449,95 EUR, jetzt +181,00 (total +209,93, echte
Steuerlast +28,93). Verzerrung rund 2.630 EUR - sie machte aus einem
profitablen Konto ein verlustreiches. Die Schaetzung der EINBEHALTENEN
Summe war fast exakt; falsch war allein die Annahme, sie bleibe weg.

trader.steuer_buchungen() liest die WHT-/Tax-Deals direkt
(position_id == 0, sauber von Trade-Deals getrennt), unter mt5_lock,
5 min gecacht. Fail-safe: ohne MT5 Rueckfall auf die Schaetzung, das
Feld wht_quelle sagt welche Zahl drinsteht.

Kurze Zeitraeume bleiben verzerrt, in BEIDE Richtungen - die Erstattung
kommt am Folgetag. Bei "today" ist wht sogar negativ, weil die
Erstattung von gestern heute einging. Ehrlich benannt, nicht kaschiert.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Axel Hocks
2026-08-12 20:44:09 +02:00
co-authored by Claude Opus 5
parent d8839ef7c5
commit 5819a9df21
3 changed files with 127 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CLAUDE.md
+28
View File
@@ -6209,6 +6209,34 @@ aber „20:11:42 CLOSE" sagte. ➜ **Epochs übergeben (lokal + Offset), beim Le
Moment des Closes, der Broker den Fill). Die Summe hebt sich fast auf (+1,66 €
über 19 Trades) → nur berichtet, **nicht** automatisch korrigiert.
## ✅✅ NETTO-RECHNUNG AUS DEN ECHTEN STEUER-BUCHUNGEN (2026-08-12)
Der seit dem 05.08. dokumentierte Defekt ist behoben. `server._add_net` schaetzte
`net_pnl = total_pnl − gross_win × 26,375 %` und unterstellte, die Quellensteuer
sei endgueltig verloren. Sie wird aber taeglich per `Tax settlement` erstattet.
| Zeitraum | total_pnl | wht (ECHT) | net_pnl | einbehalten / erstattet |
|---|---|---|---|---|
| today | −32,72 | −68,93 | **+36,21** | −21,03 / **+89,96** |
| week | −1.235,26 | −432,88 | −802,38 | −425,71 / +858,59 |
| **all** | **+209,93** | **+28,93** | **+181,00** | −2.754,56 / **+2.725,63** |
⚠⚠ **Vorher stand bei `all` −2.449,95 €** — eine Verzerrung von rund **2.630 €**,
die aus einem profitablen Konto ein verlustreiches machte.
✅ Die Schaetzung der EINBEHALTENEN Summe war fast exakt (2.620 gegen 2.755);
falsch war allein die Annahme, sie bleibe weg — real werden **99 %** erstattet.
**Umsetzung:** `trader.steuer_buchungen(von, bis)` liest die `WHT #…`- und
`Tax settlement`-Deals direkt (position_id == 0, damit sauber von den Trade-Deals
getrennt — kein Doppelzaehlen). Unter `mt5_lock`, **5 min gecacht** (die Abfrage
ueber lange Zeitraeume braucht Sekunden und gehoert nicht in jeden Aufruf).
⚠ **Fail-safe:** antwortet MT5 nicht, faellt es auf die alte Schaetzung zurueck —
das Feld **`wht_quelle`** sagt, welche Zahl drinsteht („echt" / „geschaetzt").
⚠ **KURZE ZEITRAEUME sind verzerrt, in BEIDE Richtungen:** die Erstattung kommt
erst am Folgetag. Bei „today" oben ist `wht` sogar **negativ** (−68,93), weil die
Erstattung von GESTERN heute einging — das Netto liegt damit ueber dem Brutto.
Das ist korrekt gebucht, aber als Tageszahl irrefuehrend. Das Flag `wht_lag`
faengt bisher nur die eine Richtung (einbehalten, nichts erstattet).
⚠ Zeitfalle beachtet: Epochs mit Broker-Offset uebergeben, beim Lesen abziehen.
## ✅ STATISTIK-MODUL: ARITHMETIK KORREKT, NETTO-RECHNUNG WEITER DEFEKT (2026-08-12)
Gegen unabhängige SQL geprüft, alle drei Zeiträume: **Abweichung 0,00 in jeder