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

Если торгуете на Московской бирже, то class_code + order_num уникальная комбинация.

Спасибо!

Добрый день,

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

Уважаемая техподдержка Quik!
Уже можете не отвечать. Разобрался экспериментальным путем.
Но я первый раз встречаю программный продукт, допускающий возможность разработки пользовательских расширений своего функционала, разработчики которого не желают представить действительно полное описание своего API, а предлагают экспериментальным путем выяснять как работает их продукт. Игра с черным ящиком на деньги опаснее, чем в три наперстка на привокзальной площади.

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

Sergey Gorokhov,
Но умение это взялось не из-за какого-то уникального AI, встроенного в программное обеспечение, а из четко заложенных разработчиками для каждого class_code своих схем данных обмена командами и информационных потоков с соответствующей торговой площадкой.
Именно поэтому, в идеале, хотелось бы увидеть для каждого class_code свой справочный файл с описанием полей отправки транзакций и полей потоков OnOrder и OnTrade (для торговых поручений). Ведь наименования и информационное наполнение этих полей не являются копией протоколов биржевых шлюзов, а являются собственной разработкой ARQA. Эту документацию не обязательно поставлять в составе Quik, но хотелось бы иметь возможность получить ее хотя бы по запросу для конкретного class_code.
Но это все, конечно, мои "хотелки", а вовсе не претензии к разработчикам :)
Именно по отношению к этой, неоднократно встречающейся на форуме рекомендации, я написал:
А теперь, вернемся к конкретике.
В форме ввода для ручной подачи заявки 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 вариантов, никак не связанных с конкретной торговой площадкой).

Sergey Gorokhov,
Большое спасибо за разъяснения!