FIX 4.4 : TimeInForce <59> field
Type: char
Used In
Description
Specifies how long the order remains in effect. Absence of this field is interpreted as DAY. NOTE not applicable to CIV Orders.
Valid values:
0 = Day (or session)
1 = Good Till Cancel (GTC)
2 = At the Opening (OPG)
3 = Immediate or Cancel (IOC)
4 = Fill or Kill (FOK)
5 = Good Till Crossing (GTX)
6 = Good Till Date7 = At the Close
頭を悩ます...ストップがどうしても決まらない...エラーも多い。これが実験の残骸で、もううまくいかない
このようにすると、エラーは出ませんが、ストップロスが設定されないままです
どうやら、前回の問題をあまり明確に説明していなかったようです。もう一回やらせてください。
この1年間で、ENUM_ORDER_TYPE_FILLING 列挙値リストの記述が少なくとも3回変更された。 以前の記述は次の通りであった。
enum_order_type_filling
識別子
商品説明
オーダーフィリングフォック
取引は、指定された数量と、注文で指定された価格と同等かそれ以上の価格でのみ実行されます。もし、その注文シンボルに対して十分な供給がその時点で市場にない場合、その注文は成立しません。この充填タイプは 、 SYMBOL_TRADE_EXECUTION_INSTANT 実行モード または SYMBOL_TRADE_EXECUTION_REQUESTで使用さ れます。
オーダーフィリング
注文で指定された数量の範囲内で、市場で入手可能な最大の数量で、注文で指定された価格と同等以上の価格で取引を執行する契約です。この場合、不足分の追加注文は行いません。このフィリングタイプは 、トレードサーバーの設定により、実行モードSYMBOL_TRADE_EXECUTION_MARKET およびSYMBOL_TRADE_EXECUTION_EXCHANGE においてのみ利用 可能です。
オーダーフィリングリターン
注文で指定された数量の範囲内で、市場で入手可能な最大の数量で、注文で指定された価格と同等かそれ以上の価格で取引を行うことを約する。この場合、不足分の数量について、本注文で指定された価格で追加注文が行われます。このフィリングタイプは、保留中の注文（TRADE_ACTION_PENDING）に対してのみ使用 されます。
簡単にわかるように、ORDER_FILLING_RETURNと保留中の注文は 一対一で対応しています、つまり。 ORDER_FILLING_RETURNは保留中の注文にのみ適用され、すべての 保留中の注文の type_filling フィールドはORDER_FILLING_RETURNの 値のみで埋められる可能性があります。
成行注文（action==TRADE_ACTION_DEAL）の場合、サーバー側で設定された執行モードに応じて、type_filling フィールドが入力されているはずです。
つまり、保留中の注文があればORDER_FILLING_RETURN、成行注文が あれば ORDER_FILLING_FOKまたはORDER_FILLING_IOC（モードによる）というように、一定のパラダイムがあったのです。
今、すべてが少しひっくり返った、すなわち
enum_order_type_filling
識別子
商品説明
オーダーフィリングフォック
このオーダーフィリングポリシーは、指定された数量までしかオーダーを満たすことができないことを意味します。その時点で市場に十分な量の金融商品がない場合、注文は執行されません。必要なボリュームは、現在市場にある複数のオファーからまとめることができます。
オーダーフィリング
注文で指定された数量の範囲内で、市場で入手可能な最大の数量まで取引を行うことに同意することを示す。完全な執行が不可能な場合、注文は利用可能な数量まで満たされ、満たされていない数量はキャンセルされます。
オーダーフィリングリターン
このモードは、ORDER_TYPE_BUY_LIMITとORDER_TYPE_SELL_LIMITの注文にのみ使用されます。部分約定した場合、残りの数量の指値注文は削除されず、有効なままとなります。
ORDER_TYPE_BUY_STOP_LIMITとORDER_TYPE_SELL_STOP_LIMIT注文に対応するORDER_TYPE_BUY_LIMIT/ORDER_TYPE_SELL_LIMITリミットオーダーで実行タイプが ORDER_FILLING_RETURN のものは起動時に作成されることになります。
ORDER_FILLING_FOKとORDER_FILLING_IOCは、成行注文でのみ 使用するという制約がなくなりました。 また、ORDER_FILLING_FOKとORDER_FILLING_IOCは、サーバーで設定された実行モードによっては、成行注文で 使用することに制限はない。 ORDER_FILLING_RETURNは、指値注文と逆指値注文でのみ 使用できるという制約があります。
そこで質問なのですが、指値・逆指値注文を含むすべての注文（成行・保留ともに）に対して、 ORDER_FILLING_FOKと ORDER_FILLING_IOCを全く 使用しなくても良いのでしょうか。どなたか変更点を把握された方はいらっしゃいますか？
うん、この問題に関しては、ちょっと不透明だね。
ENUM_SYMBOL_TRADE_EXECUTIONと ENUM_ORDER_TYPE_FILLINGが 完全に対応している場合、2番目のものは明らかに不要で ある。
したがって、道徳性はなく、1つの 同じENUM_SYMBOL_TRADE_EXECUTIONの 値で異なる ENUM_ORDER_TYPE_FILLINGの 値を許容 することがほとんどである。MQはここに可能性のあるテーブルを記述するが、ほとんどの場合、このデータはディーリングサーバーの設定に依存する。
そして、それゆえに2つ目のモラル、結局のところ何が必要なのか。
要求された注文タイプ（即時または保留）に対して、有効なオプションのリスト（ENUM_ORDER_TYPE_FILLING）を返す関数が必要 である。
そこにはあまり選択肢がないので、「｜」経由でintを突っ込むといい。
もし私が間違っていたら、この質問はどこを見ればいいのか、魔法の魔法使いを教えてください。
この疑問を解決するために、私は（習慣として、他の人がどのようにしているかを見て明確でない場合）標準ライブラリに 行きました。
CTrade クラスでは SetTypeFilling() は使用されず、type_filling フィールドはデフォルトのゼロで初期化され、列挙によるとORDER_FILLING_FOK に対応することになるため、便利な継承関数が与えられました。
それだけで、もう仕事はありません。そして、このフィールドはインターフェースに存在しないので、クラスで自動充填されているということだと思いました。
SZY全般、回答待ち、修正方法 :)今のところ、解決策は一つです。
腹を抱えて笑った、良い夜のエンターテイメント。
中国人が国防総省のメインサーバーをハッキングした。
チャイナマンなら誰でも一度はパスワード入力に挑戦したことがあるはずだ。
他の人はみんな "Mao Tse Tung "と入力した。
5*10^7回の試行で、サーバーはパスワードが "Mao Tse Tung "であると言っています。
今のところ、正しい答えが出るまでサーバーを叩くというのが一つの方法だと考えています。
バカの一つ覚え
まず、DCに相談し、どのような実行形式を サポートしているか、その実行形式に対応するメタクォートリストの種類を確認する必要があります。
というのも、metaquotesが3種類のフィルと3種類のタイムを思いついたからといって、それが実際のブローカーで注文を出すときの現実を反映しているとは言えないからです。
バカの一つ覚え
まず、DCに相談し、どの実行タイプを サポートしているか、どのメタクオートリストタイプがその実行タイプに対応しているかを確認する必要があります。
というのも、metaquotesが3種類のフィルと3種類のタイムを思いついたからといって、それが実際のブローカーで注文を出すときの現実を反映しているとは言えないからです。
それこそ、サーバーの設定次第でどうにでもなりますよ。
しかし、すべての証券会社をノックするのも問題です。
例えば、ある証券会社では、実際の仲介のための注文を受けるかもしれません。
が、全てをバイパスしてコードにスイッチディリングを書くのはやり過ぎです。
すでに登録済みと思われる方は、リアルブローカーで一から開設していただいても構いませんし、ゼロから開設していただいても結構です。
PS 通常のコードは、どんなディーリングに対しても、例外はあり得るが、最初は例外がルールを確認し、次に例外があれば例外を書かなければならない、という統一された方法で書かれていることに同意されますか？
ここで、そんな同語反復が判明した。
私が言いたいのは、すべてはサーバーの設定に依存するということです。
しかし、各証券会社にノックするのは問題でしょう。
両者の違いがわからないと、注文が正しいものにコピーされると思うかもしれません。
が、全てをバイパスしてコードにスイッチディリングを書くのはやり過ぎです。
PS 通常のコードは、どのような取引にも対応できるように統一された方法で書かれていることに同意してください。
PS 通常のコードは、どんなディーリングに対しても、例外はあり得るが、第一に例外はルールを確認するだけであり、第二に例外があれば例外を書かなければならないことに同意されるのですね。ここで、そんな同語反復が判明した。
ということです。
メタクォートは、実行タイプと実行時間がめちゃくちゃです。現実には、IOCとFOKの注文は実行時間を参照しているという意味で、非標準です。
注文の実行タイプは、以前はAON.と十分に名付けられていましたが、その後削除されました。
FCが利用し、注文を実行するFIXの仕様に注目
メタクォータを取ったタイプにマークを付けましたが、ご覧の通り、それらはすべてTimeInForce タグ<59>の1つのグループになっています。
そして今度は、市場で入札を行うブローカーが、MT注文でプット型IOCと時間GTDをどのように処理するのか、教えてください。なぜなら、これは2つの異なるフィールドではなく、1つの フィールドだからです。
したがって、フィリングをどうするか、どのようなタイプにするか、どのように注文を取り消すかは、各ブローカーが自分で考えることになります。
唯一の救いは、成行注文と保留注文の 違い、つまり、保留注文にのみ使用される注文執行のタイプと、成行注文に使用されるタイプがあることです。 一般的には、この点に着目して議論する必要があります。
All-Or-Nothingという名前は全く別のタグExecInst <18>にあり、MTの順番では一切渡されない。FOKタイプでは暗黙のうちに（おそらく）想定されています。
...
このトピックはアレックスが引き継いでください。私は残念ながら、このような問題には浮き足だってしまうのです。
SDに提案する、話をする。
トピックを何らかの形で整理する必要があります。
今あるものは、プロのプログラミングには全く使えないものです。
アレックス、このトピックを引き継いでください。私は、残念ながら、このようなことに泳いでいます。
sdに提案する、話をする。
話題を整理する必要がある。
今あるものが、プロのプログラミングに適しているかどうかはわかりません。
私がバカなのか、スキーが走らないのか、どちらかです。
毎月、methaquotesが新しい取引所や市場に接続していることがお分かりになると思います。
ということは、この状態では、プログラマーはMTとFIXを問題なく（あるいはどちらかの制限で多少無理をして）ドッキングさせているのだろうと結論づけられる。
つまり、FOKとGTCの時間タイプを組み合わせることができるわけで、作業中である以上、当面は何も変わることはないだろうということだ。
同時に、MTからの交換ブリッジは、AONかPartialの2種類しか設定できないと理解している。そして、MT Returnで発明された - おそらくPartialに行く。
一般的に、相互作用のFIXブローカーとMTサーバの問題は、MTからプロバイダにブリッジを作るブローカでスキルと理解プロジェの平面にある。 そして、私は彼らが長いと積極的に市場にプラットフォームを推進しているため、メタ引用符が、何かを変更するとは思わないので、MTサーバの内部構造は非常に現実に一致している。