FORTS: OnTradeTransaction() のリターンコード - ページ 5

 

11.2誤った取引に対する課金

取引の過程で、表2に示すエラーコードが割り当てられた場合、取引は誤りと認識されるものとする。誤発注の判定において、取引とは、注文の提出、注文の取消、取引条件の異なる注文の同時提出を伴う注文の取消、取引条件の異なる2つの注文の同時提出を伴う2つの注文の取消を意味するものとする。

過誤取引に関する手数料の計算は、当取引日の イブニング清算セッションの取引停止(停止1秒前を含む)から翌取引日のイブニング清算セッションの取引停止(停止1秒前を含まない)までの期間(以下「計算期間」)についてログイン毎に行うものとする。

誤取引に対する手数料の額の算定は、次の算式により行うものとします。

のところです。

TranFee2 - 決済期間中に行われた誤った取引に対する手数料の金額(付加価値税を含むルーブル)です。

キャップ - テクニカルセンターが設定し、モスクワ取引所のウェブサイト上で公開される過誤取引に対する手数料の上限額。

xi- 1秒間に計算される値で、整数に切り捨てられ、数式で決定 される。

のところです。

Qi- i番目の秒の全ポイントの合計(ポイントは表2にしたがって決定される)

Li- 与えられたログインの限界値.数式に従って計算され,整数に丸められた もの.

どこで

容量i- 本付属書3.2に規定される手順に従い決定されるログインの容量で、i番目の秒に有効な もの。

表2:

トランザクションの種類*。

実行結果(エラーコード)*。

スコアQ

注文の追加

クロス取引が発生した(31)

Q1

顧客資金の不足 (332)

Q2

証券会社からの資金不足(333)

Q3

FOKの入札が連結されない(4103)

Q4

デルオーダー

注文が見つかりません (14)

Q5

MoveOrder

クロスディーリングが発生した (31)

Q6

注文が見つからなかった(50)

Q7

顧客資金の不足 (332)

Q8

証券会社の資金不足(333)

Q9

DelUserOrders

取引は正常に終了しました。

であり、順序が削除されることはありません

Q10

* FORTS Plaza-2 Gatewayの記載に準ずる。

Q1-Q10のポイント値は、テクニカルセンターの決定により決定され、モスクワ取引所のホームページで公開されます。

この条件に該当する場合、誤送信手数料が発生します。

のところです。

TranFee2 - 決済期間中に行われた誤った取引に対する手数料の金額 (付加価値税を含むルーブル) です。

Capmin- テクニカルセンターが設定し、モスクワ取引所のウェブサイト上で公開される過誤取引に対する手数料の最低額の制限

過誤取引に関する手数料は、過誤取引に関する手数料が決定されたログインがリンクされているクリアリングレジスター部分から請求されます。

 
数式だけは残念ながら挿入されません。
 
Dmitriy Skub:
酔っぱらうか?))フィギュアを書くのはそんなに大変なんですか?
Alexey Kozitsynは、この条項のテキストの一部をコピーした。明確になったのでしょうか?))理解しようと思えば、やはり寝るしかないでしょう。))
 

このエラーのリターンコードは何ですか?

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

無効なリクエストのエラーコードに戻る

注文を削除する機能を少し変更しました。

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

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

注文後

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

MT5サーバーから応答がないため、CheckOrders()関数が起動し、オーダーチケットを受信した。

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

その後、注文(EA)を削除するコマンドは通りませんでした。

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

そして、このことは端末でも確認された。

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]

質問です。

端末のメモリーに残っているオーダーは 何ですか?

なぜ無効なリクエストなのですか?

端末環境からチケットを受け取ったので、端末は注文が決まっていることを「知っている」のです

結局、後日、同じ機能でこの注文を同じチケットで削除してしまった。

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

無効なリクエストのエラーコードに戻る

注文を少し削除する機能に変更しました。

CheckError()関数。

注文後

MT5サーバーから応答がないため、CheckOrders()関数が起動し、オーダーチケットを受信しました。

その後、注文(EA)を削除するコマンドは通りませんでした。

そして、このことは端末でも確認された。

質問です。

端末のメモリーに残っているオーダーは 何ですか?

なぜ無効なリクエストなのですか?

(端末環境からチケットを取得したので、端末は「注文があったことがわかる」)!

また、こんなこともあります。

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

この方法で試してみてください。

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

まだまだありますよ。

セルゲイ!

なぜか、チケットがあれば(令状が発行された後)、ありえないような気がします。

その状態

ORDER_STATE_REQUEST_ADD
 
Михаил:

セルゲイ!

なんとなくですが、(令状が発行された後に)チケットがあれば

その状態。

私もそう思うのですが、私の考えではなく、このエラーはトランザクションログからのものです。

このチェックを追加した後、削除前と変更前のすべての状態をログに記録します。InvalidRequestは発生しなくなった。

この質問は、ORDER_STATE_REQUEST_ADDが どのように表示されるかについて、サーバーオペレーションと開発者により多く関係しています。

 
Sergey Chalyshev:

私もそう思うのですが、私の考えではなく、このエラーは操作ログからのものです。

このチェックを追加した後、削除前と変更前のすべての状態をログに記録します。InvalidRequestは発生しなくなった。

この質問は、ORDER_STATE_REQUEST_ADDが どのように表示されるかについて、サーバーオペレーションと開発者により多く関係しています。

サーバーからの応答を待つ端末のタイムアウトがかなり長いのでは...?