Глюк с выставлением заявки по рынку

[ddd323]

Финам. Фортс. Фьюч на сбер SBRF-12.12
HFT сервер. версия терминала 304.12 (UID послал в личку Heller'у)
Заявка высталялась из onNewCandle на свече 14.03 сегодня (13.12.12) так:
var OrdrHash = new_object("hash"); OrdrHash["quantity"] = 1; OrdrHash["operation"] = OP_BUY; trade_action::transactMultiple(OrdrHash);
Денег на счете достаточно.
Получил в onATFOrderErr следующее:
SBRF-12.12 (sbrf1): Некорректный ордер: (10032) Цена сделки вне лимита Покупка  SRZ2

Где проблема: глюк терминала? биржа с диапазонами цен намудрила? финам с настройками сервера? 13-е число?

[mag]

Это точно не глюк терминала и точно Финам тут не виноват.
Проблема находится на стыке системы TRANSAQ и Биржи.

Дело в том, что торговая система FORTS не поддерживает "рыночных" заявок как таковых. Поэтому трейдинговые системы, в том числе и TRANSAQ, получив от клиента "рыночную" заявку, подают её на Биржу как лимитированную заявку по действующей сегодня максимально допустимой (минимально допустимой) цене. Эти максимальные и минимальные цены, или как их называют "планки", TRANSAQ узнаёт от самой Биржи, через шлюз. Так вот, теоретически могут быть промежутки времени, когда Биржа, в силу каких-либо причин уже изменила коридор цен (провела промклиринг или отреагировала на какие-то новости), и уже контролирует заявки по новым ценовым "планкам",  а TRANSAQ на момент обработки полученной от клиента заявки ещё не получил или не успел обработать и принять к сведению уведомления Биржи о изменении действующих ценовых планок.

Это наиболее вероятное материалистическое объяснение феномена.
По мере возможности мы попробуем запросить в Финаме логи системы за 13 декабря и изучить обстоятельства вашего случая.

[ddd323]

Да, спасибо, посмотрите обстоятельства моего случая.

Но вообще не дело. Проблемы клиентам так сказать на ровном месте. Может коль такие ситуации со стороны биржы возможны, стоит какую-нибудь функцию приделать, которая будет отслеживать и перевыставлять?
Или хотя бы дайте нам клиентам возможность с этим работать. Я когда то предлагал, добавьте в АТФ какую-нибудь минимальную библиотечку для работы со строками. Поиск там/str.contains(), да вырезание mid(n,m). А то пока, единственное что можно сделать - тупо перевыставлять последнюю заявку при появлении любой ошибки в onATFOrderErr(var str), либо самому писать что-то а-ля 1) сохранение в файл 2) посимвольное доставание (из просто строки же это вроде не сделаешь) 3) сравнение с алфавитом 4) обратное собирание слов, и т.п.

Кстати, вы в контексте перехода с onATFOrder/Trade на onOrder/Trade механизм/логику работы функции onATFOrderErr(var str) меняли начиная с ATF1.16? Или она по-прежнему, в т.ч. и после ATF 1.20 будет в соответствии с названием выдавать ошибки по заявкам конкретного скрипта? (Вообще это было бы странно: нужную для onATFOrder фильтрацию поддерживать не можете/хотите, а нужную для onATFOrderErr можете, хотите и будете...)
А если таки логику работы onATFOrderErr  тоже поменяли, почему новую функцию с новым названием не сделали?

[Heller]

Насчет ATF - учтем. По поводу остального вам чуть позже другие разработчики ответят.

[klimov]

По данному случаю:  в логах видно, что как только новые "планки" были получены от Биржи, именно они и стали использоваться при выставлении рыночных заявок.

[ddd323]

Heller, а насчет onATFOrderErr прокомментируйте пожалуйста.
Klimov, а через какое время новые планки стали использоваться - доли секунды, секунды, десятки секунд?

[klimov]

13го декабря новые планки пришли в 14:03:51,
(Т.е. через 51 сек после выставления)

Обычно это случается где-то в промежутке от 14:01 до 14:02
Видимо, была какая-то задержка на Бирже

[ddd323]

Heller, прокомментируйте плиз вопросы про OnATFOrderErr из моего второго поста

[Heller]

onATFOrderErr никак не изменит свое поведение - он работает корректно и пока мы не планируем ничего с ним сделать.

[ddd323]

