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

 

Fantástico!

Tempo de instalação - 15:07:31.849

Hora da eliminação - 15:07:31.865

E já é a 25ª semana dopedido Inválido, e está com toda a seriedade. Agora entendo porque o servicedesk está em silêncio.


 

Em tais casos, o assessor pode receber um código:

TRADE_RETCODE_REJECT
 

Sergei!

Você se mostrou certo. Bug MQ

Oterminal não atualiza o status do pedido:

2015.11.26 15:41:56.094 Forts_trader (GAZR-12.15,H1)    Remove: Ордер не отослан! Причина: Неправильный запрос; Билет = 24041883
2015.11.26 15:41:56.094 Forts_trader (GAZR-12.15,H1)    DEBUG: order state = ORDER_STATE_STARTED
2015.11.26 15:41:56.068 Forts_trader (GAZR-12.15,H1)    CheckOrders: Sell ордер установлен. Билет = 24041883

Recebi um pedido, mas seu estado ainda éORDER_STATE_STARTED

 
Михаил:

Sergei!

Você se mostrou certo. Bug MQ

Oterminal não atualiza o status do pedido:

Recebi o pedido, mas seu estado ainda éORDER_STATE_STARTED

Michael, a ordem ainda existe depois destas mensagens? Por acaso, um acordo não poderia ter sido executado em alguns meses antes?

 
Alexey Kozitsyn:

Michael, a ordem ainda existe depois destas mensagens? Por acaso, foram alguns ms antes que o comércio não pudesse ter sido executado?

Sim, a ordem ainda existe após o erro.

Não importa, pois antes de eliminar (modificar) a ordem é verificada se ela existe:

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 ) ||
           ( ord_state == ORDER_STATE_REQUEST_ADD ) ) return;
//........................................ Other code 
   }
  }
}
 

Por que eu pergunto, eu tenho esta situação:

Diário de bordo (especialistas):

2015.11.26 18:05:16.725 FROG (RTS-12.15,M1)     TradeRemoveCycle case ORDER_STATE_PLACED: ОШИБКА #4756,  retcode = 10013. Ордер не удален!
2015.11.26 18:05:16.691 FROG (RTS-12.15,M1)     TradeRemoveCycle: ORDER_STATE_PLACED

Posso ver que o pedido foi aceito (o que significa que pode ser tratado), mas o pedido não está correto.

No diário de bordo, o diário é assim:

2015.11.26 18:05:16.725 Trades  '1007642': failed cancel order #35817112 buy 0.00  at market [Invalid request]
2015.11.26 18:05:16.693 Trades  '1007642': cancel order #35817112 buy limit 1.00 RTS-12.15 at 87780
2015.11.26 18:05:16.691 Trades  '1007642': deal #4375646 buy 1.00 RTS-12.15 at 87780 done (based on order #35817112)

Isto é, no momento em que a ordem foi apagada, um acordo foi executado sobre ela. E então, o robô está tentando apagar a ordem que não existe mais.

Agora eu estou tentando decidir o que fazer.

 
Михаил:

Sim, a ordem existe após o erro.

Mas isso não importa, porque antes de eliminar (modificar) a ordem é verificado que ela existe:

Como podem ver, o meu também...
 
Alexey Kozitsyn:

Por que eu pergunto, eu tenho esta situação:

Diário de bordo (especialistas):

Posso ver que o pedido foi aceito (o que significa que pode ser tratado), mas o pedido não está correto.

No diário de bordo, o diário é assim:

Isto é, no momento em que a ordem foi apagada, um acordo foi executado sobre ela. E então, o robô está tentando apagar a ordem que não existe mais.

Agora eu estou tentando decidir o que fazer.

Eu também tive este problema, mas o resolvi.

Que comando você usa para definir o OrderSend() ou OrderSendAsync()?

 
Михаил:

Eu também já tive este problema, mas o resolvi.

Qual comando você usa para definir OrderSend() ou OrderSendAsync()?

OrderSend(). E qual é a diferença neste caso?
 
Alexey Kozitsyn:
EncomendarEnviar()

O problema é que quando uma ordem está sendo executada, você não controla sua execução e, portanto, não bloqueia OnTick() ou OnBookEvent().

Você precisa lidar com o evento comercial na OnTradeTransaction() para controlar rapidamente a ordem que está sendo executada.

Em breve postarei o código de como fazê-lo...

Razão: