Насколько уникален order_num?

Страницы: 1
RSS
Насколько уникален order_num?
 
Транзакция на снятие заявки требует указания не только номера заявки, но и кодов класса и инструмента.
Отсюда возникает вопрос: насколько уникален в течение торговой сессии номер заявки?
Он действительно уникален или уникален в пределах класса инструментов (class_code + order_num) или уникальной является лишь комбинация class_code + sec_code + order_num?
 
Если торгуете на Московской бирже, то class_code + order_num уникальная комбинация.
 
Цитата
_sk_ написал:
Если торгуете на Московской бирже, то class_code + order_num уникальная комбинация.
в течение одного торгового дня
 
Спасибо!
 
Если в течение торгового дня для разных классов на бирже (на разных площадках) могут быть зарегистрированы разные заявки с одним и тем же order_num, то почему же в OnTransReply на снятие заявки нет class_code?

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

Проблема в том, что для KILL_ORDER транзакции brokerref не заполняется, однозначности в trans_id - никакой, т.к. клиент quik сам беспрерывно обменивается с сервером кучей своих служебных транзакций с непредсказуемо заполненными trans_id, а тут еще выясняется, что и order_num - тоже не однозначный идентификатор. Что остается? Заниматься еще анализом firm_id и client_code для однозначной идентификации к какой торговой площадке относится пришедший OnTransReply от KILL_ORDER?
 
Добрый день,

Вероятность НЕуникальности order_num крайне мала, поэтому можно считать, что отсутствие проверки дополнительных условий не будет приводить к ошибкам идентификации заявки.
При необходимости, Вы конечно можете реализовывать дополнительные алгоритмы проверки.
 
Цитата
s_mike@rambler.ru написал:
Цитата
_sk_   написал:
Если торгуете на Московской бирже, то class_code + order_num уникальная комбинация.
в течение одного торгового дня
Как ведет себя order_num лимитированной заявки forts, выставленной средствами qlua, после перехода через клиринг, если она выставлена с условием ["Переносить заявку"] = "Да" и указанием даты экспирации? Если он меняется, то как скрипт может узнать какой новый номер присвоен заявке? Придет OnOrder со старым trans_id, но новым order_num?
 
Уважаемая техподдержка Quik!
Уже можете не отвечать. Разобрался экспериментальным путем.
Но я первый раз встречаю программный продукт, допускающий возможность разработки пользовательских расширений своего функционала, разработчики которого не желают представить действительно полное описание своего API, а предлагают экспериментальным путем выяснять как работает их продукт. Игра с черным ящиком на деньги опаснее, чем в три наперстка на привокзальной площади.

С другой стороны, заранее прошу прощения у разработчиков за свой эмоциональный пост, возможно, я просто по невнимательности не нашел в руководствах Quik раздел, посвященный выставлению средствами lua лимитированной заявки на рынке Forts с возможностью автоматического перевыставления её на последующие торговые дни до указанной даты. Интересно было бы посмотреть описание поведения для такой заявки полей таблицы orders: trans_id, exchange_code, linkedorder, ext_order_flags и т.д., а не выяснять это экспериментальным путем.
Также я не нашел полноценного описания формата *.tri файла с ключами на русском языке, обладающего большей функциональностью.
 
Алексей,

Дело в том что Ваш вопрос вообще никак не связан с QLUA да и с QUIK в принципе.
Вы торгуете на бирже и заявки там исполняются по правилам биржи.
И совершенно не важно как Вы эти заявки подаете, через QLUA, динамический импорт или через терминал.
Все равно они исполнятся по правилам биржи.
И то как заявка переносится через сессию это опять же правила биржи.
И к слову, на нашей планете есть не только Московская биржа.
Бирж много и у каждой свои правила.
А QUIK умеет работать с очень большим количеством бирж.
Так как бирж много и так как у каждой свои правила, мы чисто физически не можем впихнуть в одну документацию правила вообще всех бирж, которые поддерживаются в QUIK.
Да это и не нужно так как эти правила есть на сайте нужной Вам биржи.

Что касается полноценного описания формата *.tri файла с ключами на русском языке.
Вы его не нашли потому что его не существует. И не может существовать в принципе.
Как уже было сказано бирж много, у каждой свои правила и свои транзакции и даже если транзакции разных бирж делают одно и тоже, у них могут  быть разные параметры.
Формат "на русском" это формат транзакции в том виде как она представлена согласно протоколу обмена данными с биржей и он поддерживает все параметры которые возможны на конкретной бирже. Включив в настройках терминала галку "Стандартные формы ввода" Вы увидите форму ввода транзакции как раз в этом виде.
И как можно заметить в такой форме обычно гораздо больше параметров чем в "красивой".
Так как на разных биржах параметры разные, чтобы было удобно, мы объединили некоторые совпадающие по смыслу в заранее заданные константы.
Именно они представлены в нашей документации.
А тот формат который "на русском", это родной биржевой формат.
Так как бирж много, так как у каждой свои транзакции, так как совпадающие по смыслу транзакции имеют разные параметры, мы опять же чисто физически не можем впихнуть в одну документацию описание вообще всех транзакций вообще всех бирж, которые поддерживаются в QUIK.
Да это и не нужно так как эти параметры есть в правилах торгов которые есть на сайте нужной Вам биржи.

