質問掲示板
岡三RSS
集いの広場

「何もトリガーが無いのに条件決済される」と書きましたが、前回のようにExcelを再起動したときには決済されなかったのですが、もしかしたら以下の点がトリガーだったのかもしれません。

・夜中03:01と日中15:01に決済されていた時があった
　→Excelがフリーズしないよう、毎日03:00と15:00にマクロで岡三RSSを再起動しているのが何らかの影響を与えているのかも

・新規約定した際に即条件決済されていた
　→新規約定したことが何らかのトリガーになっていた？

たった今も見ていたら、16:30の新規注文時に、条件決済が起動していたので、明らかにそれがトリガーになっているのかもしれません。この時はたまたま？売買区分が正しくないというメッセージが出て、決済されずに済みましたが。。。

やはり、Excelの処理する順番が不定なので、条件決済が走っている感じなので、もっと条件を追加して誤作動を防ぐ必要があるのかもしれません。

お知恵をお貸しください。よろしくお願いします。

2019年03月20日

けんさん、お久しぶりです！！

内容からすると、前回のIFSの時みたいに起動後にもしかしたら決済がかかってしまってるのかもですね・・・

Excelファイルを観てみたいのですが、
あげて頂いたファイルが、壊れてるみたいで開けませんでした・・・
もう一度、あげて頂けますと幸いでーす。

また、今お仕事でトラブってて・・・
毎日午前様です・・・(しくしく
返答が遅くなってしまう可能性が大なことをご容赦ください・・・(ごめんなさい

2019年03月21日

RSS日経225mini0322.xlsx (402.2KB)

Ryo Ohnoさんおはようございます。
返信いただきありがとうございます！

前回、修正いただいてから多少はいじりましたが、計算式の基本の部分はほぼ変えてないので何がいけないのかさっぱり。。。

ファイルを再度添付いたしました。
　（普段は岡三RSSを再起動するマクロを有効として.xlsmの拡張子なのでそれをここに添付しようとしたら、添付出来ないエラーになったのでファイル名を.xlsxにリネームしたのですが、それだとファイルが開けないのですね。。。）
　（ここに添付はできないけど、.xlsmのエクセルファイルは実用上は問題なく使えるのですよね？）

お仕事が忙しいのに申し訳ありません。
もしお手すきの時があれば見てみてください。

2019年03月22日

Ryo Ohnoさん、こんばんは。けんです。

お忙しいのに本当にいつもありがとうございます。
説明の吹き出しを確認しましたが、私にも理解できました。

しばらくいただいた対策で実施してみます。
また何かありましたらご連絡いたします。

本当にありがとうございます！！！


　

2019年03月25日

Ryo Ohnoさん、こんばんは。
残念ながらまだ駄目でした。。。。。。

ポジションを保有、ロスカット利食いの条件に達していない状態で、岡三RSSとExcelを再起動した際、同時に条件決済が走りました。

１度目は（1日1回の今日付けの発注IDで）即決済が走りました。
（この時は売買区分か取引区分が違うというメッセージで決済されず）

上記の後、同様にExcelと岡三RSSを再起動した際に、昨日付けの発注IDで）再度条件発注が誤って走ってしまいました。
（この時も決済建玉がありません、エラーで決済されず）

条件を満たしてないのに条件発注がされてしまう現象に変わりありませんでした。（泣）
＃なので肝心な時に決済が走らないのです。。。

この状況にて他に対策はありますでしょうか？

何度も申し訳ないのですが、よろしくお願いします。

2019年03月26日

その後繰り返しの検証で分かったこと（備忘録です）

・Excelを再起動後、岡三RSSを起動してログインすると、3回に1回程度の割合で誤発注が起きている
・誤発注のほとんどは「注文エラー：建玉がありません」となるが、たまにエラーにならずに発注されてしまう
・岡三RSSを起動したまま、Excelを再起動しても誤発注は起きない

まとめ：ログイン直後のタイミングで誤発注（注文エラーor正常注文）が起きる場合がある（毎回ではない）

ちなみに以前、複数ではなくひとつの建玉のみで条件発注していた時はこのタイミングでの誤発注は無かった

2019年03月26日

備忘録追加
タスクスケジューラで毎日15時と3時に岡三RSSを再起動させていて、その直後に誤発注されたことがあったので、やっぱりトリガーはログイン直後にFOPPOSITION関数で値を取得した時か。。。

2019年03月26日

Ryo Ohnoさん、こんばんは。
ようやくお仕事が一段落したんですね。よかったです。

はい、A38が注文用のセルで、B38は文字列セルで表示用です。
A38にB38の式をコピーしてるのでそこが原因ではないと思われます。

また、誤動作しているのはA38セルだと思っています。
（誤発注時のエラーメッセージの発注IDで確認済みです）
が、誤発注がエラーにならず発注されたときはエラーメッセージが無く、発注IDが分からないので、A25が誤動作している可能性も捨てきれませんが、たぶん違うと思っています。
　＃どちらが誤動作しているか検証する方法はあるのでしょうか？

それと念のため確認させて下さい。
Ryo Ohnoさんに今回修正いただいたのは下記２か所ですよね？

→A38セルとL20-L26セル

その2か所を普段使用しているファイルにコピペしたのですが、もしかしたら他の部分も修正しているなんてことはないでしょうか？
　＃念のため確認です。

以上、よろしくお願いします。
　＃いつもすいません、ありがとうございます。

2019年03月31日

マザーズは実質ロスカットが効かない価格設定にしていたので、A38の条件決済のセルは無効にしていました。
なので誤発注が起きているのはN225ミニしーとだけになります。
そしてまた今朝も8:04に誤動作で発注されてしまい、それに気づかずに8:45に決済されてしまいました。
一体これでいくら損害が出ているのか。。。（泣）

マクロについてはよく分からないのですが、NOW関数の現在時刻がフリーズして止まることがよくあり困っていたので、時計が止まらないためのマクロをネットでググって仕込んでいます。
　＃もしかしてこれが原因だったりするでしょうか。。。

'===================================================
Private tm As Double
Sub 更新()
Application.Calculate
tm = [now()+timevalue("00:01:00")]
Application.OnTime tm, "更新"
End Sub
'=====================================================
Sub 更新やめ()
Application.OnTime tm, "更新", , False
End Sub

上記のマクロの良しあしを含めて、対処療法のマクロについても教えていただければと思います。

2019年04月01日

それともう一点気になることがあります。

FOPPOSITION関数で取得した値をF20-K25の表で表示させているのですが、更にvlookup関数でその値を拾いF40-L40に表示させて、そこをA38セルの式が参照して条件決済しています。

F40-L40の方にも、L20-L26のTrue/Falthのような仕掛けを入れなくても大丈夫でしょうか？
少し気になったので念のための確認です。

2019年04月01日