FORTS: OnTradeTransaction() Rückgabecodes - Seite 5

 

11.2Gebühren für fehlerhafte Transaktionen.

Transaktionen werden als fehlerhaft anerkannt, wenn ihnen im Verlauf der Transaktion ein Fehlercode gemäß Tabelle 2 zugewiesen wurde. Für die Zwecke der Ermittlung fehlerhafter Transaktionen wird unter einer Transaktion die Einreichung einer Order, die Rücknahme einer Order, die Rücknahme einer Order bei gleichzeitiger Einreichung einer Order mit unterschiedlichen Transaktionsbedingungen, die Rücknahme eines Ordenspaares bei gleichzeitiger Einreichung eines Ordenspaares mit unterschiedlichen Transaktionsbedingungen verstanden.

Die Berechnung des Entgelts für Fehltransaktionen erfolgt für jeden Login für den Zeitraum von der Aussetzung des Handels für die abendliche Clearing-Session des aktuellen Handelstages (einschließlich der ersten Sekunde der Aussetzung) bis zur Aussetzung des Handels für die abendliche Clearing-Session des nächsten Handelstages (ohne die erste Sekunde der Aussetzung) (im Folgenden - der Berechnungszeitraum).

Die Berechnung der Höhe der Gebühr für fehlerhafte Transaktionen erfolgt nach der folgenden Formel:

wo:

TranFee2 - die Höhe der Gebühr für fehlerhafte Transaktionen während des Abrechnungszeitraums (in Rubel einschließlich Mehrwertsteuer);

Cap - ein vom Technischen Zentrum festgelegter und auf der Website der Moskauer Börse veröffentlichter Höchstbetrag für die Gebühr für fehlerhafte Transaktionen;

xi- pro Sekunde berechneter Wert, abgerundet auf ganze Zahlen und bestimmt durch die Formel:

wo:

Qi- die Summe aller Punkte für die i-te Sekunde (die Punkte werden gemäß Tabelle 2 bestimmt);

Li- der Grenzwert des angegebenen Logins, der nach der Formel berechnet und auf ganze Zahlen gerundet wird:

Wo:

Kapazitäti- Kapazität der Anmeldung, die nach dem in Punkt 3.2 dieses Anhangs festgelegten Verfahren bestimmt wird und für die i-te Sekunde gilt.

Tabelle 2:

Vorgangsart*

Ergebnis der Ausführung (Fehlercode)*

Punktzahl Q

AddOrder

Es hat eine Quertransaktion stattgefunden (31)

Q1

Unzureichende Kundengelder (332)

Q2

Unzureichende Mittel der Maklerfirma (333)

Q3

FOK-Angebot nicht konsolidiert (4103)

Q4

DelOrder

Auftrag nicht gefunden (14)

Q5

MoveOrder

Cross-Dealing fand statt (31)

Q6

Es wurde keinAuftraggefunden (50)

Q7

UnzureichendeKundengelder (332)

Q8

Unzureichende MitteldesMaklerunternehmens (333)

Q9

DelUserOrders

Die Transaktion wurde erfolgreich abgeschlossen,

und kein Auftrag wird gelöscht

Q10

* in Übereinstimmung mit der Beschreibung des FORTS Plaza-2 Gateway.

Die Q1-Q10-Punktewerte werden durch einen Beschluss des Technischen Zentrums festgelegt und auf der Website der Moskauer Börse veröffentlicht.

Eine Gebühr für fehlerhafte Transaktionen wird erhoben, wenn die Bedingung erfüllt ist:

wo:

TranFee2 - der Betrag der Gebühr für fehlerhafte Transaktionen, die während der Abrechnungsperiode getätigt wurden (in Rubel einschließlich Mehrwertsteuer);

Capmin- eine Beschränkung der Mindesthöhe der Gebühr für fehlerhafte Transaktionen, die vom technischen Zentrum festgelegt und auf der Website der Moskauer Börse veröffentlicht wird,