К слову, чтобы узнать как называется нужный параметр "на русском", достаточно добавить нужную транзакцию в карман транзакций и сохранить от туда в tri файл.
Открыв файл блокнотом, Вы увидите транзакцию в формате "на русском". Или можно воспользоваться галкой "Стандартные формы ввода"

Почему "на русском" пишется в кавычках? Дело в том что в английском интерфейсе терминала, эти же параметры будут "на английском".
Параметры "на русском" не работают в английской версии интерфейса.
Параметры "на английском" не работают в русской версии интерфейса.
Параметры в том виде как они приведены в документации, работают в обоих версиях интерфейса.
 
Sergey Gorokhov,
Цитата
Бирж много и у каждой свои правила. QUIK умеет работать с очень большим количеством бирж.
Но умение это взялось не из-за какого-то уникального AI, встроенного в программное обеспечение, а из четко заложенных разработчиками для каждого class_code своих схем данных обмена командами и информационных потоков с соответствующей торговой площадкой.
Цитата
Как уже было сказано бирж много, у каждой свои правила и свои транзакции и даже если транзакции разных бирж делают одно и тоже, у них могут  быть разные параметры.
Именно поэтому, в идеале, хотелось бы увидеть для каждого class_code свой справочный файл с описанием полей отправки транзакций и полей потоков OnOrder и OnTrade (для торговых поручений). Ведь наименования и информационное наполнение этих полей не являются копией протоколов биржевых шлюзов, а являются собственной разработкой ARQA. Эту документацию не обязательно поставлять в составе Quik, но хотелось бы иметь возможность получить ее хотя бы по запросу для конкретного class_code.
Но это все, конечно, мои "хотелки", а вовсе не претензии к разработчикам :)
Цитата
К слову, чтобы узнать как называется нужный параметр "на русском", достаточно добавить нужную транзакцию в карман транзакций и сохранить от туда в tri файл.
Именно по отношению к этой, неоднократно встречающейся на форуме рекомендации, я написал:
Цитата
Алексей написал:
разработчики ... предлагают экспериментальным путем выяснять как работает их продукт.
А теперь, вернемся к конкретике.
В форме ввода для ручной подачи заявки forts есть возможность выставить "многодневную" (как это названо в руководстве spectra plaza) заявку c временем жизни "по дату".
В руководстве Qlua об этой возможности я ничего не нашел.
Цитата
Да это и не нужно так как эти параметры есть в правилах торгов которые есть на сайте нужной Вам биржи.
В руководствах spectra plaza я увижу описание потока информации по шлюзу между биржей Forts и сервером брокера, но я не увижу какие параметры нужно заполнить в таблице для sendTransaction и в каких полях OnOrder я смогу увидеть информацию, связанную, например, с ежедневным перевыставлением заявки.

Через карман транзакций я выяснил какие параметры нужны для sendTransaction, и они были на русском.
Цитата
Дело в том что в английском интерфейсе терминала, эти же параметры будут "на английском".
В описании *.tri файла я не нашел подходящего параметра. Но может быть, все же, в английском варианте есть поле, соответствующее ["Переносить заявку"]? (Или для выяснения этого я должен переключить язык интерфейса клиентского места? Опять же, в региональных установках у меня только одна возможность выбора языка - это "Russian[Standard Set]").

Опять же, главная проблема не в этом.
А главная проблема в том, что при разработке скрипта нельзя гадать, какой столбец Quik-овской Таблицы Заявок соответствует какому полю lua таблицы, получаемой в OnOrder. Это надо четко видеть в руководстве разработчика Qlua. Например, откуда берется информация для столбца "Расширенный статус"? Из ext_order_flags? Но об этом нигде ни слова, как и о собственно значениях битов этого флага. Между тем, оттуда можно подчерпнуть информацию о том, что заявка "отменена по закрытию сессии", что бы убедится, что она не "слетела" по каким-то иным причинам. Ведь во всем остальном для скрипта ответ OnOrder в этой ситуации выглядит так, будто заявку отменил сам пользователь вручную. Как скрипту связать перевыставленную после клиринга заявку с исходной? По linkedorder или в exchange_code, где мы можем увидеть исходный order_num заявки (и заодно первоначальную дату выставления заявки)? Но это лишь мои предположения. Где можно найти об этом информацию? В руководстве Qlua об этом ни слова. Или нужно искать linkedorder, exchange_code и т.д. в описании протокола обмена информацией между биржей и сервером брокера? Так там совершенно другие наименования полей. А заниматься гаданием, при написании приложений, управляющих реальными деньгами, - непозволительная роскошь.

