FORTS: Códigos de retorno de OnTradeTransaction() - página 5

Nuevo comentario
 

11.2Cobro de transacciones erróneas.

Las transacciones se reconocerán como erróneas si durante el transcurso de la transacción se le ha asignado un código de error según lo establecido en el cuadro 2. A efectos de determinar las operaciones erróneas, se entiende por operación la presentación de una Orden, la retirada de una Orden, la retirada de una Orden con la presentación simultánea de una Orden con condiciones de Operación diferentes, la retirada de un par de Órdenes con la presentación simultánea de un par de Órdenes con condiciones de Operación diferentes.

El cálculo de la Comisión por Operaciones Erróneas se realizará para cada Sesión de Negociación durante el período comprendido entre la suspensión de la negociación de la sesión de compensación vespertina del Día de Negociación en curso (incluyendo el primer segundo de suspensión) y la suspensión de la negociación de la sesión de compensación vespertina del Día de Negociación siguiente (sin incluir el primer segundo de suspensión) (en adelante, el Período de Cálculo).

El cálculo del importe de la Tasa por transacciones erróneas se realizará según la fórmula:

donde:

TranFee2 - el importe de la Tasa por transacciones erróneas realizadas durante el Periodo de Liquidación (en rublos, incluido el IVA);

Cap - un límite en el importe máximo de la Tasa por transacciones erróneas establecido por el Centro Técnico y publicado en el sitio web de la Bolsa de Moscú;

xi- valor calculado por segundo, redondeado a enteros y determinado por la fórmula:

donde:

Qi- la suma de todos los puntos para el i-ésimo segundo (los puntos se determinan de acuerdo con la Tabla 2);

Li- el límite del ingreso dado, que se calcula según la fórmula y se redondea a números enteros:

Dónde:

Capacidadi- capacidad del inicio de sesión, determinada de acuerdo con el procedimiento estipulado en el punto 3.2 del presente anexo, válida para el i-ésimo segundo.

Tabla 2:

Tipo de transacción*

Resultado de la ejecución (código de error)*

Puntuación Q

AddOrder

Se ha producido una transacción cruzada (31)

Q1

Insuficiencia de fondos de clientes (332)

Q2

Fondos insuficientes de la empresa de corretaje (333)

Q3

Oferta FOK no consolidada (4103)

Q4

DelOrder

Pedido no encontrado (14)

Q5

MoveOrder

Se produjeron operaciones cruzadas (31)

Q6

No se haencontrado ningunaorden(50)

Q7

Insuficiencia de fondos declientes (332)

Q8

Insuficiencia de fondosde laempresade corretaje(333)

Q9

DelUserOrders

La transacción se ha completado con éxito,

y no se elimina ninguna orden

Q10

* de acuerdo con la descripción de la pasarela FORTS Plaza-2.

Los valores de los puntos Q1-Q10 se fijan por decisión del Centro Técnico y se publican en el sitio web de la Bolsa de Moscú.

Se cobrará una tasa por Transacciones erróneas si se cumple la condición:

donde:

TranFee2 - el importe de la Tasa por Transacciones erróneas realizadas durante el Periodo de Liquidación (en rublos, incluido el IVA);

Capmin- restricción del importe mínimo de la Tasa por Transacciones erróneas fijada por el Centro Técnico y publicada en la página web de la Bolsa de Moscú,

La Tasa por Operaciones Erróneas se cobra desde la sección del registro de compensación a la que está vinculada la entrada para la que se determina la Tasa por Operaciones Erróneas.

 
Sólo las fórmulas, lamentablemente, no se insertan.
 
Dmitriy Skub:
¿Quieres que nos emborrachemos?) ¿Es tan difícil escribir una cifra?
Alexey Kozitsyn copió sólo una parte del texto de esta disposición. ¿Está más claro ahora? )) Me temo que tendrás que seguir durmiendo si quieres entenderlo. ))
 

¿Cuál es el código de retorno de este error?

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

Volviendo al código de error de solicitud inválida

He cambiado un poco la función para borrar el pedido:

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

Función 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;            
  }
}

Después de hacer el pedido:

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

El servidor MT 5 no ha enviado ninguna respuesta, se ha activado la función CheckOrders() y se ha recibido un ticket de pedido:

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

Después de eso, el comando para eliminar la orden (EA) NO pasó:

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

Y esto también fue confirmado por la terminal:

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]

Pregunta:

¿Cuál es el estado de la orden en la memoria del terminal?

¿Por qué la solicitud no es válida?

¡Recibí un ticket del entorno del terminal, por lo que el terminal "sabe" que el pedido está establecido!

Al fin y al cabo, más tarde la misma función borró esta orden con el mismo billete:

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

Volviendo al código de error de solicitud inválida

He modificado la función para borrar un poco el orden:

Función CheckError().

Después de hacer el pedido:

El servidor MT 5 no ha enviado ninguna respuesta, se ha activado la función CheckOrders() y se ha recibido un ticket de pedido:

Después de eso, el comando para eliminar la orden (EA) NO pasó:

Y esto también fue confirmado por la terminal:

Pregunta:

¿Cuál es el estado de la orden en la memoria del terminal?

¿Por qué la solicitud no es válida?

¡(He obtenido el ticket desde el entorno del terminal, por lo que el terminal "sabe que el pedido ha sido realizado")!

También está esto:

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

Inténtalo de esta manera:

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

Hay más de estos:

¡Sergei!

Por alguna razón me parece que si hay una multa (después de una orden judicial), no puede haber

su estado:

ORDER_STATE_REQUEST_ADD
 
Михаил:

¡Sergei!

De alguna manera me parece que si hay una multa (después de una orden judicial), no puede haber

Su estado:

Yo también lo creo, pero no es mi idea, este error es del registro de transacciones.

Después de añadir esta comprobación, ponga todos los estados, antes de la eliminación y la modificación, en el registro. Ya no se produce InvalidRequest.

Esta pregunta se refiere más a las operaciones del servidor y a los desarrolladores de cómo apareceORDER_STATE_REQUEST_ADD.

 
Sergey Chalyshev:

Yo también lo creo, pero no fue idea mía, este error es del registro de operaciones.

Después de añadir esta comprobación, ponga todos los estados, antes de la eliminación y la modificación, en el registro. Ya no se produce InvalidRequest.

Esta pregunta se refiere más a las operaciones del servidor y a los desarrolladores de cómo apareceORDER_STATE_REQUEST_ADD.

Debe haber un tiempo de espera bastante largo en el terminal esperando la respuesta del servidor...
1234567891011
Nuevo comentario