Die Gebühr für fehlerhafte Transaktionen wird von dem Abschnitt des Verrechnungsregisters abgebucht, mit dem die Anmeldung, für die die Gebühr für fehlerhafte Transaktionen ermittelt wurde, verknüpft ist.

 
Nur die Formeln werden leider nicht eingefügt.
 
Dmitriy Skub:
Willst du, dass wir uns betrinken?)) Ist es so schwer, eine Zahl zu schreiben?
Alexey Kozitsyn hat nur einen Teil des Textes dieser Bestimmung kopiert. Ist es jetzt klarer? )) Ich fürchte, Sie werden noch schlafen müssen, wenn Sie es verstehen wollen. ))
 

Wie lautet der Rückgabecode für diesen Fehler?

2015.09.21 10:00:13     20845617        SBRF-3.16       buy limit       2.00 / 0.00             7 303                   2015.09.21 10:00:13             rejected        Инструмент отсутствует в текуще 
 

Rückkehr zum Fehlercode Ungültige Anfrage

Ich habe die Funktion geändert, um den Auftrag ein wenig zu löschen:

//+------------------------------------------------------------------+
// Remove order                                                      |
//+------------------------------------------------------------------+
void COrder::Remove()
{
  if ( ticket > 0 )
  {
    if ( OrderSelect( ticket ) )
    {
      ENUM_ORDER_STATE ord_state = ENUM_ORDER_STATE( OrderGetInteger( ORDER_STATE ) );
      if ( ( ord_state == ORDER_STATE_REQUEST_MODIFY ) || ( ord_state == ORDER_STATE_REQUEST_CANCEL ) ) return;
//---      
      mem_magic = ulong( OrderGetInteger( ORDER_MAGIC ) );
      mem_tick = GetTickCount();
      req_id = 0;
      MqlTradeRequest request = {0};
      MqlTradeResult  result  = {0};
            
      request.action = TRADE_ACTION_REMOVE;
      request.order = ticket;
          
      if ( OrderSendAsync( request, result ) )
      {
        if ( result.retcode == TRADE_RETCODE_PLACED )
        { 
          req_id = result.request_id;
//---          
          switch( order_status )
          {
            case BUY_ORDER:  state = ORD_BUY_DO_CANCEL;
                             break;
                
            case SELL_ORDER: state = ORD_SELL_DO_CANCEL;
                             break;           
          } 
          SetTransCount( true );
        }
        else
        {
          mem_magic = 0;
          mem_tick = 0;
          CheckError( result.retcode, "Remove: Ордер не удалён! Причина: ", order_status, ticket );
        }  
      }
      else
      {
        mem_magic = 0;
        mem_tick = 0;
        CheckError( result.retcode, "Remove: Ордер не отослан! Причина: ", order_status, ticket );
      }
    }
    else
    {
      ticket = 0;
      modify_count = 0;
    }
  }
  else
  {
    modify_count = 0;
  }
}

CheckError() Funktion.

//+------------------------------------------------------------------+
// Expert Check Error function                                       |
//+------------------------------------------------------------------+
void CheckError( const uint ret_code, const string err_msg, const ENUM_ORD_STATUS ord_status, const ulong a_ticket )
{
  switch( ret_code )
  {
    ........                              
    case TRADE_RETCODE_INVALID: Print( err_msg + GetRetCode( ret_code ), "; Билет = ", a_ticket );
                                break;                                                       
                
    default: Print( err_msg, GetRetCode( ret_code ), "; Билет = ", a_ticket );  
             break;            
  }
}

Nach Aufgabe der Bestellung:

2015.11.25 15:07:30.773 Trades  'xxxxx': buy limit 5.00 SNGP-3.16 at 40718
2015.11.25 15:07:30.784 Trades  'xxxxx': buy limit 5.00 SNGP-3.16 at 40718 placed for execution in 10 ms

MT 5 Server hat keine Antwort gesendet, die Funktion CheckOrders() wurde ausgelöst und ein Auftragsticket wurde empfangen:

2015.11.25 15:07:31.849 Forts_trader (SNGP-12.15,H1)    CheckOrders: Buy ордер установлен. Билет = 23992887

