QUIK (версия 7.0.1.5)

Sergey Gorokhov,
В QUIK 7.0.4.10 на боевом сервере:

Скрытый текст

Код 26.02.16 14:07:25.090 [OnOrder] order_num=20003386909; 1 26.02.16 14:07:25.090 [OnOrder] order_num=20003386909; 1 26.02.16 14:08:04.772 [OnTrade] trade_num=1404415763; order_num=20003386909; 1 26.02.16 14:08:04.772 [OnTrade] trade_num=1404415763; order_num=20003386909; 1 26.02.16 14:08:04.776 [OnOrder] order_num=20003386909; 0 26.02.16 14:11:07.868 [OnTrade] trade_num=1404423113; order_num=20003517712; 1 26.02.16 14:11:07.868 [OnTrade] trade_num=1404423113; order_num=20003517712; 1 26.02.16 14:11:07.868 [OnOrder] order_num=20003517712; 0 26.02.16 14:11:07.868 [OnOrder] order_num=20003517712; 0 В конце указан остаток (balance). Заявки выставлялись вручную, поэтому наличие дублей нельзя объяснить добавлением trans_id в последующих колбэках.

Скрытый текст

Код 26.02.16 14:10:30.077 [OnStopOrder] order_num=113318863; trans_id=1024. Активна 26.02.16 14:10:33.131 [OnTrade] trade_num=1404422578; order_num=20003504311; 8 26.02.16 14:10:33.131 [OnTrade] trade_num=1404422578; order_num=20003504311; 8 26.02.16 14:10:33.131 [OnTrade] trade_num=1404422578; order_num=20003504311; 8 26.02.16 14:10:33.131 [OnOrder] order_num=20003504311; 0 26.02.16 14:10:33.131 [OnOrder] order_num=20003504311; 0 26.02.16 14:10:33.131 [OnOrder] order_num=20003504311; 0 26.02.16 14:10:33.131 [OnStopOrder] order_num=113318863; trans_id=1024. Выставлена заявка в ТС: 20003504311 26.02.16 14:10:33.131 [OnStopOrder] order_num=113318863; trans_id=1024. Выставлена заявка в ТС: 20003504311

Добрый день,
   
    По данному обращению мы диагностируем что заявки, отправляются     пользователям столько раз, сколько раз они менялись на сервере (под     изменением понимается, как изменение статуса, остатка, так и     установка UID, trans_id). При этом по факту заявки могут быть     отправлены сразу в последнем, актуальном, состоянии. Поэтому клиенты     видят многократный апдэйт одной и той же заявки без ее видимых     изменений. В одной из следующих версий серверного ПО QUIK мы     постараемся исправить эту ситуацию, чтобы не дублировать отправку     заявки в одном и том же состоянии несколько раз.

можно ли фильтровать колбек onTrade на основе поля trade_num?
Если исполнение заявки выполнилось за один раз, придет три onTrade с одинаковыми полями.
Если же исполнение заявки выполнилось, к примеру за два раза, то придет 3 onTrade с trade_num = 123456 и еще 3 onTrade с trade_num = 67890
все правильно?

т.е. мне требуется собрать все ответы от колбека onTrade в одну кучу (в массив) и выкинуть ненужные. Собирать я планирую
trade_num
order_num
qty
price.
Никак не могу понять, как их выловить и для начала поместить в массив? Если можно простой пример на примере одной переменной

_sk_,      Добрый день,
   
    Мы рассмотрели Ваше пожелание. По итогам его анализа сообщаем Вам,     что реализация пожелания признана потенциально целесообразной. Если     по результатам дальнейшего анализа, включающего юридические аспекты,     анализ на непротиворечивость с общей политикой компании, никаких     возражений не возникнет, мы постараемся включить Ваше пожелание в     план доработок при выпуске одной из следующих версий нашего ПО.

Не не не не. Старатель знает, что пишет. И сборщик мусора тут не при чём. Любая Lua-таблица может быть проиндексирована любым значением в качестве индекса (кроме nil). В результате вы получите nil в случае, если ключ в таблице отсутствует или значение ключа. Поэтому код
не затрагивает сборщик мусора и абсолютно безопасен, хоть и бессмысленен.

