FORTS : Codes de retour de OnTradeTransaction() - page 9

Nouveau commentaire
 
Михаил:

Vous avez mal compris.

C'est le serveur qui n'a pas envoyé le statut de commande PLASED pendant 20 secondes.

Je voulais dire les développeurs du serveur.
 
Михаил:

Il y a une erreur évidente dans le terminal, où l'état de la commandeORDER_STATE_STARTED"pend".

La question a-t-elle été définitivement réglée ?

Qu'est-ce que la bourse a dit exactement à propos de cet ordre? A-t-il été placé rapidement ? Si c'est le cas, il est évident qu'il y a eu une erreur sur le serveur ou le terminal MT qui n'a pas mis à jour le statut. Et avec ça, vous pouvez vous adresser au service d'assistance.

 

Suite à la discussion sur le problème avec Michael dans le Service Desk :

Apparemment, nous devons expliquer comment fonctionne le système de commande et ce que signifie le placement.

Donc :

1. Vous envoyez une demande 

buy limit 5.00 SNGR-3.16 at 35501

2. Le serveur MT5 vérifie cette demande (paramètres, pre-trade, etc.). S'il y a un problème, vous obtiendrez un code d'erreur correspondant en réponse à la demande.

Après cela, vous créez une nouvelle commande en lui donnant un ticket (#24025010) - avec cela, l'état "commencé" est défini pour la commande. Le ticket d'ordre est utilisé pour relier l'identifiant de l'ordre dans MT5 à l'ordre sur la bourse au moment où l'ordre est placé sur la bourse.
Le terminal envoie une transaction concernant l'ajout d'un nouvel ordre dans l'état "commencé", qui peut être suivi dans OnTradeTransaction.

3. Ensuite, le serveur de négociation (via la passerelle) envoie votre ordre à la bourse, si la demande a été envoyée avec succès, votre demande recevra une réponse - cela signifie
"que la demande a été envoyée", les résultats seront exécutés de manière asynchrone, car vous ne savez pas à l'avance combien de temps la bourse va répondre.

Respectivement c'est à ce moment que vous voyez l'enregistrement dans le journal

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. Après un certain temps, la bourse fixe l'ordre dans son système, lui attribue un identifiant et en informe ensuite la passerelle et le serveur MT5.
Si la bourse a fixé l'ordre, l'identifiant de l'ordre est inscrit dans l'ordre dans MT5 et le statut de l'ordre change avec => placé.
Si l'échange refuse de passer une commande pour une raison quelconque, la commande sera supprimée.

Tout cela peut être suivi en enregistrant simplement les transactions entrant dans OnTradeTransaction.

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

Ce qui se passe :

1. Vous soumettez une demande de commande - voir les étapes 1 à 3.

2. au moment où l'ordre est déjà dans MT5, et qu'il n'est pas encore présent sur la bourse, vous envoyez un ordre pour retirer cet ordre.
Mais comme cette commande est dans son état initial (commencée) et que l'existence d'une commande pour celle-ci n'est pas définie, vous recevez un refus de retirer la commande
.

Vous devez effectuer les contrôles-corrections appropriés dans la logique de votre EA.


Z.U. L'autre chose est qu'en une seconde. 

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]
(et de plus pendant 20 secondes) la commande aurait dû être passée, ceci est en cours de traitement, un des problèmes potentiels a été trouvé - nous le corrigeons.
 
MQ Alexander:
Merci pour les explications ! Veuillez ajouter ceci à la documentation !
 
MQ Alexander:

Suite à la discussion sur le problème avec Michael au Service Desk :

Apparemment, nous devons expliquer comment fonctionne le système de commande et ce que signifie le placement.

Donc :

1. Vous envoyez une demande


2. Le serveur MT5 vérifie cette demande (paramètres, pre-trade, etc.). S'il y a un problème, vous obtiendrez un code d'erreur correspondant en réponse à la demande.

