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

Nuevo comentario
 
Михаил:

Lo has entendido mal.

Fue el servidor el que no envió el estado del pedido PLASED durante 20 segundos.

Me refería a los desarrolladores del servidor.
 
Михаил:

Hay un error evidente en el terminal, donde el estado de la ordenORDER_STATE_STARTED"se cuelga".

¿Se ha solucionado finalmente?

¿Qué dice exactamente la bolsa sobre esta orden? ¿Se colocó rápidamente? Si es así, es obvio que hubo un error en el servidor o en el terminal MT que no actualizó el estado. Y con esto puedes ir al servicio técnico.

 

Como resultado de la discusión sobre el problema con Michael en Service Desk:

Parece que hay que explicar cómo funciona el sistema de pedidos y qué significa la colocación.

Así que:

1. Usted envía una solicitud 

buy limit 5.00 SNGR-3.16 at 35501

2. El servidor de MT5 comprueba esta solicitud (parámetros, pre-negociación, etc.). Si hay un problema, obtendrá un código de error correspondiente en respuesta a la solicitud.

A continuación, se crea una nueva orden y se le asigna un ticket (#24025010), con lo que se establece el estado "iniciado" para la orden. El ticket de la orden se utiliza para vincular el identificador de la orden en MT5 con la orden en la bolsa en el momento de colocar la orden en la bolsa.
El terminal envía una transacción sobre la adición de una nueva orden en el estado "iniciado", que puede seguirse en OnTradeTransaction.

3. A continuación, el servidor de operaciones (a través de la pasarela) envía su orden a la bolsa, si la solicitud fue enviada con éxito, su solicitud recibirá una respuesta - esto significa
"que la solicitud ha sido enviada", los resultados se ejecutarán de forma asíncrona, ya que no se sabe de antemano cuánto tiempo responderá la bolsa.

Respectivamente es en este punto donde se ve el registro en el diario

2015.11.26 10:48:23.726 Trades  'xxxxxx': buy limit 5.00 SNGR-3.16 at 35501 placed for execution in 7 ms

4. Después de un tiempo, la bolsa fija la orden en su sistema, le asigna un identificador y luego lo notifica a la pasarela y al servidor MT5.
Si la bolsa ha fijado la orden, el identificador de la orden se escribe en la orden en MT5 y el estado de la orden cambia con => colocada.
Si la bolsa se niega a realizar un pedido por alguna razón, el pedido será eliminado.

Todo esto se puede seguir simplemente registrando las transacciones que llegan a OnTradeTransaction.

================================================================================

Lo que sucede:

1. Usted presenta una solicitud de pedido - vea los pasos 1 a 3.

Y en el momento en que la orden ya está en MT5, y no hay ninguna orden en la bolsa, se envía una orden para retirar esta orden.
Pero como esta orden está en su estado inicial (iniciada) y no está definida la existencia de una orden para ella, recibe una negativa a retirar la orden
.

Debe realizar las comprobaciones-correcciones adecuadas en la lógica de su EA.


Z.U. La otra cosa es que en un segundo. 

2015.11.26 10:48:24.583 Trades  'xxxxxx': failed cancel order #24025010 buy limit 5.00 SNGR-3.16 at 35501.00000 [Invalid request]
(y además durante 20 segundos) el pedido debería haberse realizado, esto se está tratando, se ha encontrado uno de los posibles problemas - lo estamos corrigiendo.
 
MQ Alexander:
Gracias por las explicaciones. Por favor, añada esto a la documentación.
 
MQ Alexander:

Como resultado de la discusión sobre el problema con Michael en el Service Desk:

Parece que hay que explicar cómo funciona el sistema de pedidos y qué significa la colocación.

Así que:

1. Usted envía una solicitud


2. El servidor de MT5 comprueba esta solicitud (parámetros, pre-negociación, etc.). Si hay un problema, obtendrá un código de error correspondiente en respuesta a la solicitud.

A continuación, se crea una nueva orden y se le asigna un ticket (#24025010), con lo que se establece el estado "iniciado" para la orden. El ticket de la orden se utiliza para vincular el identificador de la orden en MT5 con la orden en la bolsa en el momento de colocar la orden en la bolsa.
El terminal envía una transacción sobre la adición de una nueva orden en el estado "iniciado", que puede seguirse en OnTradeTransaction.

3. A continuación, el servidor de operaciones (a través de la pasarela) envía su orden a la bolsa, si la solicitud fue enviada con éxito, su solicitud recibirá una respuesta - esto significa
"que la solicitud ha sido enviada", los resultados se ejecutarán de forma asíncrona, ya que no se sabe de antemano cuánto tiempo responderá la bolsa.

Respectivamente es en este punto donde se ve el registro en el diario

4. Después de un tiempo, la bolsa fija la orden en su sistema, le asigna un identificador y luego lo notifica a la pasarela y al servidor MT5.
Si la bolsa ha fijado la orden, el identificador de la orden se escribe en la orden en MT5 y el estado de la orden cambia con => colocada.
Si la bolsa se niega a realizar un pedido por alguna razón, el pedido será eliminado.

Todo esto se puede seguir simplemente registrando las transacciones que llegan a OnTradeTransaction.

================================================================================

Lo que sucede:

1. Usted presenta una solicitud de pedido - vea los pasos 1 a 3.

2. en el momento en que la orden ya está en MT5, y todavía no está presente en la bolsa, usted envía una orden para retirar esta orden.
Pero como esta orden está en su estado inicial (iniciada) y no está definida la existencia de una orden para ella, recibe una negativa a retirar la orden
.

Debe realizar las comprobaciones-correcciones adecuadas en la lógica de su EA.


Z.U. La otra cosa es que en un segundo

(y además, durante 20 segundos) la orden debe ser colocada, estamos tratando con ella, hemos encontrado uno de los problemas potenciales - vamos a arreglarlo.
Todavía no entendemos en qué momento el estado de la orden "iniciada" cambia al estado "colocada". ¿Sucede esto según el punto 3 de su explicación, según el punto 4 de su explicación o en ambos casos el punto 3 y el 4?
 
Yury Kirillov:
No está claro en qué momento el estado de la orden "iniciada" cambia a "colocada". ¿Sucede esto según el punto 3 de su explicación, según el punto 4 de su explicación o en ambos casos el punto 3 y el 4?
MQ Alexander:

4. Después de algún tiempo, la bolsa establece la orden en su sistema, asigna su identificador, y luego notifica a la pasarela y al servidor MT5 acerca de ella.
Si la bolsa ha establecido la orden - el identificador de la orden se escribe en la orden en MT5, y el estado de la orden cambia de iniciada => colocada.

 
MQ Alexander:

3. A continuación, el servidor de comercio (a través de la pasarela) envía su solicitud a la bolsa, si la solicitud se envió con éxito, entonces su solicitud será respondida, lo que significa

"que la solicitud ha sido enviada", los resultados de su trabajo se ejecutarán de forma asíncrona, ya que no se sabe de antemano a qué hora la respuesta de intercambio.

En consecuencia, es en este punto donde se ve en el asiento

2015.11.26 10:48:23.726 Trades  'xxxxxx': buy limit 5.00 SNGR-3.16 at 35501 placed for execution in 7 ms

4. Después de un tiempo, la bolsa establece la orden en su sistema, le asigna un identificador y luego notifica a la pasarela y al servidor MT5.
Si la bolsa ha establecido la orden, el identificador de la orden en MT5 se escribe en la orden en MT5 y el estado de la orden cambia con => colocada.

Aquí hay otro motivo de confusión: en el registro dice que el pedido ya ha sido realizado, pero en realidad su estado aún no ha cambiado.

¿Quizás deberíamos escribir algo como "enviado" en lugar de "realizado" porque el pedido no ha sido realmente aceptado por la bolsa?

 

Resulta lo siguiente.

Antes ( o después ) de realizar cualquier acción en una orden,

tienes que "comprobar" su estado cada vez (corrígeme si no estoy seguro):

enum ENUM_ORD_REAL_STATE
{
  ORD_NOT_SPECIFIED         = 0, //Состояние ордера не определено
  ORD_NONE_CANCELED         = 1, //Ордера нет, отменён пользователем
  ORD_NONE_PARTIAL_CANCELED = 2, //Ордера нет, исполнился частично (не был залит вторым объёмом)
  ORD_NONE_PARTIAL          = 3, //Ордера нет, исполнился частично
  ORD_NONE_EXPIRED          = 4, //Ордера нет, удалён по сроку
  ORD_NONE_FILLED           = 5, //Ордера нет, исполнился полностью
  ORD_NONE_REJECTED         = 6, //Ордера нет, отклонён брокером(биржей)
  ORD_BUSY                  = 7, //Ордер находится в переходном состоянии
  ORD_EXIST                 = 8, //Ордер выставлен на биржу, возможны действия над ним
  ORD_EXIST_PARTIAL         = 9  //Ордер выставлен на биржу, частично исполнился, возможны действия над ним
};
//
ENUM_ORD_REAL_STATE CheckOrderState( const ulong ticket )
{
  if ( ticket > 0 )
  {
    if ( HistoryOrderSelect( ticket ) ) //Только не существующий ордер может находится в истории
    {
      ENUM_ORDER_STATE ord_state = ENUM_ORDER_STATE( HistoryOrderGetInteger( ticket, ORDER_STATE ) );
      double init_volume = HistoryOrderGetDouble( ticket, ORDER_VOLUME_INITIAL );
      double cur_volume = HistoryOrderGetDouble( ticket, ORDER_VOLUME_CURRENT );
//---      
      switch( ord_state )
      {
                                                           
        case ORDER_STATE_CANCELED:       if ( init_volume == init_volume )
                                         {
                                           return( ORD_NONE_CANCELED );
                                         }
                                         else
                                         {
                                           return( ORD_NONE_PARTIAL_CANCELED );
                                         }  
                                         break;
                                         
        case ORDER_STATE_PARTIAL:        return( ORD_NONE_PARTIAL );
                                         break;
                                         
        case ORDER_STATE_EXPIRED:        return( ORD_NONE_EXPIRED );
                                         break;
                                                                              
        case ORDER_STATE_FILLED:         return( ORD_NONE_FILLED );
                                         break;
                                         
        case ORDER_STATE_REJECTED:       return( ORD_NONE_REJECTED );
                                         break;   
 
       
      }
    }
    else
    if ( OrderSelect( ticket ) ) 
    {
      ENUM_ORDER_STATE ord_state = ENUM_ORDER_STATE( OrderGetInteger( ORDER_STATE ) );
//---      
      switch( ord_state )
      {
        case ORDER_STATE_STARTED:
        case ORDER_STATE_REQUEST_ADD:
        case ORDER_STATE_REQUEST_MODIFY:
        case ORDER_STATE_REQUEST_CANCEL: return( ORD_BUSY );
                                         break; 
 
        case ORDER_STATE_PARTIAL:        return( ORD_EXIST_PARTIAL );
                                         break;
                                          
        case ORDER_STATE_PLACED:         return( ORD_EXIST );
                                         break;
      }
    }
  }
  return( ORD_NOT_SPECIFIED );
}
 
Михаил:

Resulta lo siguiente.

Antes ( o después ) de realizar cualquier acción en una orden,

tienes que "comprobar" su estado cada vez (corrígeme si me he perdido algo):

No es así,

Si nos fijamos en la entradaHistoryOrderSelect( ), entonces tenemos que aplicarHistoryOrderGetInteger(),HistoryOrderGetDouble()

 
Sergey Chalyshev:

No es correcto,

Si miramos enHistoryOrderSelect( ticket ), tenemos que aplicarHistoryOrderGetInteger(),HistoryOrderGetDouble()

Cierto, es un error de imprenta :)

Gracias, lo he corregido...

1234567891011
Nuevo comentario