Danach wurde der Befehl zum Löschen des Auftrags (EA) NICHT ausgeführt:

2015.11.25 15:07:31.865 Forts_trader (SNGP-12.15,H1)    Remove: Ордер не отослан! Причина: Неправильный запрос Билет = 23992887

Dies wurde auch vom Terminal bestätigt:

2015.11.25 15:07:31.865 Trades  'xxxxx': failed cancel order #23992887 buy limit 5.00 SNGP-3.16 at 40718.00000 [Invalid request]

Frage:

Wie ist der Status des Auftrags im Terminalspeicher?

Warum ungültiger Antrag?

Ich habe ein Ticket von der Terminalumgebung erhalten, so dass das Terminal "weiß", dass die Bestellung eingestellt ist!

Immerhin hat dieselbe Funktion später diesen Auftrag mit demselben Ticket gelöscht:

2015.11.25 15:15:03.245 Trades  'ххххх': cancel order #23992887 buy limit 5.00 SNGP-3.16 at 40718
2015.11.25 15:15:03.254 Trades  'ххххх': cancel order #23992887 buy limit 5.00 SNGP-3.16 at 40718 placed for execution in 8 ms
 
Михаил:

Rückkehr zum Fehlercode Ungültige Anfrage

Ich habe die Funktion zum Löschen der Bestellung ein wenig geändert:

CheckError() Funktion.

Nach Aufgabe der Bestellung:

MT 5 Server hat keine Antwort gesendet, die Funktion CheckOrders() wurde ausgelöst und ein Auftragsticket wurde empfangen:

Danach wurde der Befehl zum Löschen des Auftrags (EA) NICHT ausgeführt:

Dies wurde auch vom Terminal bestätigt:

Frage:

Wie ist der Status des Auftrags im Terminalspeicher?

Warum ungültiger Antrag?

(Ich habe das Ticket von der Terminalumgebung erhalten, so dass das Terminal "weiß, dass die Bestellung aufgegeben wurde")!

Es gibt auch dies:

2015.11.24 17:07:15.020 FORTS (MXI-12.15,M5)       ORDER_STATE = ORDER_STATE_REQUEST_ADD
 

Versuchen Sie es auf diese Weise:

if(!(OrderGetInteger(ORDER_STATE)==ORDER_STATE_PARTIAL || OrderGetInteger(ORDER_STATE)==ORDER_STATE_PLACED)) return; 
 
Sergey Chalyshev:

Es gibt noch mehr davon:

Sergej!

Aus irgendeinem Grund scheint es mir, dass, wenn es einen Strafzettel gibt (nachdem ein Haftbefehl ausgestellt wurde), es keine

seinen Zustand:

ORDER_STATE_REQUEST_ADD
 
Михаил:

Sergej!

Irgendwie scheint es mir, dass, wenn es einen Strafzettel gibt (nachdem ein Haftbefehl ausgestellt wurde), es nicht möglich ist

Sein Status:

Das denke ich auch, aber es ist nicht meine Idee, dieser Fehler stammt aus dem Transaktionsprotokoll.

Nach dem Hinzufügen dieser Prüfung werden alle Zustände vor der Löschung und Änderung in das Protokoll aufgenommen. InvalidRequest tritt nicht mehr auf.

Diese Frage bezieht sich eher auf den Serverbetrieb und die Entwickler, wieORDER_STATE_REQUEST_ADD erscheint.

 
Sergey Chalyshev:

Das denke ich auch, aber es war nicht meine Idee, dieser Fehler stammt aus dem Betriebsprotokoll.

Nach dem Hinzufügen dieser Prüfung werden alle Zustände vor der Löschung und Änderung in das Protokoll aufgenommen. InvalidRequest tritt nicht mehr auf.

Diese Frage bezieht sich eher auf den Serverbetrieb und die Entwickler, wieORDER_STATE_REQUEST_ADD erscheint.

Es muss eine ziemlich lange Zeitspanne sein, in der das Terminal auf die Antwort des Servers wartet...
Grund der Beschwerde: