Statistik geprueft: Aggregate exakt, aber die Netto-Rechnung ist um Faktor 4,7
zu pessimistisch
Geprueft gegen unabhaengige SQL-Rechnung: /api/stats ueber today/week/all mit
~50 Werten (n_trades, wins/losses/breakeven, total_pnl, avg_win/loss,
gross_win/loss, winrate, profit_factor), dazu die inneren Konsistenzen
(wins+losses+be = n, gross_win-gross_loss = total_pnl, Summe closed_by = n,
Summe hour_stats = wins/losses) und 8 Setup-Zeilen. Ebenso stats_compact und
day_pl. Alles stimmt bitgenau.
Der Defekt liegt in server._add_net / _add_net_setup:
net_pnl = total_pnl - gross_win x 26,375 %. Das unterstellt, die Quellensteuer
sei endgueltig verloren - sie wird aber groesstenteils erstattet, was CLAUDE.md
selbst dokumentiert ("erstattet via taegl. Tax settlement"), die Rechnung aber
ignoriert.
Empirisch aus den echten Broker-Buchungen (history_deals_get, gleicher Zeitraum
wie die Statistik): einbehalten -2236,10, erstattet +1789,65, tatsaechlich
verblieben -446,45. Das Modell rechnet mit -2097,10.
Angezeigtes Netto -1104,67 gegen reales Netto +545,98 - Abweichung 1650,65 EUR,
und das Vorzeichen dreht. Real verbleiben nur 21 % der modellierten Last.
Richtige Loesung waere, die tatsaechlichen WHT-/Tax-Deals zu verwenden statt zu
schaetzen (ueber history_deals_get + Kommentar-Filter exakt abrufbar, gecacht und
unter mt5_lock). Nicht gebaut - Umfang war die Pruefung.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Opus 5
parent
7009541c42
commit
6ff3c15b1d
@@ -80,6 +80,41 @@ dort bereits nachvalidiert, ØR +0,305.) **Eine** Oberfläche:
|
|||||||
Race). `sr.detect()` läuft inline unter dem bereits gehaltenen Lock. Ebenso:
|
Race). `sr.detect()` läuft inline unter dem bereits gehaltenen Lock. Ebenso:
|
||||||
`mt5data.reconnect()` (shutdown/initialize) und `trader._log_open`-`delayed_log`
|
`mt5data.reconnect()` (shutdown/initialize) und `trader._log_open`-`delayed_log`
|
||||||
(positions_get im Thread) laufen jetzt unter `mt5_lock` (waren Races).
|
(positions_get im Thread) laufen jetzt unter `mt5_lock` (waren Races).
|
||||||
|
- ⚠⚠ **STATISTIK-PRÜFUNG 2026-08-05 (User-Auftrag): alle Aggregate KORREKT — aber
|
||||||
|
die NETTO-Rechnung überschätzt die Steuerlast um Faktor 4,7 und dreht das
|
||||||
|
Vorzeichen des Gesamtergebnisses.**
|
||||||
|
✅ **Geprüft und exakt:** `/api/stats` gegen unabhängige SQL-Rechnung, ~50 Werte
|
||||||
|
über `today`/`week`/`all` — n_trades, wins/losses/breakeven, total_pnl, avg_win,
|
||||||
|
avg_loss, gross_win/loss, winrate, profit_factor, dazu die inneren Konsistenzen
|
||||||
|
(wins+losses+be = n · gross_win−gross_loss = total_pnl · Σ closed_by = n ·
|
||||||
|
Σ hour_stats = wins/losses) und 8 Setup-Zeilen. **Alles stimmt bitgenau.**
|
||||||
|
Ebenso `stats_compact` (Dashboard-Kachel) und `day_pl` im Header.
|
||||||
|
⚠⚠ **DER DEFEKT liegt in `server._add_net` / `_add_net_setup`:**
|
||||||
|
`net_pnl = total_pnl − gross_win × 26,375 %`. Das unterstellt, die Quellensteuer
|
||||||
|
auf JEDEN Gewinn-Trade sei endgültig verloren. **Sie wird aber größtenteils
|
||||||
|
erstattet** — genau das steht zwei Absätze weiter unten („erstattet via tägl.
|
||||||
|
*Tax settlement*"), fließt in die Rechnung aber nicht ein.
|
||||||
|
**Empirisch aus den echten Broker-Buchungen** (`history_deals_get`, 08.05.–05.08.,
|
||||||
|
derselbe Zeitraum wie die Statistik):
|
||||||
|
| | |
|
||||||
|
|---|---|
|
||||||
|
| WHT einbehalten (685 Buchungen) | **−2.236,10 €** |
|
||||||
|
| erstattet (63 Tax-Buchungen) | **+1.789,65 €** |
|
||||||
|
| **tatsächlich verblieben** | **−446,45 €** |
|
||||||
|
| Modell der Statistik | −2.097,10 € |
|
||||||
|
| **angezeigtes Netto** | **−1.104,67 €** |
|
||||||
|
| **reales Netto** | **+545,98 €** |
|
||||||
|
**Abweichung +1.650,65 € — die Anzeige macht aus einem profitablen Konto ein
|
||||||
|
verlustreiches.** Real verbleiben nur **21 %** der modellierten Last.
|
||||||
|
✅ **Richtige Lösung: die TATSÄCHLICHEN Buchungen verwenden statt zu schätzen.**
|
||||||
|
Die WHT-/Tax-Deals sind über `mt5.history_deals_get` + Kommentar-Filter
|
||||||
|
(`WHT #…` / `Tax settlement`) exakt abrufbar; die Schätzung kann ganz entfallen.
|
||||||
|
⚠ Zu cachen (MT5-Abfrage gehört nicht in den 1-s-Snapshot) und unter `mt5_lock`.
|
||||||
|
⚠ **Der Header-G/V ist ein anderer Fall** (`app.js`: `raw × (1 − wht/100)` für die
|
||||||
|
OFFENE Position): dort ist der Abzug im Moment des Schließens sachlich richtig —
|
||||||
|
die Erstattung kommt erst später. Das ist eine Cashflow-Sicht, also vertretbar,
|
||||||
|
aber ebenfalls pessimistisch.
|
||||||
|
**Nicht gebaut** — Umfang war die Prüfung.
|
||||||
- **Steuer:** Broker behält **WHT 26,375 %** (DE-Abgeltungst.+Soli) je Gewinn ein
|
- **Steuer:** Broker behält **WHT 26,375 %** (DE-Abgeltungst.+Soli) je Gewinn ein
|
||||||
(`WHT #…`-Buchungen), erstattet via tägl. „Tax settlement". Stats sind **brutto**;
|
(`WHT #…`-Buchungen), erstattet via tägl. „Tax settlement". Stats sind **brutto**;
|
||||||
`[trading] wht_pct` zeigt eine Netto-Schätzung.
|
`[trading] wht_pct` zeigt eine Netto-Schätzung.
|
||||||
|
|||||||
Reference in New Issue
Block a user