Après cela, vous créez une nouvelle commande en lui donnant un ticket (#24025010) - avec cela, l'état "commencé" est défini pour la commande. Le ticket d'ordre est utilisé pour relier l'identifiant de l'ordre dans MT5 à l'ordre sur la bourse au moment où l'ordre est placé sur la bourse.
Le terminal envoie une transaction concernant l'ajout d'un nouvel ordre dans l'état "commencé", qui peut être suivi dans OnTradeTransaction.

3. Ensuite, le serveur de négociation (via la passerelle) envoie votre ordre à la bourse, si la demande a été envoyée avec succès, votre demande recevra une réponse - cela signifie
"que la demande a été envoyée", les résultats seront exécutés de manière asynchrone, car vous ne savez pas à l'avance combien de temps la bourse va répondre.

Respectivement c'est à ce moment que vous voyez l'enregistrement dans le journal

4. Après un certain temps, la bourse fixe l'ordre dans son système, lui attribue un identifiant et en informe ensuite la passerelle et le serveur MT5.
Si la bourse a fixé l'ordre, l'identifiant de l'ordre est inscrit dans l'ordre dans MT5 et le statut de l'ordre change avec => placé.
Si l'échange refuse de passer une commande pour une raison quelconque, la commande sera supprimée.

Tout cela peut être suivi en enregistrant simplement les transactions entrant dans OnTradeTransaction.

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

Ce qui se passe :

1. Vous soumettez une demande de commande - voir les étapes 1 à 3.

2. au moment où l'ordre est déjà dans MT5, et qu'il n'est pas encore présent sur la bourse, vous envoyez un ordre pour retirer cet ordre.
Mais comme cette commande est dans son état initial (commencée) et que l'existence d'une commande pour celle-ci n'est pas définie, vous recevez un refus de retirer la commande
.

Vous devez effectuer les contrôles-corrections appropriés dans la logique de votre EA.


P.S. L'autre chose, c'est qu'en une seconde...

(et de plus, pendant 20 secondes) la commande doit être passée, nous nous en occupons, nous avons trouvé un des problèmes potentiels - réglons-le.
Nous ne comprenons toujours pas à quel moment l'état de l'ordre "commencé" se transforme en état "placé". Cela se passe-t-il selon le point 3 de votre explication, selon le point 4 de votre explication ou dans les deux cas, selon les points 3 et 4 ?
 
Yury Kirillov:
Il n'est pas clair à quel moment l'état de la commande "commencée" devient "placée". Cela se passe-t-il selon le point 3 de votre explication, selon le point 4 de votre explication ou dans les deux cas, selon les points 3 et 4 ?
MQ Alexander:

4. Après un certain temps, la bourse fixe l'ordre dans son système, lui attribue son identifiant, puis en informe la passerelle et le serveur MT5.
Si la bourse a fixé l'ordre - l'identifiant de l'ordre est inscrit dans l'ordre dans MT5, et l'état de l'ordre passe de commencé => placé.

 
MQ Alexander:

3. Ensuite, le serveur de négociation (via la passerelle) envoie votre demande à la bourse, si la demande a été envoyée avec succès, alors votre demande recevra une réponse, ce qui signifie que

"que la demande a été envoyée", les résultats de son travail seront exécutés de manière asynchrone, car vous ne savez pas à l'avance à quelle heure la réponse de l'échange sera donnée.

En conséquence, c'est à ce moment-là que vous voyez dans le journal de bord

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. Après un certain temps, la bourse fixe l'ordre dans son système, lui attribue un identifiant et en informe ensuite la passerelle et le serveur MT5.
Si la bourse a fixé l'ordre, l'identifiant de l'ordre dans MT5 est inscrit dans l'ordre dans MT5 et le statut de l'ordre change avec => placé.

Voici une autre raison de confusion : dans le journal, il est indiqué que la commande a déjà été passée, mais en fait son état n'a pas encore changé.

Peut-être devrions-nous écrire quelque chose comme "envoyé" au lieu de "placé" parce que la commande n'a pas été réellement acceptée par l'échange ?

 

Il en ressort ce qui suit.

Avant ( ou après ) d'effectuer toute action sur une commande,

vous devez "vérifier" son état à chaque fois (corrigez-moi si je ne suis pas sûr) :

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

Il en ressort ce qui suit.

Avant ( ou après ) d'effectuer toute action sur une commande,

vous devez "vérifier" son état à chaque fois (corrigez-moi si j'ai raté quelque chose) :

Faux,

Si nous regardons leHistoryOrderSelect( ticket ), alors nous devons appliquerHistoryOrderGetInteger(),HistoryOrderGetDouble()

 
Sergey Chalyshev:

C'est faux,

Si nous regardons dansHistoryOrderSelect( ticket ), nous devons appliquerHistoryOrderGetInteger(),HistoryOrderGetDouble()

C'est vrai, c'est une erreur d'impression :)

Merci, je l'ai corrigé...

1234567891011
Nouveau commentaire
Raison: