へろへろ
NT両建て決済注文で方玉のみ残る
こんにちは
N225ミニとTOPIXミニの差額（サヤ）の取引シートを岡三RSSで作りました。
新規建ては、5分足終値のNT差額が希望額になったときに建玉します。決済は、建玉の合計「評価損益額」が利食いの評価益額に達するか、損切りの評価損額に達した場合、セルにサイン「１」を表示させ、別の二つのセル内の225,Topixの両方の発注関数を同時に有効化して建玉決済を行うというものです。決済の「評価損益額」の計算には分足データではなく、Fpositionで導き出した評価損益額の合計を使用しています。
起こった問題ですが、決済時、片玉のみしか決済されない事例が現れました。これは、価格の変動により、発注条件が一瞬だけ満たされた場合に起きる現象なのだろうと想像しています。このような現象で、片玉だけ残る事態を避けるための工夫や知恵や、現在の仕組みへのダメ出しがあればコメントいただければと思っています。
このシート（ブック）で、マクロは「マクロの記録」で利用できるものを加工したものしか使っておりません。VBA知識は乏しいです。
また、別件ではありますが、Fpositionで導いた建玉情報が、建玉がなくなった後でも、表示先に残ることが頻繁にあり、個別に消去しています(Ordqueryでも起こるようです)。
対策があれば情報いただければと思います。
2020年03月10日
大野 了
へろへろさん、こんにちは！！
ちなみにこちらは、毎回発生しますでしょうか？
それとも、時々発生する感じになりますでしょうか？
状況を考えますと、2つ原因が考えられると思いました！！
１．へろへろさんの想像されている現象でサイン『1』が一瞬しか出ないため、片側しか決済がかからなかった
こちらは
１．一瞬決済の『１』が表示される
２．２２５だけ決済
３．『１』が消える
４．その後にTopixの判断
という動きになると、へろへろさんがおっしゃられてる動作になりそうです。
２．片側が証券会社側、もしくは岡三RSSの発注時にエラーになってしまっている
１の場合は、サインの1をN225、Topix両方で見るのではなく、どちらか片方にして、
もう片方は、その発注が完了されたかどうかを見るのが対応としては簡単だと思います。
=====================================================
A1：サインのセル
B1：N225の決済用セル
C1：Topixの決済用セル
とした場合
B1：＝IF(A1＝1,FNEWORDER(225),"待機")
C1：＝IF(B1＝"発注完了",FNEWORDER(Topix),"待機")
としてあげれば、N225の決済発注であるB1の発注が行われたことをトリガーにTopixの発注がされるため、
片バリになることを防げると思います！！
=====================================================
２の場合は、ネットトレーダや、ORDQUERY、ORDERRESULTを使用すると
発注エラーが発生していた場合、その内容を見ることができます！！
もしエラーが片方の発注が取り消されている場合は、エラーを教えて頂けますと
何かしら対応の提案ができると思いまーす！！
>また、別件ではありますが、Fpositionで導いた建玉情報が、建玉がなくなった後でも、表示先に残ることが頻繁にあり、個別に消去しています(Ordqueryでも起こるようです)。
自分もFOPPOSITIONなど使っていますが、今のところ発生していません。
ちなみに2/22以前から発生してますでしょうかー？
2020年03月10日
へろへろ
大野様
早速のご回答をいただき感謝いたします。
2つのケースを挙げていただきました。
今までに、数回ですが、決済で使用していて初めてのことです。また、発注エラーは見受けられない（よう）です。 １のケースなのかと思います。
この場合、戻り値の ”発注完了” を利用しろというご指摘をいただきました。自分では思い付きもしませんでした。やってみます。ありがとうございました。
別件の、旧データが表示先に残る件ですが。png 画像ファイルでお示しします。この画像の場合はNTとも正常に決済され、ミニTOPIXについても決済後で建玉がない状態です。Nの建玉のあった13行めは、***END***となっていますが、その下の2行はNT両建玉のあったときのままの表示になっています。毎回（だと思いますが）手入力で消すため、運用の妨げとなります。
ひょっとしたら、もともと、決済があった後は、13行目以下をクリアして使用すべきものでしょうか。
2020年03月10日
大野 了
へろへろさん、こんにちは！！
決済発注はエラーではなくそもそもされてないんですねー
でしたら、"発注完了"を見ることにより何とかなると思います。
うまくいくことを祈ります！！
旧データが残る件ですが、これのことだったんですねー
通常は消さなくても、自動で消えるようですが、
ポジションが大きく動いたときにたまに残るようです。
この現象はたまに自分も起きています。
とはいえ、頻繁には起きないです・・・
対策としては、へろへろさんのおっしゃいます通り、13行目以降を消して頂くか
Lookup関数や、sum関数の範囲を、
一番初めに出てくる『***End***』までにすることでしょうかー
確かにこれ、確実に消してほしいですね・・・
2020年03月10日
sakai
＞Lookup関数や、sum関数の範囲を、
＞一番初めに出てくる『***End***』までにすることでしょうかー
＞確かにこれ、確実に消してほしいですね・・・
この仕様については今のままの方が良ろしいかと思います
Lookup関数や、sum関数の範囲を、一番初めに出てくる『***End***』までにする*べき*です
ご存じのようにシートへの書き込み（clear）は時間がかかります
RSSに余計な作業をさせると注文がスリップする可能性が高くなります
私は株取引でRSSを使っていますが1注文の出来が分割出来となり、多いときは複数銘柄でPOSITIONが１００行ほどになります 市場の超高速なシステムを相手に戦っていますので、少しでも高速な処理を希望します
RSS開発者が変な気を起こさないようにしたいものです
前回の株注文の表示関数化version-upのようなことがないようにお願いします(その後macro機能を復活していただきました)
老婆心ながら
2020年04月11日
大野 了
ポジションが100銘柄ですかー！！
さかいさん相変わらず、すごいですね・・・
なるほどー
確かにそこまでポジションがあると、ちんたらされると困るので、
高速性の要求も高くなりますね。
2020年04月13日
へろへろ
度々のご返信ありがとうございました。
2020年03月10日
大野 了
少しでもお役に立てれれば幸いです！！
わかり辛い点もあると思いますので、何かあればご連絡頂けますと幸いです！！
2020年03月10日