Здравствуйте,
Не вижу причин упрека, никто не говорил что в версии 7.2 в этом месте что-то менялось
Рекомендуем ознакомиться со списком изменений.

OnOrder*

Quik 8.2.0.78
14:52:55.674 Отправил бай SendMarketOrder(classCode, secCode, tool.AccountID, Operation.Buy, 10);
14:52:55.847 OnTransReply(): По транзакции №=12145255 Успешно выставлена заявка №=4755649620 По цене=0 Объёмом=10
14:52:55.976 Events_OnMoneyLimit(): Изменилась позиция по деньгам: CurrentBal=272991,13 OpenBal=294251,82 Locked=28176,41
14:52:55.978 Events_OnDepoLimit(): Изменилась позиция по бумагам: SBER CurrentBalance=0 AweragePositionPrice=0
14:52:56.581 Events_OnTrade(): OrderNum=4755649620 OrderPrice=0 trade.Price=258,43 TransID=12145255 TradeNum=3126631556 Quantity=10 flag=0 OrderQty=0 SystemRef= UID=152656
14:52:56.582 Events_OnTrade(): OrderNum=4755649620 OrderPrice=0 trade.Price=258,43 TransID=12145255 TradeNum=3126631556 Quantity=10 flag=0 OrderQty=0 SystemRef= UID=152656
14:52:56.583 Events_OnTrade(): OrderNum=4755649620 OrderPrice=0 trade.Price=258,43 TransID=12145255 TradeNum=3126631556 Quantity=10 flag=0 OrderQty=0 SystemRef= UID=152656
14:52:56.584 Events_OnOrder(): OrderNum = 4755649620 TransID = 0
14:52:56.585 Events_OnOrder(): OrderNum = 4755649620 TransID = 12145255

Вопросы:
1. Для версии 8.2 все также 3 колбека для OnTrade() и 2 для OnOrder() ... ничего не исправили ?
Не смог найти отличий в квитанциях полученных в OnTrade, их три штуки ((( Я плохо искал ? судя по ответам разработчиков в этой ветке их не всегда 3 штуки может быть а от 1 до бесконечности ((((.

2. Как понять что полученная квитанция в  OnTrade окончательная и не будет больше меняться, т.е. я могу брать из неё данные и работать дальше?
вариант запоминать  TradeNum и обрабатывать заявки только с большим номером не проходит ((, т.к. при отправке 1000 лот, они разбиваются на части и там каша этот вариант не сработает....
Заранее спасибо.  

З.Ы. Пишу видео и выкладываю их на Ютуб. Программирование торговых роботов на языке С# через торговый терминал Quik. Если кому-то интересно присоединяйтесь буду искренне рад, любой помощи и подсказке.
ПлейЛист https://clck.ru/LRGZB

Пятый пошел!

Вроде бы как-то обещали, что внесете порядковый номер обновления для каждой сущности, что было видно, что что-то поменялось.
Три года с тех пор прошло.

А зачем?

заведите в скрипте таблицу с полученными колбеками, по каждому пришедшему смотрите в ней уже имеющиеся и делайте свои выводы.

по вычислительной нагрузке это - ничто.

 Отправляю заявку через скрипт Lua - 1 лот, использую свой TRANS_ID на транзакцию. Задача - если сделка произошла, значит надо отправить другую заявку. Т.е. мне нужен контроль исполнения заявки(сделка). Логи показывают, что сначала первой всегда откликается OnTransReply(), потом могут идти 3 вызова OnTrade() и 2 вызова OnOrder() в разной очерёдности. Логика контроля исполнения заявки(по сути приход сделки) была такая:
1) В OnOrder() если пришло изменение заявки, т.е. order.balance == 0 , то -> флаг is_nul = true.
2) В OnTrade() если trade.order_num == номеру моей заявки(получаю его через OnTransReply(), или в OnOrder() если пришла моя TRANS_ID если этот OnOrder() вызвался раньше OnTransReply()[мало ли?] , то -> флаг  is_trade = true.
3) Далее если if is_nul and is_trade then -> выставляем нужную заявку.

Я не рассчитывал на то, что колбэки могут отправляться по нескольку раз. Прочитал эту тему, понял, что могут и причём неограниченное число раз. Я не заморачивался и не тестил чем конкретно отличаются пришедшие в колбэках таблицы, но вижу, что OnOrder() где order.balance == 0 - 2 раза, и OnTrade() 3 раза и слава богу цена в нём одна и та же.

Вопросы:
1) Возможен ли вызов OnTransReply() на мою поданную заявку с моим TRANS_ID, с trans_reply.trans_id == 0, nil, "0", "" или же trans_reply.trans_id всегда содержит номер заявки? Этот номер заявки измениться не может?
2) OnTransReply() вызывается только один раз?
3) Возможен ли случай, когда сначала первой будет вызов OnOrder(), а потом уже вызов OnTransReply()? Вроде бы как-то один раз такое проскочило, когда скрипт вылетел с ошибкой исполнения. Но точно не помню, возможно было и так, даже скорее всего так, что был вызов только OnTrade(), а  OnTransReply() не вызвался, хотя по факту заявка выставилась. Из-за этого дублирую сохранение номера заявки не только в OnTransReply(), но и в OnOrder().
4) Могу ли я быть уверен, что имея самый первый OnOrder() c order.balance == 0, последующие OnOrder() не изменят значение  order.balance?
5) Могут ли приходить сначала OnTrade() без  trade.price, а потом с  trade.price? От этого зависит какие именно я могу использовать вызовы OnTrade(), т.е. нужно ли вообще проверять установлено ли в них поле  trade.price, или это поле заполнено ценой всегда и не меняется в следующих вызовах?
6) Могу ли я быть уверен, что имея самый первый OnTrade() с ценой исполнения trade.price, последующие OnOrder() не изменят значение trade.price?
7) Могу ли я с учётом своего алгоритма контроля исполнения использовать только самые первые вызовы OnOrder(), OnTrade(), OnTransReply(), отфильтровывая все последующие, где я фактически смотрю только на изменение баланса в заявке и жду появления сделки с номером заявки?
8) Может быть вообще как-то по другому изменить алгоритм контроля исполнения заявки(приход сделки)? Какой алгоритм контроля посоветуют разработчики с учётом всех этих многочисленных вызовов?