Хм, интересно, может, я неправильно представляю как она сейчас работает. Тогда на примере.

1. Допустим у меня 2 скрипта работают на 2-х графиках по одной бумаге (фьючерсу). Скрипт №1 выставил заявку, которая не исполнилась из-за ошибки. Внимание, вопрос: я получу вызов onARFOrderErr()
А) в обоих скриптах (так как функция и раньше, несмотря на название, была скорее аналогом onOrder, а не onATFOrder)
В) только в скрипте №1 (т.к. функция соответствует своему названию)


2. Более сложная история, на которой onATFOrder раньше переставал работать с соответствии со своим названием, а именно - переход через ночь/перезагрузку терминала. Итак вечером Скрипт №1 выставил условный стоп (при достижении такой то цены закрыть позицию по рынку). (Вечерняя сессия закончилась, сервер выключился, терминал потерял связь с сервером. Утром терминал по сути загрузился с нуля, перезагрузив конфигурацию экрана.) В первую же милисекунду торгов стоп сработал, но допустим (хотя через ночь такое вряд ли возможно) биржа опять опоздала на несколько секунд с разрешенными диапазонами цен, и фьючерсная заявка "по рынку" была отвергнута биржей, и я должен получить описание ошибки в onARFOrderErr. Внимание, вопрос: я получу вызов onARFOrderErr()
А) в обоих скриптах (так как функция и раньше, несмотря на название, была скорее аналогом onOrder, а не onATFOrder)
В) только в скрипте №1 (т.к. функция соответствует своему названию и идеально работает, несмотря на перезагрузку терминала)
С) ни в одном из скриптов (т.к., например, функция соответствует своему названию, а название аналогично onATF/ClientOrder, но функции onClientOrderErr нет)
 

[ddd323]

Heller, ответьте пожалуйста на вопросы из моего предыдущегь сообщения

[Heller]

По первому вопросу ответ B, по второму вопросу ответ C. Он работает да, так же как onATFOrder. Мы конечно посмотрим как это возможно модифицировать, так как действительно при каких-то обстоятельствах сообщения об ошибках могут не доходить (хотя в этом случае все равно сработает onOrder и в нем будет установлен статус, описывающих суть ошибки).

[ddd323]

А вот с этого места поподробнее. В каком месте я все равно получу статус, описывающий суть ошибки?
Вы хотите сказать, что произошли еще какие-то изменения при переходе с onATFOrder на onOrder: новые статусы появились или новые поля в возвращаемом хэше заявок (в хелпе по ATF про это ни слова)?
Просто в вышеописанном случае 13.12.2012 ATF в атф 1.16 ни onATFOrder, ни onClientOrder по соответствующей отвергнутой сервером заявке даже не вызвались. Хотя теоретически вернуть OS_DENIED (Отклонена брокером) они могли бы...

А про модификацию - модифицируйте, конечно - полное молчание  скрипта - это плохо. Полагаю, раз вы не смогли ничего хитроумного сделать с функцией onATFOrder, чтобы ее сохранить - разумно повторить с onATFOrderErr тот же путь.
В терминах аналогии с предыдущим вопросом onATFOrder работает так:  1B, 2C (так же как Вы сказали работает сейчас onATFOrderErr. В итоге решили перейти на onOrder, который будет работать по принципу 1А, 2А. Соответственно, вероятно придется переходить с onATFOrderErr на 2А (что всяко лучше чем 2С), но безусловно хотелось бы сохранить 1B (ибо это лучше 1А)

[Heller]

Нет, изменений никаких больше не происходило. Я имел ввиду, что ошибку можно понять по статусу заявки, хотя в этом случае да, не будет описания текстового. Просто говорить об onATFOrderErr() довольно сложно из-за того, что ошибка может произойти в очень разных местах и обрабатываться она соответственно может по-разному.

Вообще функция  onATFOrderErr() вызывается на данный момент лишь в двух случаях:

1) Если заявка немедленно отклоняется сервером Transaq (вызов при этом произойдёт все равно асинхронно).
2) Если заявка отклонена биржей и при этом Transaq помнит из какого скрипта она выставлялась (то есть не было перезагрузок, переходов через сессию и т. п.)

Тут конечно с ней неудобно работать в таком виде, мы всё же переделаем её в ATF 1.18.

[ddd323]

я собственно про статус и спрашивал: в моем случае (13 декабря ) onOrder вызовется или нет (аналогично onATFOrder который не вызвался)?