Ваше пожелание зарегистрировано, мы постараемся его рассмотреть. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожелания в будущих версиях ПО.
В текущей реализации как-либо повлиять на описанное поведение нельзя. Ваши пожелания зарегистрировано, мы постараемся их рассмотреть. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожелания в будущих версиях ПО.
Расписание сессии по алгоритмическому классу (при закрытии, лимитированные заявки будут сняты) задается брокером. При завершении биржевой торговой сессии, лимитированные заявки снимаются торговой системой.
Ваше пожелание зарегистрировано. Мы постараемся его рассмотреть. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожелания в будущих версиях ПО.
При включенном "умном" заказе данных, уменьшение количества отображаемых в таблице текущих торгов инструментов действительно снизит объем получаемых данных и, как следствие, нагрузку на терминал. Однако, при небольшом количестве отображаемых инструментов, на практике данная разница будет незаметна.
Правильно понимаем, что имеется в виду возможность получения реального количества баров индикатора в случае, когда оно отличается от количества баров источника данных (в частности, индикатор "сдвинут вправо" от исходных данных)? В текущей реализации такая возможность отсутствует.
Регистрируем пожелание на соответствующую доработку?
1. Проблема изучается, постараемся в ближайшее время дать ответ.
2.
Цитата
AndyWise написал: Можно ли отложить запуск Луа машины или как то получить готовность графиков?
В текущей реализации такой возможности нет. Перед началом работы действительно рекомендуется подождать некоторое время, чтобы терминал прогрузил всю необходимую информацию.
Вынуждены повториться, нам не известно, как определяется направление на сделках в других местах. Это не исключает того момента, что в них оно может быть одинаковым (относительно друг друга).
Если у Вас есть сомнения в корректности отображаемой в терминале информации, рекомендуем обратиться в поддержку Вашего брокера и инициировать их обращения к нам для анализа ситуации.
В таком случае, повторимся, наиболее вероятно, имела место быть разовая проблема с получением/рассылкой данных. В случае повторения проблемы, рекомендуем поступить описанным ранее образом.
ISINhere2001 написал: У меня нет полномочий заставлять брокера обращаться к вам., что делать ?
К сожалению, у нас нет ответа на данный вопрос. Ровно также как и аналогичного рода полномочий. Ответить на Ваш вопрос или произвести анализ проблемы, если таковая имеется, без участия брокера не представляется возможным.
Если у Вас все еще есть сомнения в корректности работы системы, единственное, что мы можем предложить, это повторно обратиться в поддержку Вашего брокера.
В текущей реализации, направление обезличенной сделки на срочном рынке в системе QUIK соответствует тому, что транслирует биржа. Как это направление определяется в любых других системах и сайтах, нам, к сожалению, не известно.
Уточните, пожалуйста, данная проблема наблюдается ежедневно или после перезаказа данных она более не встречалась? В первом случае, Вам необходимо обратиться в поддержку Вашего брокера и, в случае необходимости, проинициировать его обращение к нам для анализа данной проблемы на серверной стороно. Во втором же, предполагаем, что имела место быть разовая проблема с получением данных.
В универсальном формате использование рыночной цены (как и "время действия") передается в виде флагов транзакции. Получить значение флагов транзакции нужного Вам типа можно добавив транзакцию с нужными параметрами в карман и выгрузив ее в tri-файл.
Обычно, связанные заявки снимаются при закрытии торговой сессии по классу алгоритмической торговли. Так как данное расписание настраивается Вашим брокером, рекомендуем обратиться по данному вопросу в его поддержку.
В случае, если брокер не сможет дать точный ответ, Вы можете попросить его обратиться к нам за помощью.
Пришлите, пожалуйста, нам на почту (quiksupport@arqatech.com) архив с терминалом и дамп процесса, снятый через деспетчер задач windows. Архив и дамп должны быть созданы на момент наблюдения чрезмерного потребления памяти: 1) Снять дамп
2) Закрыть терминал 3) Сформировать архив со всей директорией терминала (за исключением пользовательских ключей) и прислать его нам
В письме просьба подробно описать проблему либо же добавить ссылку на данную тему форума.
В текущей реализации, на сервере хранится (загружается утром брокером вместе с Вашими позициями) лишь средневзвешенная цена приобретения облигации, выраженная в процентах. Поскольку информация о том, с каким НКД была совершена сделка по открытию/наращиванию позиции отсутствует, для расчета средневзвешенной стоимости приобретения используется текущее значение НКД, транслируемое биржей. По этой причине, данное поведение не является ошибочным.
Можем предложить зарегистрировать и рассмотреть пожелание на соответствующую доработку. Правильно понимаем, что Вы хотели бы, чтобы цена приобретения облигаций фиксировалась в деньгах, а не в %, с учетом НКД на момент открытия/расширения позиции?
В первую очередь, рекомендуем выполнить обновление терминала до актуальной версии - 9.3.3 (если этого не было сделано ранее) и убедиться, что запуск скрипта(ов) осуществляется на Lua 5.4 В случае, если проблема сохраняется при таких условиях, просьба прислать снимок экрана с соответствующей ошибкой (так, чтобы на фоне была видна версия терминала) и сам скрипт для анализа.
Как ответили ранее и как правильно заметил пользователь Anton, обновление таблицы текущих торгов происходит "срезами", так данные транслирует торговая система биржи. Иными словами, между двумя полученными значениями могло произойти 0, 1, 2, 10 ... сделок. Это корректное поведение.
В первую очередь, рекомендуем выполнить обновление терминала до актуальной версии (9.3.3), предварительно убедившись у Вашего брокера, что версия его сервера 9.0.0 или выше. Скачать обновление можно по данной ссылке.
Необходимо будет закрыть терминал и распаковать скачанный архив обновления в директорию, где он установлен (обязательно подтвердив замену файлов).
Если описанное поведение сохраниться, просьба сообщить, будем изучать проблему подробнее.
1. Брокер действительно может устанавливать ограничение на количество отправляемых пользователем в секунду транзакций на свое усмотрение. Однако, это никак не лишает карман транзакций его предназначения. В условиях такого ограничения можно доставать транзакции группами. Уточните, пожалуйста, как в Вашем понимании должны выглядеть настройки, позволяющие обойти данный момент? Готовы зарегистрировать пожелание на доработку при наличии его подробного описания и актуальности.
2.
Цитата
Сергей написал: периодически уничтожает АЛГОРИТМИЧЕСКИЕ ЗАЯВКИ СО СРОКОМ ДЕЙСТВИЯ
В первую очередь, просьба уточнить, что имеется в виду в данном моменте. Пробовали ли Вы обращаться к брокеру по данному вопросу? Что он ответил?
Цитата
Сергей написал: могли бы вы сделать простой экспорт заявок из QUIK в файл, так, чтобы после их можно было импортировать из этого файла и подать на биржу
Уточните, пожалуйста, о каких преобразованиях идет речь? Заявки из таблицы заявок можно сохранить в текстовый файл, из него же их можно загрузить в карман транзакций соответствующей функцией контекстного меню.
AlexandraL написал: Пытаюсь понять что передается в тегах Теги TotalValueTraded (6143) и TotalVolumeTraded (387) - в спеке не очень однозначно написано. Это объемы сделки или это объем всех сделок по конкретному инструменту?
Объем (6143) и количество (387) во всех сделках по конкретному инструменту соответственно.
Цитата
AlexandraL написал: Точно ли тег 6143 будет передаваться в Market Date Incremental Refresh в fix версии 4.2? Данные забираем через Fix_drop_copy.
Не совсем понятно, с чем связан вопрос. Ответ - да, будет.
Андрей написал: Кто додумался в новой версии запретить перемещать на аукционах откр\закр? Чем обусловлено?
Можете, пожалуйста, подробнее описать проблему? Какую ошибку Вы получаете при попытке перенести (изменить) заявку в стакане?
Цитата
Андрей написал: Видимо это перемещение реализовано не совсем как снятие+создание на стороне терминала
Что имеется в виду под "не совсем как снятие+создание"? На сервер (и, в дальнейшем, на биржу) все также отправляется 2 транзакции - снять заявку, выставить заявку.
Уточнили данный момент. В текущей реализации все именно так, разблокировка средств производится при изменении статуса заявки, транслируемого биржей, на "Снята".
Цитата
Старатель написал: Сократить время можно, если обновлять лимиты не только после получения уведомления по заявке, но и после ответа от биржи по транзакции.
Предлагаем зарегистрировать такое пожелание. Регистрируем?
Мы рассмотрели Ваше пожелание. По итогам его анализа сообщаем Вам, что реализация пожелания признана потенциально целесообразной. Если по результатам дальнейшего анализа, включающего юридические аспекты, анализ на непротиворечивость с общей политикой компании, никаких возражений не возникнет, мы постараемся включить Ваше пожелание в план доработок при выпуске одной из следующих версий нашего ПО.
Незнайка написал: Не совсем так: Цитата - Если при сдвиге пары заявок одна из них наткнулась на кросс-сделку (сведение с заявкой от того же ИНН, либо клиентского регистра), она откатывается, а другая заявка сдвигается.
Да, действительно. Большое спасибо, что поправили.
Прошу прощения, насчет OnTransReply действительно поторопился с ответом. Текущая реализация данных флагов именно такова. Опишите, пожалуйста, подробнее, в каком виде Вы бы хотели ее видеть? Зарегистрируем пожелание.
Извиняемся за задержку с ответом. К сожалению, нам не удалось понять причину возникшей ошибки. В случае повтора просьба максимально подробно описать обстоятельства возникновения ошибки. Приносим извинения за причиненные неудобства.
Данный ранее ответ представлен в явном виде. Подробнее, к сожалению, некуда. За более подробной информацией рекомендуем обратиться в поддержку брокера.
Наиболее вероятно, что проблема заключается в настройках операционной системы. Направьте, пожалуйста, обращение нам на почту (quiksupport@arqatech.com), отправим Вам инструкцию по устранению проблемы.
Значение поля "Плечо" в актуальных схемах маржинального кредитования не несет в себе никакой значимой информации и совершенно не относится к объему доступных заемных средств. Так как данное значение задается Вашим брокером и транслируется в Ваш терминал с его сервера, за более подробной информацией рекомендуем обратиться в поддержку Вашего брокера.
У нас описанная Вами проблема не воспроизводится (оба терминала успешно запускаются и открываются). Можете зафиксировать проблему, например, на запись экрана и ее прислать нам на почту (quiksupport@arqatech.com) для анализа ?
В письме просьба коротко описать суть проблемы и указать ссылку на данную тему форума. Спасибо.
1. Такой возможности действительно не предусмотрено. Можем предложить зарегистрировать пожелание на доработку.
2. Режим связанных окон в текущей реализации не предусматривает использование таблицы стоп-заявок как основной таблицы. Можем предложить зарегистрировать пожелание на доработку, в таком случае просьба уточнить, с какую (какие) таблицу Вы хотели бы использовать как связанную в таком режиме? По какому признаку должна производиться фильтрация?
3. Аналогично пункту 2.
4. Просьба уточнить. Правильно понимаем, что настройка умного заказа данных включена, но несмотря на успешное выполнение функции ParamRequest, функция getParamEx не возвращает никаких значений?
5. "Смена операции клавишей "Пробел"" предусмотрена для смены операции на форме подачи заявки (как и следует из ее названия).
6. Просьба подробнее описать желаемый функционал. Как это должно выглядеть и действовать? Готовы зарегистрировать пожелание.
7. Заметим, что в виду отсутствия в торговой системе срочного рынка рыночных заявок, система QUIK выставляет искусственную "рыночную" заявку с ценой равной максимально/минимально возможной по данному инструменту. Если с учетом этой информации описанная Вами проблема сохраняется, просьба прислать подробный пример со снимком экрана, будем разбираться.
8. Уточните, что имеется в виду под "Ошибкой создания заявки"? Ответ от торговой системы? В таком случае, это корректное поведение, так как SendTransaction возвращает ошибку лишь по тем транзакциям, которые в принципе не удалось передать серверу. Для всего остального можно и нужно использовать OnTransReply.
9. Можете подробнее описать, для чего это нужно? Данная возможность уже реализована - OnTransReply
10. Нам не удалось воспроизвести описанную Вами проблему. Если она повторится, зафиксируйте ее пожалуйста и пришлите снимок экрана. Спасибо.
11. Правильно понимаем, что данная опция должна безусловно перезапускать упавший скрипт? Что делать, если скрипт продолжает падать при каждом запуске? Готовы зарегистрировать пожелание.
12. Ваше пожелание зарегистрировано, мы постараемся его рассмотреть. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожелания в будущих версиях ПО.
13. Данная проблема решается при помощи функции unpack в документации к использованию lua-индикаторов в QUIK даже приведен пример с ее использованием.
14. Trans_ID должен быть уникальным только при импорте транзакций из файла. При отправке транзакции из Lua-скрипта, его значение может быть каким угодно, так как оно используется только для синхронизации внутри самого скрипта (если таковая требуется).
В индикаторе функция getInfoParam("TRADEDATE") выдаёт ошибку - версия 9.2.2.11, В индикаторе функция getInfoParam("TRADEDATE") выдаёт ошибку - версия 9.2.2.11
В OnTransReply подобный флаг не может быть реализован, так как ответ на транзакцию, пришедший из торговой системы биржи, не содержит в себе подобной информации. Как вариант, готовы рассмотреть возможность добавления подобного флага в предложенный Вами коллбэк OnSendTransaction. Добавляем данный момент в пожелание?
Аналогичный момент касательно OnOrder и OnTrade, обновленная информация по заявке/сделке приходит на сервер из торговой системы биржи, которой не известно, каким образом была подана транзакция на выставление заявки.
Правильно понимаем, что заявка остается активной, но меняет свой тип? Опишите, пожалуйста, проблему подробнее. Желательно, пришлите снимок экрана.
Также, как верно заметил BlaZed , если речь идет о выставлении рыночных заявок на срочном рынке, то в таблице заявок они будут выглядеть как лимитные (по лучшему встречному предложению).
На другом форуме мне ответили так: " Потому что на срочном рынке ВСЕ заявки лимитные. Понятия "купить по рынку" на срочном рынке нет. Это введено в Quik, а алгоритм quikа по-видимому подставляет вместо рыночного ценника ценник лучшего предложения на момент выставления заявки. Это сервер Quik брокера преобразует рыночную в лимитную, а затем отсылает на биржу. Если в тот момент, пока заявка из сервера Quik идет на биржу, лучшие предложения съедят, то Ваша преобразованная в лимитную останется висеть." Насколько это верно?
Прошу прощения, имелось в виду, что такая заявка будет исполнена по лучшему имеющемуся в стакане предложению. При выставлении самой же заявки действительно будет подставлена минимальная/максимальная возможная цена. При этом, если встречных предложений на момент выставления не будет, заявка будет снята, а не останется висеть в стакане.
Как отметил коллега выше, в документации действительно имела место быть ошибка, она будет исправлена в одной из ближайших версий ПО.
Обратиться через Lua к доске опционов и ее полям возможности нет. Единственный вариант - рассчитать значения необходимых греков самостоятельно. Уточните, пожалуйста, почему Вы считаете, что один из параметров в таблице рассчитывается неправильно? Пришлите, пожалуйста, пример из терминала и свой расчет.
Правильно понимаем, что заявка остается активной, но меняет свой тип? Опишите, пожалуйста, проблему подробнее. Желательно, пришлите снимок экрана.
Также, как верно заметил BlaZed, если речь идет о выставлении рыночных заявок на срочном рынке, то в таблице заявок они будут выглядеть как лимитные (по лучшему встречному предложению).
Имена любых параметров таблицы текущих торгов можно посмотреть при помощи экспорта таблицы через DDE с включенной галочкой "Формальные заголовки". Названия столбцов после экспорта и будут являться именами необходимых параметров.
Ваше пожелание зарегистрировано, мы постараемся его рассмотреть. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожелания в будущих версиях ПО.