Все эти 0, nil, "0", "", которые могут прийти в trans_id в разных частных случаях в OnTrade() или в OnOrder() как я понял для меня не критичны, так как во всех колбэках я проверяю поля таблиц trans_id со своим номером транзакции TRANS_ID.

Владимир, привет. Вот и в этой ветке встретились. Мне бы весь этот сыр-бор с колбеками свести к решению моей простой задачи. Мне собственно(во всяком случае пока) надо реализовать элементарный алгоритм. Покупка лота - 1 шт, т.е. автоматом отпадает возможность срабатывания только части заявки потому как 1 лот это 1 лот и его частично исполнить нельзя. Это намного упрощает задачу. Далее всё, что мне нужно это контроль исполнения этой заявки на покупку. Всё. Я должен быть на 100% быть уверен, что моя заявка исполнилась. И если исполнилась, то только тогда подаю следующую уже на продажу, так что тут такой же принцип блокировки - пока не сработает покупка - никакой продажи. На QPILE я это делал так - в цикле пробегал по таблице заявок в поиске своей заявки с номером который мне возвратила send_transaction() в своём результате, смотрел значения поля баланса когда станет равно нулю, как только оно стало равно нулю, то потом в цикле пробегал по таблице сделок и как только в ней появлялась запись с номером моей заявки, я считал что сделка исполнена. Не знаю насколько хорош такой алгоритм, но он работал всегда. Возможно, что достаточно было просто увидеть ноль на балансе в таблице заявок и плюнуть на таблицу сделок, не знаю. Или наоборот, может достаточно было бы и того что сделка появилась в таблице сделок. Но я для надёжности решил использовать и то и то. Перейдя на Lua сначала обрадовался, что есть колбэки и не надо бегать в цикле по таблицам в поиске нужного номера заявки, но не тут то было. С одной стороны всё просто. С другой стороны - куча вопросов. А есть ли гарантия? На данный момент меня интересует пока только одно, могу ли я использовать самый первый вызов OnOrder(), в котором на балансе появился ноль вместо единицы и отбросить все остальные вызовы? Могу ли я использовать только самый первый вызов OnTrade(), который мне показал, что в нём появился номер моей заявки, взять из него цену и быть уверенным, что эта цена не меняется в следующих вызовах, и что вообще есть ли гарантия, что эта цена будет в самом первом этом вызове, т.е. надо ли проверять что цена не ноль, а остальные вызовы отбросить?
Если так можно, то суть контроля исполнения оставляю ту же - приход нуля в балансе заявки и(AND) появление сделки. Открытым в принципе остаётся вопрос, а надо ли вообще делать 2 проверки или может быть достаточно только какой-то одной из них? Если вызовы колбэков идут вразнобой, может заменить AND на OR? Может вообще как-то изменить сам алгоритм контроля исполнения? Как? Как лучше?

