FORTS: OnTradeTransaction() のリターンコード - ページ 5 1234567891011 新しいコメント 削除済み 2015.11.14 11:27 #41 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)Q3FOKの入札が連結されない(4103)Q4デルオーダー注文が見つかりません (14)Q5MoveOrderクロスディーリングが発生した (31)Q6注文が見つからなかった(50)Q7顧客資金の不足 (332)Q8証券会社の資金不足(333)Q9DelUserOrders取引は正常に終了しました。であり、順序が削除されることはありませんQ10* FORTS Plaza-2 Gatewayの記載に準ずる。Q1-Q10のポイント値は、テクニカルセンターの決定により決定され、モスクワ取引所のホームページで公開されます。この条件に該当する場合、誤送信手数料が発生します。のところです。TranFee2 - 決済期間中に行われた誤った取引に対する手数料の金額 (付加価値税を含むルーブル) です。Capmin- テクニカルセンターが設定し、モスクワ取引所のウェブサイト上で公開される過誤取引に対する手数料の最低額の制限。過誤取引に関する手数料は、過誤取引に関する手数料が決定されたログインがリンクされているクリアリングレジスター部分から請求されます。 FORTS: OnTradeTransaction() return codes 削除済み 2015.11.14 11:29 #42 数式だけは残念ながら挿入されません。 kond777 2015.11.16 20:52 #43 Dmitriy Skub: 酔っぱらうか?))フィギュアを書くのはそんなに大変なんですか?Alexey Kozitsynは、この条項のテキストの一部をコピーした。明確になったのでしょうか?))理解しようと思えば、やはり寝るしかないでしょう。)) kond777 2015.11.18 15:12 #44 このエラーのリターンコードは何ですか?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 Инструмент отсутствует в текуще Mikhail Filimonov 2015.11.25 13:44 #45 無効なリクエストのエラーコードに戻る注文を削除する機能を少し変更しました。//+------------------------------------------------------------------+ // 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 Sergey Chalyshev 2015.11.25 14:13 #46 Михаил:無効なリクエストのエラーコードに戻る注文を少し削除する機能に変更しました。CheckError()関数。注文後MT5サーバーから応答がないため、CheckOrders()関数が起動し、オーダーチケットを受信しました。その後、注文(EA)を削除するコマンドは通りませんでした。そして、このことは端末でも確認された。質問です。端末のメモリーに残っているオーダーは 何ですか?なぜ無効なリクエストなのですか?(端末環境からチケットを取得したので、端末は「注文があったことがわかる」)!また、こんなこともあります。2015.11.24 17:07:15.020 FORTS (MXI-12.15,M5) ORDER_STATE = ORDER_STATE_REQUEST_ADD Sergey Chalyshev 2015.11.25 14:23 #47 この方法で試してみてください。if(!(OrderGetInteger(ORDER_STATE)==ORDER_STATE_PARTIAL || OrderGetInteger(ORDER_STATE)==ORDER_STATE_PLACED)) return; Mikhail Filimonov 2015.11.25 14:25 #48 Sergey Chalyshev:まだまだありますよ。セルゲイ!なぜか、チケットがあれば(令状が発行された後)、ありえないような気がします。その状態 ORDER_STATE_REQUEST_ADD Sergey Chalyshev 2015.11.25 14:38 #49 Михаил:セルゲイ!なんとなくですが、(令状が発行された後に)チケットがあればその状態。 私もそう思うのですが、私の考えではなく、このエラーはトランザクションログからのものです。このチェックを追加した後、削除前と変更前のすべての状態をログに記録します。InvalidRequestは発生しなくなった。この質問は、ORDER_STATE_REQUEST_ADDが どのように表示されるかについて、サーバーオペレーションと開発者により多く関係しています。 Mikhail Filimonov 2015.11.25 14:55 #50 Sergey Chalyshev:私もそう思うのですが、私の考えではなく、このエラーは操作ログからのものです。このチェックを追加した後、削除前と変更前のすべての状態をログに記録します。InvalidRequestは発生しなくなった。この質問は、ORDER_STATE_REQUEST_ADDが どのように表示されるかについて、サーバーオペレーションと開発者により多く関係しています。 サーバーからの応答を待つ端末のタイムアウトがかなり長いのでは...? 1234567891011 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
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- テクニカルセンターが設定し、モスクワ取引所のウェブサイト上で公開される過誤取引に対する手数料の最低額の制限。
過誤取引に関する手数料は、過誤取引に関する手数料が決定されたログインがリンクされているクリアリングレジスター部分から請求されます。
酔っぱらうか?))フィギュアを書くのはそんなに大変なんですか?
このエラーのリターンコードは何ですか?
無効なリクエストのエラーコードに戻る
注文を削除する機能を少し変更しました。
CheckError()関数。
注文後
MT5サーバーから応答がないため、CheckOrders()関数が起動し、オーダーチケットを受信した。
その後、注文(EA)を削除するコマンドは通りませんでした。
そして、このことは端末でも確認された。
質問です。
端末のメモリーに残っているオーダーは 何ですか?
なぜ無効なリクエストなのですか?
端末環境からチケットを受け取ったので、端末は注文が決まっていることを「知っている」のです
結局、後日、同じ機能でこの注文を同じチケットで削除してしまった。
無効なリクエストのエラーコードに戻る
注文を少し削除する機能に変更しました。
CheckError()関数。
注文後
MT5サーバーから応答がないため、CheckOrders()関数が起動し、オーダーチケットを受信しました。
その後、注文(EA)を削除するコマンドは通りませんでした。
そして、このことは端末でも確認された。
質問です。
端末のメモリーに残っているオーダーは 何ですか?
なぜ無効なリクエストなのですか?
(端末環境からチケットを取得したので、端末は「注文があったことがわかる」)!
また、こんなこともあります。
この方法で試してみてください。
まだまだありますよ。
セルゲイ!
なぜか、チケットがあれば(令状が発行された後)、ありえないような気がします。
その状態
ORDER_STATE_REQUEST_ADD
セルゲイ!
なんとなくですが、(令状が発行された後に)チケットがあれば
その状態。
私もそう思うのですが、私の考えではなく、このエラーはトランザクションログからのものです。
このチェックを追加した後、削除前と変更前のすべての状態をログに記録します。InvalidRequestは発生しなくなった。
この質問は、ORDER_STATE_REQUEST_ADDが どのように表示されるかについて、サーバーオペレーションと開発者により多く関係しています。
私もそう思うのですが、私の考えではなく、このエラーは操作ログからのものです。
このチェックを追加した後、削除前と変更前のすべての状態をログに記録します。InvalidRequestは発生しなくなった。
この質問は、ORDER_STATE_REQUEST_ADDが どのように表示されるかについて、サーバーオペレーションと開発者により多く関係しています。