Я не докапываюсь до отсутствия описания какой-то малоиспользуемой, частной особенности выставления и работы с заявкой на forts. Я говорю об общем подходе к описанию OnTransReply, OnOrder, OnTrade и параметров таблицы для sendTransaction. На форуме неоднократно уже говорилось, что странно, что о некоторых ограничениях в работе с заявками из lua оказывается надо узнавать из описания Qplie. Странно, что в руководстве не упоминается, что поле class_code не заполняется в ответах OnTransReply на Kill_Order транзакции. И этих "странно" очень много на форуме. Просто смешно наблюдать, когда пользователи на форуме начинают гадать, какая информация содержится в exchange_code, там ни одного вразумительного ответа.
Пожалуйста, дополните, насколько возможно, описание Qlua.
И, пожалуйста, расшифруйте значения битов ext_order_flags хотя бы для фондовой и срочной площадок московской биржи. (Хотя в описании столбца "Расширенный статус" указано 8 вариантов, никак не связанных с конкретной торговой площадкой).
 
Цитата
Алексей написал:
Именно поэтому, в идеале, хотелось бы увидеть для каждого class_code свой справочный файл с описанием полей отправки транзакций и полей потоков OnOrder и OnTrade (для торговых поручений).
Только по примерным прикидкам, удалось насчитать около 2000 разных class_code которые поддерживаются в QUIK.
Описать их все? И сколько простите гигабайт тогда будет весить документация?

Цитата
Алексей написал:
Ведь наименования и информационное наполнение этих полей не являются копией протоколов биржевых шлюзов, а являются собственной разработкой ARQA.
Вот как раз копией они и являются. QUIK не умеет брать информацию из воздуха.
На разных биржах одинаковые по смыслу параметры называются по разному, а в QUIK они объедены и называются одинаково.

Цитата
Алексей написал:
В руководствах spectra plaza я увижу описание потока информации по шлюзу между биржей Forts и сервером брокера, но я не увижу какие параметры нужно заполнить в таблице для sendTransaction и в каких полях OnOrder я смогу увидеть информацию, связанную, например, с ежедневным перевыставлением заявки.
Правила торгов это не тоже самое что описание протокола, которое Вы видимо и читаете.

Цитата
Алексей написал:
В описании *.tri файла я не нашел подходящего параметра. Но может быть, все же, в английском варианте есть поле, соответствующее ["Переносить заявку"]? (Или для выяснения этого я должен переключить язык интерфейса клиентского места? Опять же, в региональных установках у меня только одна возможность выбора языка - это "Russian[Standard Set]").
Вы категорически неверно поняли.
Описание параметров транзакций, которое приведено в документации это один вариант.
Описание "на русском" это второй вариант
Описание "на английском" это третий вариант.

Первый, это объединенный вариант, который содержит параметры транзакций которые являются общими для разных торговых площадок. Т.е. тут есть далеко не все возможные параметры.
Второй и третий это одно и тоже, они представляют варианты транзакций с полным набором параметров который есть на бирже.
Параметра "Переносить заявку" нет в первом варианте, так как этот параметр является специфичным.

Цитата
Алексей написал:
Опять же, в региональных установках у меня только одна возможность выбора языка - это "Russian[Standard Set]").
Английский интерфейс является отдельно приобретаемой услугой т.е. не все брокера его предоставляют.

Цитата
Алексей написал:
Просто смешно наблюдать, когда пользователи на форуме начинают гадать, какая информация содержится в exchange_code, там ни одного вразумительного ответа.
Всегда есть поддержка у которой можно спросить.

Цитата
Алексей написал:
И, пожалуйста, расшифруйте значения битов ext_order_flags хотя бы для фондовой и срочной площадок московской биржи. (Хотя в описании столбца "Расширенный статус" указано 8 вариантов, никак не связанных с конкретной торговой площадкой).

Пожалуйста, конкретно для срочной секции:
Цитата

заявка снята COD = 4
заявка заменена = 16
заявка в состоянии отмены = 32
заявка отвергнута = 64
приостановлено исполнение заявки = 512
заявка в состоянии регистрации = 1024
заявка снята по причине закрытия сессии = 2048
заявка снята по времени действия = 4096
заявка в состоянии замены = 8192

Для фондовой, этот параметр не используется.
 
Sergey Gorokhov,
Большое спасибо за разъяснения!
 
Цитата
Stanislav Tvorogov написал:
Добрый день,

Вероятность НЕуникальности order_num крайне мала, поэтому можно считать, что отсутствие проверки дополнительных условий не будет приводить к ошибкам идентификации заявки.
При необходимости, Вы конечно можете реализовывать дополнительные алгоритмы проверки.
а можно ли снять заявку по trans_id, seccode и class, не используя order_num?
 
Цитата
s_mike@rambler.ru написал:
Цитата
_sk_ написал:
Если торгуете на Московской бирже, то class_code + order_num уникальная комбинация.
в течение одного торгового дня
Откуда такая информация?
Страницы: 1
Читают тему (гостей: 1)
Наверх