Двойное срабатывание OnOrder

Страницы: 1
RSS
Двойное срабатывание OnOrder, Двойное срабатывание OnOrder
 
При отслеживании срабатывания заявки с помощью функции OnOrder обнаружилась интересная особенность. Если срабатывание заявки происходит после ее выставления, то вход в блок if осуществляется один раз. А если одновременно с выставлением (цена инструмента лучше цены заявки), то два раза. Как отловить в данном случае второй вход?



function OnOrder(order)
if (bit.band(order[‘flags’], 3)==0) then
...
end



Протокол

Время Сообщение
17:13:59 (162) Заявка на покупку N 5758751 зарегистрирована (1 удовлетворено).

17:14:00 Сработала заявка номер - 5758751.
17:14:00 Код класса – CETS
17:14:00 Код бумаги - USD000UTSTOM
17:14:00 Цена позиции 59.2825

17:14:00 Сработала заявка номер – 5758751
17:14:00 Код класса – CETS
17:14:00 Код бумаги - USD000UTSTOM
17:14:00 Цена позиции 59.2825

17:15:09 (161) Заявка на продажу N 5765504 зарегистрирована.

17:15:10 Сработала заявка номер – 5765504
17:15:10 Код класса – CETS
17:15:10 Код бумаги - USD000UTSTOM
 
Здравствуйте,
Вопрос уже не раз подымался на форуме. Второй вызов может произойти в момент, когда сервер устанавливает на теле заявки параметры которых нет на бирже.
Таковыми например являются UID и TRANS_ID (есть и другие). В первом вызове их нет, а во втором есть.
 
В первом вызове значения UID и TRANS_ID равны 0 или nil? И можно ли пропустить вызов в данном случае и ожидать второй вызов?
 
Цитата
Анатолий написал:
В первом вызове значения UID и TRANS_ID равны 0 или nil?
Лучше проверьте на практике.

Цитата
Анатолий написал:
И можно ли пропустить вызов в данном случае и ожидать второй вызов?
Второго вызова может и не быть, в случае если транзакция отправлялась на биржу не через QUIK.
Отличить заявку выставленную через QUIK но без доп параметров, от заявки выставленной не через QUIK никак нельзя.
Поэтому лучше реагировать на ответы на транзакции (OnTransReply) там есть номер порожденной заявки и нужные параметры UID и TRANS_ID
Если в OnTransReply параметры есть, а на заявке с тем же номером их пока еще нет, значит скоро приедет еще один OnOrder но уже с нужными параметрами.
 
ТС, работа нужно писать так, чтобы он корректно обрабатывал множественные срабатывания OnOrder
хоть два, хоть три раза.
и даже варианты, когда такого срабатывантя вовсе не произошло.
 
Что значит заявка выставлена через QUIK, но без дополнительных параметров и заявка выставлена не через QUIK?
Возможно ли что при срабатывании заявки функция OnOrder не будет вызвана вообще?
 
Цитата
Анатолий написал:
Что значит заявка выставлена через QUIK, но без дополнительных параметров и заявка выставлена не через QUIK?
Речь про первое срабатывание OnOrder, когда параметры еще не доехали.
Цитата
Анатолий написал:
Возможно ли что при срабатывании заявки функция OnOrder не будет вызвана вообще?
Такого сценария не должно быть. Разве что если связь пропадет, но после подключения, колбек все равно приедет.
 
Спасибо
 
Совсем неожиданно образовалась еще одна проблема. Данная функция сработала до начала торговой сессии. В чем проблема? И как избежать таких срабатываний?
 
Анатолий,
Этот вопрос совершенно никак не относится к LUA.
Уточните у брокера причины исполнения заявок.
 
Взаимодействе с брокером осуществляет через терминал. И данный вопрос я адресую к службе поддержки терминала потому, что не знаю как взаимодействуют терминал и брокер и где источник проблемы. Брокер - открытие. Думаю с этой проблемой должна разбираться служба поддержки. Я лишь могу сказать, что до начала торговой сессии получать изменение статуса лимитированной заявки очень странно.
 
Анатолий,
Данный вопрос совершенно никак не относится ни к терминалу ни к QUIK в целом.
За исполнение заявок отвечает биржа согласно правилам торгов. И Ваш вопрос надо адресовать брокеру, т.к. весь диалог с биржей Вы ведете через брокера.
А QUIK это лишь средство для доступа на биржу
 
Цитата
Анатолий написал:
Совсем неожиданно образовалась еще одна проблема. Данная функция сработала до начала торговой сессии. В чем проблема? И как избежать таких срабатываний?
Приехали заявки/сделки, поданные вами в вечернюю сессию?
 
Они самые. Попробую по дате отсеять. А вообще такие вещи надо в документации писать, что может быть два вызова на одно исполнение и такие вот фокусы под самое начало торгов следующего дня.
 
Посмотрите класс в этих заявках, вероятно это не SPBFUT
 
SPBFUT. Более того класс, бумага, счет и т.д. для стоп-заявки, берутся из лимитной заявки.
 
так у вас стоп заявки имеют место быть?
 
Данный скрипт по срабатывания лимитированной заявки, выставляет стоп-заявку. Если лимитированная заявка была выставлена стоп-заявкой, то для такой заявки стоп-заявка не выставляется. Цена исполнения определяется по сделкам для обрабатываемой лимитированной заявки. Вот собственно и все.
 
Цитата
Анатолий написал:
Совсем неожиданно образовалась еще одна проблема. Данная функция сработала до начала торговой сессии. В чем проблема? И как избежать таких срабатываний?
Обычное дело. Решение простое - время работы скрипта установи.С колбеками то же обычное дело  - фильтруй по маркерам, например так:
if tr_num~=trade.trade_num then tr_num=trade.trade_num
..............
end
Идентификатор обрабатываемого события сохраняем в глобальной переменной и повторный колбек с тем же идентификатором отсеивается.
Страницы: 1
Читают тему
Наверх