FORTS: codici di ritorno di OnTradeTransaction() - pagina 5

Nuovo commento
 

11.2Addebito per transazioni errate.

Le transazioni sono riconosciute come errate se nel corso della transazione è stato assegnato un codice di errore come indicato nella tabella 2. Ai fini della determinazione delle transazioni errate, per transazione si intende la presentazione di un ordine, il ritiro di un ordine, il ritiro di un ordine con la contemporanea presentazione di un ordine con condizioni di transazione diverse, il ritiro di una coppia di ordini con la contemporanea presentazione di una coppia di ordini con condizioni di transazione diverse.

Il calcolo della Commissione per le Operazioni Erronee sarà effettuato per ogni Login per il periodo dalla sospensione della negoziazione per la sessione di compensazione serale del Giorno di Negoziazione corrente (incluso il primo secondo di sospensione) alla sospensione della negoziazione per la sessione di compensazione serale del Giorno di Negoziazione successivo (non incluso il primo secondo di sospensione) (di seguito - il Periodo di Calcolo).

Il calcolo dell'importo della Tassa per le transazioni errate è fatto secondo la formula:

dove:

TranFee2 - l'importo della tassa per le transazioni errate effettuate durante il periodo di regolamento (in rubli, IVA inclusa);

Cap - un limite sull'importo massimo della tassa per le transazioni errate fissato dal Centro tecnico e pubblicato sul sito web della Borsa di Mosca;

xi- valore calcolato al secondo, arrotondato a numeri interi e determinato dalla formula:

dove:

Qi- la somma di tutti i punti per l'i-esimo secondo (i punti sono determinati secondo la tabella 2);

Li- il limite del login dato, che è calcolato secondo la formula e arrotondato a numeri interi:

Dove:

Capacitài- capacità della connessione, determinata secondo la procedura di cui al punto 3.2 del presente allegato, valida per il secondo i-esimo.

Tabella 2:

Tipo di transazione*

Risultato dell'esecuzione (codice di errore)*

Punteggio Q

AddOrder

Si sono verificati scambi incrociati (31)

Q1

Fondi del cliente insufficienti (332)

Q2

Fondi insufficienti dalla società di intermediazione (333)

Q3

Offerta FOK non consolidata (4103)

Q4

DelOrder

Ordine non trovato (14)

Q5

MoveOrder

Si è verificata una negoziazione incrociata (31)

Q6

Nessunordine è statotrovato (50)

Q7

Fondi delclienteinsufficienti(332)

Q8

Fondiinsufficientidellasocietà diintermediazione(333)

Q9

DelUserOrders

La transazione è stata completata con successo,

e nessun ordine viene cancellato

Q10

* in conformità con la descrizione del FORTS Plaza-2 Gateway.

I valori dei punti Q1-Q10 sono stabiliti da una decisione del Centro Tecnico e sono pubblicati sul sito web della Borsa di Mosca.

Una tassa per le transazioni errate sarà addebitata se la condizione è soddisfatta:

dove:

TranFee2 - l'importo della tassa per le transazioni errate effettuate durante il periodo di regolamento (in rubli, IVA inclusa);

Capmin- una restrizione sull'importo minimo della tassa per le transazioni errate fissata dal Centro tecnico e pubblicata sul sito web della Borsa di Mosca,

La Commissione per le Operazioni errate è addebitata dalla sezione del registro di compensazione a cui è collegato il login per il quale è determinata la Commissione per le Operazioni errate.

 
Solo le formule non sono purtroppo inserite.
 
Dmitriy Skub:
Vuoi che ci ubriachiamo?)) È così difficile scrivere una cifra?
Alexey Kozitsyn ha copiato solo una parte del testo di questa disposizione. È più chiaro ora? )) Temo che dovrete ancora dormire se volete capirlo. ))
 

Qual è il codice di ritorno per questo errore?

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        Инструмент отсутствует в текуще
 

Ritorno al codice di errore Invalid request

Ho cambiato la funzione per cancellare un po' l'ordine:

//+------------------------------------------------------------------+
// 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;
  }
}

Funzione CheckError().

//+------------------------------------------------------------------+
// 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;            
  }
}

Dopo aver effettuato l'ordine:

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

Il server MT 5 non ha inviato alcuna risposta, la funzione CheckOrders() è stata attivata e un biglietto d'ordine è stato ricevuto:

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

Dopo di che, il comando per cancellare l'ordine (EA) NON è andato a buon fine:

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

E questo è stato confermato anche dal terminale:

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]

Domanda:

Qual è lo stato dell'ordine nella memoria del terminale?

Perché la richiesta non valida?

Ho ricevuto un biglietto dall'ambiente del terminale, quindi il terminale "sa" che l'ordine è impostato!

Dopo tutto, più tardi la stessa funzione ha cancellato questo ordine con lo stesso biglietto:

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
 
Михаил:

Ritorno al codice di errore Invalid request

Ho cambiato la funzione per cancellare un po' l'ordine:

Funzione CheckError().

Dopo aver effettuato l'ordine:

Il server MT 5 non ha inviato alcuna risposta, la funzione CheckOrders() è stata attivata e un biglietto d'ordine è stato ricevuto:

Dopo di che, il comando per cancellare l'ordine (EA) NON è andato a buon fine:

E questo è stato confermato anche dal terminale:

Domanda:

Qual è lo stato dell'ordine nella memoria del terminale?

Perché la richiesta non valida?

(Ho ricevuto il biglietto dall'ambiente del terminale, quindi il terminale "sa che l'ordine è stato effettuato")!

C'è anche questo:

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

Provate in questo modo:

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

Ce ne sono altri:

Sergei!

Per qualche ragione mi sembra che se c'è una multa (dopo che è stato emesso un mandato), non può esserci

il suo stato:

ORDER_STATE_REQUEST_ADD
 
Михаил:

Sergei!

In qualche modo mi sembra che se c'è una multa (dopo che è stato emesso un mandato), non può esserci

Il suo stato:

Lo penso anch'io, ma non è una mia idea, questo errore viene dal log delle transazioni.

Dopo aver aggiunto questo controllo, mettete tutti gli stati, prima della cancellazione e della modifica, nel registro. InvalidRequest non si verifica più.

Questa domanda è più alle operazioni del server e agli sviluppatori come appareORDER_STATE_REQUEST_ADD.

 
Sergey Chalyshev:

Lo penso anch'io, ma non è stata una mia idea, questo errore viene dal registro delle operazioni.

Dopo aver aggiunto questo controllo, mettete tutti gli stati, prima della cancellazione e della modifica, nel registro. InvalidRequest non si verifica più.

Questa domanda è più alle operazioni del server e agli sviluppatori come appareORDER_STATE_REQUEST_ADD.

Ci deve essere un timeout piuttosto lungo nel terminale in attesa della risposta del server...
1234567891011
Nuovo commento