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

Nouveau commentaire
 

11.2Facturation des transactions erronées.

Les transactions sont considérées comme erronées si, au cours de la transaction, un code d'erreur tel que défini dans le tableau 2 lui a été attribué. Afin de déterminer les transactions erronées, on entend par transaction la soumission d'un Ordre, le retrait d'un Ordre, le retrait d'un Ordre avec soumission simultanée d'un Ordre avec des conditions de Transaction différentes, le retrait d'une paire d'Ordres avec soumission simultanée d'une paire d'Ordres avec des conditions de Transaction différentes.

Le calcul des Frais pour Transactions Erronées sera effectué pour chaque Login pour la période allant de la suspension de la négociation pour la session de compensation du soir du Jour de Négociation en cours (incluant la première seconde de suspension) à la suspension de la négociation pour la session de compensation du soir du Jour de Négociation suivant (n'incluant pas la première seconde de suspension) (ci-après - la Période de Calcul).

Le calcul du montant de la redevance pour transactions erronées est effectué selon la formule :

où :

TranFee2 - le montant de la redevance pour les transactions erronées effectuées pendant la période de règlement (en roubles, TVA comprise) ;

Cap - une limite sur le montant maximum de la redevance pour les transactions erronées, fixée par le Centre technique et publiée sur le site web de la Bourse de Moscou ;

xi- valeur calculée par seconde, arrondie aux nombres entiers et déterminée par la formule:

où :

Qi- la somme de tous les points pour la i-ème seconde (les points sont déterminés conformément au tableau 2);

Li- la limite du login donné, qui est calculée selon la formule et arrondie aux nombres entiers:

Où :

Capacitéi- capacité du login, déterminée conformément à la procédure stipulée au point 3.2 de la présente annexe, valable pour la i-ème seconde.

Tableau 2:

Type d'opération*.

Résultat de l'exécution (code d'erreur)*

Score Q

AddOrder

Une transaction croisée a eu lieu (31)

Q1

Fonds insuffisants des clients (332)

Q2

Fonds insuffisants de la société de courtage (333)

Q3

Offre FOK non consolidée (4103)

Q4

DelOrder

Commande non trouvée (14)

Q5

Ordre de déplacement

Des transactions croisées ont eu lieu (31)

Q6

Aucunordre n' a ététrouvé (50)

Q7

Fondsinsuffisants desclients (332)

Q8

Fondsinsuffisantsde lasociété decourtage(333)

Q9

DelUserOrders

La transaction a été effectuée avec succès,

et aucune commande n'est supprimée

Q10

* conformément à la description de la passerelle FORTS Plaza-2.

Les valeurs des points Q1-Q10 sont fixées par une décision du Centre technique et sont publiées sur le site Internet de la Bourse de Moscou.

Des frais pour les transactions erronées seront facturés si la condition est remplie :

où :

TranFee2 - le montant des frais pour les transactions erronées effectuées pendant la période de règlement (en roubles, TVA comprise) ;

Capmin- une restriction sur le montant minimum de la redevance pour les transactions erronées fixée par le Centre technique et publiée sur le site web de la Bourse de Moscou,

Les frais pour transactions erronées sont facturés à partir de la section du registre de compensation à laquelle est lié le login pour lequel les frais pour transactions erronées sont déterminés.

 
Seules les formules ne sont malheureusement pas insérées.
 
Dmitriy Skub:
Tu veux qu'on se saoule ?)) Est-ce si difficile d'écrire un chiffre ?
Alexey Kozitsyn a copié une partie du texte de cette disposition. C'est plus clair maintenant ? )) J'ai peur que vous deviez encore dormir si vous voulez le comprendre. ))
 

Quel est le code de retour pour cette erreur ?

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

Retour au code d'erreur "Requête invalide".

J'ai modifié la fonction pour supprimer un peu l'ordre :

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

Fonction 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;            
  }
}

Après avoir passé la commande :

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

Le serveur MT 5 n'a pas envoyé de réponse, la fonction CheckOrders() a été déclenchée et un ticket de commande a été reçu :

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

Après cela, la commande de suppression de l'ordre (EA) n'a PAS été exécutée :

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

Et cela a également été confirmé par le 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]

Question :

Quel est le statut de la commande dans la mémoire du terminal ?

Pourquoi une demande invalide ?

J'ai reçu un ticket de l'environnement du terminal, donc le terminal "sait" que la commande est fixée!

Après tout, plus tard, la même fonction a supprimé cette commande avec le même ticket :

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

Retour au code d'erreur "Requête invalide".

J'ai modifié la fonction pour supprimer un peu l'ordre :

Fonction CheckError().

Après avoir passé la commande :

Le serveur MT 5 n'a pas envoyé de réponse, la fonction CheckOrders() a été déclenchée et un ticket de commande a été reçu :

Après cela, la commande de suppression de l'ordre (EA) n'a PAS été exécutée :

Et cela a également été confirmé par le terminal :

Question :

Quel est le statut de la commande dans la mémoire du terminal ?

Pourquoi une demande invalide ?

(J'ai obtenu le ticket à partir de l'environnement du terminal, donc le terminal "sait que la commande a été passée") !

Il y a aussi ceci :

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

Essayez de cette façon :

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

Il y en a d'autres :

Sergei !

Pour une raison quelconque, il me semble que s'il y a une contravention (après qu'un mandat ait été délivré), il ne peut pas y avoir de

son état :

ORDER_STATE_REQUEST_ADD
 
Михаил:

Sergei !

Il me semble que s'il y a une contravention (après qu'un mandat ait été délivré), il ne peut y avoir...

Son statut :

Je le pense aussi, mais ce n'est pas mon idée, cette erreur provient du journal des transactions.

Après avoir ajouté cette vérification, mettez tous les états, avant la suppression et la modification, dans le journal. InvalidRequest ne se produit plus.

Cette question porte davantage sur les opérations du serveur et des développeurs, et sur la façon dontORDER_STATE_REQUEST_ADD apparaît.

 
Sergey Chalyshev:

Je le pense aussi, mais ce n'était pas mon idée, cette erreur provient du journal des opérations.

Après avoir ajouté cette vérification, mettez tous les états, avant la suppression et la modification, dans le journal. InvalidRequest ne se produit plus.

Cette question porte davantage sur les opérations du serveur et des développeurs, et sur la façon dontORDER_STATE_REQUEST_ADD apparaît.

Il doit y avoir un délai d'attente assez long dans le terminal pour la réponse du serveur...
1234567891011
Nouveau commentaire