PS. Разработчики накуралесили конечно знатно, оставив пользователям самим разбираться во всём, потому как много непоняток и нет однозначности. Не мешало бы самим этим разработчикам в документации привести хотя бы элементарный пример контроля исполнения заявки использую колбэки!

1)  OnTransReply - это колбек об отправке транзакции. Т е транзакция ушла с сервера брокера и попала на сервер биржи.
единственный параметр в ней который не изменится это trans_id.
------------------------
Его надо использовать для идентификации транзакций.
Все остальное может бить или не быть в зависимости от того как обрабатывается эта транзакция на сервере биржи.
---------------------
2) Надо делать программу так, чтобы число срабатывания колбеков не влияло на результат.
Для этого надо не считать число срабатываний, а реагировать на события о которых сообщается в информации принятой колбеком.
Если новая информация не изменяет состояния Вашего робота (конечного автомата) то какая разница, сколько раз сработает колбек.
состояние не изменится.
------------------
3) OnOrder может приходить много-много раз. Например Вы поставили лимитную заявку 100 лотов , а встречные заявки  содержат по 1 лоту.
Сколько раз сработает OnOrder? Правильно... много.
Поэтому читайте ответ 2)
-------------------
4) см 2)
5)см 2)
6) см 2)
7) нет
8) ДА
------------------

Хорошо. По пункту 8 вы не советуете конкретный алгоритм. Но это в общем случае не советуете, поскольку вариантов может быть много. Но я спрашиваю конкретно для своего наипростейшего случая, что описал выше. Например - покупка 1 лота. Нужен контроль того, что покупка 1-го лота 100% прошла и только тогда подавать на продажу того же 1-го лота. Какой алгоритм контроля применить посоветует техподдержка? Уж куда проще то? Мой алгоритм подойдёт? Или можно его упростить, например - вообще не использовать OnTrade()? Достаточно проверить OnOrder() где баланс = 0? Сейчас использую и то и то. А надо ли? Вроде работает.

Короче, ещё спрошу так. Отправил заявку например на покупку 1 лота. В OnTrade() проверил, что  order.trans_id == моему TRANS_ID и order.order_num == TRANSACTION_COMPLETED[tostring(order.trans_id)], короче отфильтровал по своей заявке и проверил что order.balance == 0. Этого достаточно для контроля исполнения заявки?

Контроль исполнения заявки, которая например в вашем стеке у которой 1 лот контролируется по balanse == 0?

У меня сейчас для заявки в 1 лот алгоритм такой. OnOrder(): если для моей заявки balance == 0 - ставлю один флаг. Пришёл OnTrade()[сделка прошла значит] с моей заявкой - ставлю другой флаг и беру цену из него и в переменную. Функция контроля иcполнения ждёт появления обоих флагов, если пришли, то цену беру из переменной. Так же внутри OnOrder()  и OnTrade() использую ещё свои флаги для того чтобы отбрасывать ненужные их вызовы - по сути OnOrder() как только пришёл в балансе ноль - ставлю флаг, следующий вызов проверяет этот флаг и если он есть, то игнорирую вызов, так же и в OnTrade(), как пришла моя сделка - ставлю флаг, чтобы отсекать другие возможные её вызовы. Вот и думаю, может просто достаточно только OnOrder() и брать из неё цену исполнения и достаточно?

А я вот решил почему-то ещё и ждать прихода самой сделки, использую OnTrade(). Может это и не надо. Что скажут разработчики? Нужен ли двойной контроль?

