Order-Ticket-Mapping funktioniert durch den Abgleich von Order-, Deal- und Position-Tickets, kombiniert mit sekundären Prüfmerkmalen wie Zeitstempel, Symbol und Volumen. Dieser mehrstufige Abgleich verhindert doppelte Ausführungen beim Kopieren zwischen MetaTrader-Konten und macht den gesamten Prozess nachvollziehbar. Wer diese Hierarchie versteht, kann Kopierfehler meist schon vor der Ausführung abfangen.
Kurz gesagt:
- Ordnen Sie zunächst Masteraufträge und Clientaufträge über eine interne Zuordnungstabelle zu; bestätigen Sie den Treffer mit Zeitfenster, Symbol und übereinstimmendem Volumen.
- Speichern Sie den Zuordnungseintrag vor der Ausführungsbestätigung dauerhaft und prüfen Sie jede Anfragekennung vor einer erneuten Ausführung, damit Verzögerungen keine doppelten Trades auslösen.
- Eine Order kann mehrere Teilausführungen erzeugen; fassen Sie deren Deals deshalb über den stabilen Positionsbezeichner zusammen, statt jeden Deal als eigenen Trade zu zählen.
- Broker können dasselbe Symbol mit Präfixen oder Endungen schreiben; gleichen Sie Varianten über eine Symboltabelle ab und prüfen Sie Zeitstempel mit Toleranz statt exakt.
- Bei Prop-Firm-Konten kann die lokale Ausführung auf einem Windows-Rechner oder VPS Cloud-Routing vermeiden; ein manueller Eintragsmodus lässt kopierte Trades wie von Hand platziert erscheinen.
Inhaltsverzeichnis
- MT4/MT5-Ticket-Modelle und relevante API-Strukturen
- Schritt-für-Schritt: So implementieren Sie zuverlässiges Order-Ticket-Mapping
- Fehlerfälle und Troubleshooting beim Mapping
- Logs, Historienabfragen und Prüfqueries für Verifikation
- Autorperspektive: Praxiserfahrungen mit Ticket-Mapping
- Wie unsere Copier-Software Mapping-Probleme in der Praxis löst
- FAQ
- Quellen
MT4/MT5-Ticket-Modelle und relevante API-Strukturen
MetaTrader unterscheidet grundsätzlich zwischen drei Objekten: der Order, dem Deal und der Position. Eine Order ist der Auftrag selbst, ein Deal ist die tatsächliche Ausführung dieses Auftrags, und eine Position fasst zusammengehörige Deals zu einer Netto-Exposition zusammen. Laut der MetaTrader-5-Dokumentation zu Handelsoperationen erzeugt jede Ausführung eine eigene Kette dieser drei Ticket-Typen, und ein Trade-Copier muss diese Hierarchie respektieren, weil auf dem Client-Konto jeweils eine komplett neue Kette entsteht. Der Position Identifier (POSITION_IDENTIFIER) bleibt dabei über mehrere Teilausführungen hinweg stabil und eignet sich deshalb besonders gut als Ankerpunkt für Zuordnungen.
Technisch stützt sich das Mapping auf die Felder, die MetaTrader bei jedem Handelsereignis bereitstellt. Die MqlTradeTransaction-Struktur liefert dafür die entscheidenden Werte:
- order: das Ticket des Auftrags auf dem jeweiligen Konto
- deal: das Ticket der konkreten Ausführung
- position: der Position Identifier, der Teilausführungen verbindet
- price, volume, time: Ausführungsdetails zur sekundären Verifikation
- magic: die Kennung, über die ein Expert Advisor eigene Trades identifiziert
Wichtig dabei: Die Reihenfolge, in der diese Ereignisse eintreffen, ist nicht garantiert. Transaktionen können asynchron ankommen, Master- und Client-Ereignisse überschneiden sich zeitlich oft nur ungefähr. Ein Mapping-System, das auf einer strikten Event-Reihenfolge aufbaut, produziert deshalb früher oder später Fehlzuordnungen, gerade bei hoher Ausführungsfrequenz oder mehreren gleichzeitig kopierten Konten.
Schritt-für-Schritt: So implementieren Sie zuverlässiges Order-Ticket-Mapping
Ein belastbares Mapping-System steht und fällt mit der Disziplin beim Protokollieren. Folgende Schritte haben sich in der Praxis bewährt:
- Felder konsequent loggen: Erfassen Sie bei jedem Ereignis order, deal, position, time_msc, symbol, volume, magic, price und comment, und zwar für Master und Client getrennt.
- Primäres Matching über das Order-Ticket: Verknüpfen Sie zunächst Master-Order mit Client-Order anhand der internen Zuordnungstabelle, die beim Senden des Kopierauftrags angelegt wurde.
- Sekundäre Prüfung: Bestätigen Sie den Treffer über ein Zeitfenster von wenigen hundert Millisekunden, exaktes oder gemapptes Symbol und übereinstimmendes Volumen.
- UID- oder Hash-Fallback einsetzen: Erzeugen Sie bei Unsicherheit eine eindeutige Kennung aus Symbol, Ticket und Zeitstempel. Solche Hash-Strategien gelten als robust gegenüber broker-seitigen Ticket-Neuvergaben, wie Beispiele aus der MQL5-Marktpraxis zeigen.
- Mapping persistent speichern: Legen Sie jeden erfolgreichen Abgleich in einer Tabelle ab, die auch über einen Neustart des Terminals hinweg erhalten bleibt.
- Request-ID für Idempotenz nutzen: Prüfen Sie vor jeder neuen Ausführung, ob die zugehörige request_id bereits verarbeitet wurde, um Replays zu erkennen.
Der eigentliche Ablauf lässt sich knapp skizzieren: Der Master sendet ein Handelsereignis, der Client empfängt es, legt eine neue Order an, schreibt sofort einen Eintrag in die Map-Tabelle und bestätigt den Vorgang im Log. Jeder dieser Schritte sollte einzeln protokolliert werden, damit sich Abweichungen später exakt lokalisieren lassen.
Profi-Tipp: Schreiben Sie den Map-Eintrag, bevor Sie die Bestätigung der Ausführung erhalten, nicht danach, sonst entstehen bei Verzögerungen Zeitfenster für doppelte Verarbeitung.
Fehlerfälle und Troubleshooting beim Mapping
Die meisten Mapping-Fehler lassen sich auf eine Handvoll wiederkehrender Ursachen zurückführen. Symbolpräfixe und -suffixe sind der klassische Stolperstein: Ein Broker nennt ein Instrument „EURUSD“, ein anderer „EURUSD.m“ oder „EURUSDpro“. Ohne eine Symbolmapping-Tabelle, die diese Varianten aufeinander abbildet, scheitert der Abgleich schon vor dem ersten Vergleich.
Preis-Digits sind eine zweite häufige Fehlerquelle. Unterschiedliche Nachkommastellen zwischen Master- und Client-Broker führen zu scheinbaren Abweichungen, die sich mit NormalizeDouble und einer Digit-Prüfung vor dem Vergleich auffangen lassen. Teilfills verursachen eine dritte Kategorie von Problemen: Eine einzelne Order kann mehrere Deals erzeugen, die alle zur gleichen Position gehören. Hier hilft die Aggregation über den Position Identifier, statt jeden Deal isoliert zu betrachten.
Weitere Prüfpunkte:
- Zeitstempel niemals auf exakte Gleichheit prüfen, sondern mit einem kleinen Toleranzfenster über time_msc arbeiten, weil TradeTransaction-Ereignisse asynchron eintreffen können.
- Retcode und request_id gemeinsam auswerten, um doppelte Ausführungen frühzeitig zu erkennen.
- Bei Verdacht auf Duplikate immer die vollständige Ticket-Kette rekonstruieren, statt nur den letzten Deal zu betrachten.
Ein Order kann laut der MQL5-Referenz zu MqlTradeTransaction mehrere Deals erzeugen, wenn sie in Teilen ausgeführt wird. Wer diese Verknüpfung nicht korrekt aggregiert, zählt Teilausführungen fälschlich als separate, unabhängige Trades.
Logs, Historienabfragen und Prüfqueries für Verifikation
Laufendes Logging über OnTradeTransaction reicht für die tägliche Überwachung meist aus, solange keine Lücken im Protokoll entstehen. Für Nachforschungen im Nachhinein braucht es dagegen historische Abfragen. Die history_deals_get-Funktion der Python-MT5-Bindings erlaubt das gezielte Filtern nach order oder nach position und ist damit das Werkzeug der Wahl, wenn ein einzelner Trade nachträglich geprüft werden muss.
Eine Audit-Tabelle für Mapping-Vorgänge sollte mindestens folgende Spalten enthalten:
- MasterTicket und ClientTicket für die direkte Zuordnung
- Timestamp zur zeitlichen Einordnung
- RequestID zur Idempotenzprüfung
- Retcode zur Fehlerdiagnose
- Note für manuelle Anmerkungen bei Abweichungen
Diese Struktur macht spätere Supportanfragen deutlich schneller lösbar, weil sich jeder Vorgang eindeutig zurückverfolgen lässt.
Autorperspektive: Praxiserfahrungen mit Ticket-Mapping
Verlässliches Mapping entsteht selten am Reißbrett, sondern über Jahre an Betriebserfahrung mit echten Broker-Eigenheiten. Seit Jahren entwickeln wir Trade-Copying-Software für MetaTrader, die bei vielen Nutzern beliebt ist. Diese Praxis zeigt: Lokale Ausführung auf Windows oder VPS kann sinnvoll sein, wo geringe Latenz und Diskretion gegenüber Cloud-Routing wichtig sind, beispielsweise bei Prop-Firm-Konten mit Einschränkungen für externe Serverzugriffe.
Was sich bewährt hat, ist die Standardisierung jedes Map-Eintrags als strukturierter Datensatz mit UID und request_id. Das macht Supportfälle nachvollziehbar und reduziert manuelle Nachforschung auf ein Minimum.
— Rimantas
Wie unsere Copier-Software Mapping-Probleme in der Praxis löst
Die technischen Mechanismen aus diesem Artikel, Symbolmapping, UID-Bildung, lückenloses Logging, stecken direkt in unserer Software. Weil alles lokal auf einem Windows-Rechner oder VPS läuft, bleibt jede Zuordnung nachvollziehbar, ohne Umweg über fremde Server.
Konkret unterstützt unsere Lösung:
- Symbolmapping-Tabellen gegen Präfix- und Suffix-Probleme zwischen Brokern
- Detaillierte Ausführungslogs für jede kopierte Order
- Den manuellen Eintragsmodus, damit kopierte Trades für Prop-Firm-Konten wie von Hand platziert wirken
Wer das selbst ausprobieren möchte, startet mit der siebentägigen kostenlosen Testphase. Die passenden Pläne, PERSONAL, MANAGER und VIP, unterscheiden sich in Kontoanzahl und Funktionsumfang und lassen sich auf der Pricing-Seite direkt vergleichen.
FAQ
Was ist der Unterschied zwischen Order-, Deal- und Position-Ticket?
Eine Order ist der ursprüngliche Handelsauftrag, ein Deal die tatsächliche Ausführung dieses Auftrags, und eine Position fasst mehrere zusammengehörige Deals zu einer Netto-Exposition zusammen. Diese Dreiteilung ist laut der MetaTrader-5-Dokumentation grundlegend für jede korrekte Zuordnung beim Trade-Copying.
Warum reicht ein einzelner Ticket-Abgleich beim Kopieren nicht aus?
Weil Ticket-Nummern zwischen Master- und Client-Konto grundsätzlich unabhängig vergeben werden und Trade-Ereignisse laut der OnTradeTransaction-Dokumentation asynchron eintreffen können. Erst die Kombination aus Order-Referenz, Zeitfenster, Symbol und Volumen liefert eine verlässliche Zuordnung.
Wie erkenne ich doppelte Ausführungen beim Ticket-Mapping?
Doppelte Ausführungen lassen sich über die Kombination aus request_id und Retcode in der MqlTradeResult-Struktur erkennen, da jede eindeutige Anfrage nur einmal verarbeitet werden sollte. Eine persistente Mapping-Tabelle, die bereits verarbeitete Request-IDs speichert, verhindert erneute Ausführungen zuverlässig.
Wie gehe ich mit Teilausführungen beim Mapping um?
Teilausführungen erzeugen mehrere Deals zu einer einzigen Order, die alle über denselben Position Identifier verbunden sind. Funktionen wie history_deals_get mit Filter auf die Position erlauben es, alle zugehörigen Deals gesammelt abzurufen und korrekt zu aggregieren.
Welche Rolle spielt lokale Ausführung beim Mapping für Prop-Firm-Konten?
Lokale Ausführung auf einem eigenen Windows-Rechner oder VPS hält sämtliche Mapping-Daten auf einer Maschine und vermeidet Cloud-Routing, was bei Prop-Firm-Konten mit Einschränkungen für automatisierten Handel relevant ist. Unsere Software bietet dafür zusätzlich einen manuellen Eintragsmodus, damit kopierte Trades wie von Hand platziert erscheinen.
Quellen
- Basic Principles – Trading Operations – MetaTrader 5 Help
- Trade Transaction Structure – MQL5 Reference
