Zwei Vorhaben des Betreibers, beide mit demselben Kern: die Durchsetzung gehoert in den Core, die Oberflaeche ist nur die Bedienung. Eine Sperre, die ein Modul selbst pruefen muesste, ist keine Sperre. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
@@ -509,6 +509,40 @@ Ledger und die Abrechnung gelten unabhängig davon; die Steuer-Engine ist als kl
|
|||||||
Platzhalter angelegt. Das Profil wird einmalig gesetzt und danach in der DB verankert.
|
Platzhalter angelegt. Das Profil wird einmalig gesetzt und danach in der DB verankert.
|
||||||
**Keine Steuerberatung.**
|
**Keine Steuerberatung.**
|
||||||
|
|
||||||
|
### [K] #485 — Positionsverwaltung: Herkunft, Zuordnung, Sperren
|
||||||
|
|
||||||
|
Seit dem Bestandsabgleich (#300/#306) weiß das System, welche Position zu welchem Buch gehört und
|
||||||
|
welche es beim Broker fand, ohne sie zuordnen zu können. **Sehen kann man das nirgends**, und
|
||||||
|
ändern schon gar nicht: UNASSIGNED bleibt UNASSIGNED, bis jemand in die Datenbank greift.
|
||||||
|
|
||||||
|
Die drei Fähigkeiten – sehen, zuordnen, sperren – hängen zusammen, weil sie dieselbe Zeile
|
||||||
|
betreffen. Die Sperre ist dabei die wichtigste und die einzige, die im Core sitzen muss: **Eine
|
||||||
|
Sperre, die ein Modul selbst prüfen müsste, ist keine Sperre, sondern eine Bitte.** Sie gehört
|
||||||
|
neben die Deckungsprüfung in den Risikopfad, wo ein Modulfehler sie nicht umgehen kann. Das
|
||||||
|
Fenster ist die Bedienung, nicht der Ort der Entscheidung.
|
||||||
|
|
||||||
|
Vier Stufen: frei, nur schließen, nur aufbauen, gesperrt. Die letzte verdient eine Warnung beim
|
||||||
|
Setzen – **sie verhindert auch den Ausgang.** Eine Position, die aus Risikogründen geschlossen
|
||||||
|
werden müsste, bleibt liegen, bis jemand die Sperre löst. Das ist eine zulässige Entscheidung des
|
||||||
|
Betreibers, aber sie muss beim Setzen sichtbar sein und nicht erst im Störungsfall.
|
||||||
|
|
||||||
|
Der manuelle Handel in TWS bleibt unberührt: gesperrt werden Module, nicht der Mensch.
|
||||||
|
|
||||||
|
### [K] #486 — Instrumentenverwaltung: Handelsverbot und harte Obergrenzen
|
||||||
|
|
||||||
|
Heute gibt es allein `MaxSymbolPercent` – ein prozentuales Konzentrationslimit. Das ist eine
|
||||||
|
Risikostreuung und wächst mit dem Konto. Was fehlt, sind Aussagen über ein **bestimmtes Papier**:
|
||||||
|
„dieses Instrument nie" und „von diesem höchstens 100 Stück".
|
||||||
|
|
||||||
|
Beides ist bewusst etwas anderes als der Prozentsatz und ersetzt ihn nicht; es gilt die jeweils
|
||||||
|
engere Grenze. Das Handelsverbot hängt am Instrument, nicht am Ticker allein – `SAP:EUR` und die
|
||||||
|
SAP-ADR in USD sind zwei Instrumente, und die Währung gehört seit #479 zur Identität. Ein Symbol
|
||||||
|
samt aller Notierungen zu sperren muss trotzdem möglich sein, sonst ist die Liste nicht pflegbar.
|
||||||
|
|
||||||
|
Offene Entscheidung, im Item festgehalten: Ein nachträglich gesetztes Verbot sperrt den **Kauf**,
|
||||||
|
nicht das Schließen. Ein Verbot darf keine Position einsperren, die man gerade loswerden will;
|
||||||
|
wer das ausdrücklich will, nimmt die Positionssperre aus #485.
|
||||||
|
|
||||||
### [T] #466 — TWS-Meldungen mit Umlauten kommen falsch dekodiert an
|
### [T] #466 — TWS-Meldungen mit Umlauten kommen falsch dekodiert an
|
||||||
|
|
||||||
Am ersten Verbindungstag auf dem neuen Testserver stand im Log `verzögerte Marktdaten` – das Bild,
|
Am ersten Verbindungstag auf dem neuen Testserver stand im Log `verzögerte Marktdaten` – das Bild,
|
||||||
|
|||||||
Reference in New Issue
Block a user