Объясняю как я делаю это.
--------------------------------
Например, циклический тест  выставления и снятия заявки.
Это тест подобен Вашей задаче.
Отличие лишь в том, что я контролировал снятие заявки, а Вы контролируете исполнение заявки.
Но алгоритм , описанный ниже решает обе задачи.
================
Результат тестирования алгоритма,
показал его безошибочную работу при случайном выставлении и снятии заявки по 200 инструментам.
За 4 часа теста на демо сервере выставлено и снято 200 тысяч заявок без единой ошибки.
==================
Алгоритм:
------------------------------
Преамбула:
Робот - это конечный автомат, который изменяет свое состояние в зависимости от внешних сигналов и своей цели.
Источником внешних сигналов являются колбеки.
------------------------
В моем роботе задействованы все колбеки, описанные в документации библиотеки QLua
Заверяю Вас, что лишних колбеков нет.
Вы можете не использовать какие-либо колбеки, но это подобно тому, что у человека отключить какой-либо орган.
-------------------------------
Если Вы колбек выкидываете, то ваш робот не видит многих событий и просто зависнет в один прекрасный момент.
===========
Если инструмент, по которому я хотел бы выставить заявку активен
,т е произошло событие по данному инструменту ( сделка, изменение заявки),
то проверяем по таблице заявок есть ли активная и  по таблице транзакций есть ли активная   по этому инструменту.
----------------------
Если есть активная , то новая заявка не выставляется, иначе выставляется.
-----------------
В более продвинутом алгоритме выполняется анализ актуальности текущего состояния , но это уже другая задача.
 

Здравствуйте.

Вы можете протестировать Ваши алгоритмы, проанализировать и выбрать более эффективный для Вас. Протестировать можно на учебном сервере QUIK Junior.

Ну я собственно использую большинство колбэков, и для контроля исполнения использую и OnOrder() и OnTrade() впаре чисто для повышения надёжности. Хотя уверен, что и OnTrade() было бы вполне достаточно. Работает и ладно.

Вот ещё хочу тут спросить старожилов по такому поводу. Скрипт на Lua сначала делает продажу акций Лукойл по рынку в шорт 10 шт через sendTransaction() при этом естественно ставлю TYPE="M", PRICE="0".
Транзакция проходит, заявка исполнилась нормально. Следующая транзакция на покупку фьючерса "LKZ2", т.е. LKOH-12.22 в количестве 1шт так же по рынку, где в sendTransaction() установлено так же TYPE="M", PRICE="0". Но при этом транзакция с ошибкой: Ошибка создания заявки. [GW][332] "Нехватка средств по лимитам клиента." Пытаюсь купить данный фьючерс вручную в квике, установив галочку в окне ввода заявки "Рыночная" - результат опять та же самая ошибка!
В результате фьючерс купил таки вручную, указав цену на покупку из стакана равную лучшей цене продажи. Транзакция прошла без ошибок и заявка тут же исполнилась. Да мог бы поставить цену покупки и выше чем лучшая цена продажи на несколько пунктов, это я знаю, и заявка ушла бы так по лучшей рыночной цене.
Но вопрос: почему sendTransaction() работает на покупку/продажу акций по рынку с значениями TYPE="M", PRICE="0", а на  покупку/продажу фьючерса с значениями TYPE="M", PRICE="0" выдаёт ошибку: "Нехватка средств по лимитам клиента." и я вынужден ставить цену хуже рынка, чтобы заявка ушла по рынку? Заявка то в конечном итоге прошла, значит средств достаточно!

Рыночных заявок на срочном рынке нет, на самом деле. Брокер Они отправит их по верхней|нижней границе допустимого ценового диапазона. Так происходит, потому что размер ГО, блокируемого под сделку, зависит от цены сделки. И чем дальше цена от цены последнего клиринга, там ГО будет выше. Хотя реальная сделка и будет не так далеко, но расчет ГО у брокера будет по цене ордера. Так что на сделку в 200 пунктах от цены клиринга может и хватает, а вот уже на сделку в 2000 пунктах - нет. Но такое происходит, если торговать на границе доступных средств. Когда средств достаточно, то и "по рынку" пройдет сделка.