Nikolay (Все сообщения пользователя)

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

Никак. Более того это зависит от выбранного шрифта и его размера. Плюс надо не забывать, что есть шапка окна, её необходимо не включать в расчёты, т.к. она есть если строк 0. Так что я просто делаю доступным параметры масштабирования, чтобы можно было задать для каждого скрипта.

Собственно да, это же ожидания, хотя в основном он для другого https://www.moex.com/ru/ruonia

В целях планирования фючерс даже интересней.

Есть очень близкий индекс RUSFAR, на RUONIA есть фьючерс RUON

Да примерно всё также, три вклада, накопительный и четыре брокера. Я не буду заниматься переброской денег из банка в банк ради повышенных приветственных ставок.
Я плачу налоги как с вкладов, так и с облигаций. Ранее, до 2021, ОФЗ были без налога, теперь есть. Также как и вклады от суммы 1 млн. Так что приходится платить и эти налоги. Что касается рисков, то я бы здесь поспорил, т.к. риски по банкам, где высокие проценты, выше. Например, я не могу открыть вклад с своих банках выше 22-23%. И это без капитализации и пополнения, т.е реальная ставка ниже. Поэтому те же ОФЗ, хоть и имеют процент ниже, но позволяют торговать волатильность без потери купонов. А флотеры по сути и есть аналог вклада, например 29014, 29106. Дают доходность как вклад, купоны раз в квартал, но тоже позволяют торговать их. Ставка зависит от RUONIA.

Что касается Самолёта, то это реальность - лесенкой собирал, лесенкой сдавал. Также как и по другим облигациям, которые упали после октябрьского заседания, а в декабре выстрелили обратно.

Что касается срочки, то я предпочитаю календарные спреды. Простые фьючи тоже торгуются, но чаще это просто позиция для защиты. Заниматься спекуляциями как работой желания нет, банально надоело.

Для облигаций есть достаточно инвестиционных стратегий, например Колесо. В моём понимании надо иметь три части в облигациях:
1. фиксированный купон - это фиксация, но набирать надо когда есть дисконт к цене.
2. флоатеры - это как раз аналог вклада. Получаете текущий средний процент на рынке, не думая ни о чём. Например 29014, 29016 и далее.
3. торговля тела - т.е. покупаем на просадках, продаём на росте. При этом эта часть может дать даже намного больше, чем купоны.

Что выбирать - дело субъективное. Кто-то боялся покупать облигации Самолёт недавно, а кто-то за несколько дней собрал десятки процентов от тела. Достаточно было читать отчёт компании, а не потоки анал-итики. Да, риски есть всегда. Но если их исключать (почти), то взять ОФЗ ПК и ПД раных дюраций и не думать. Тем более, что есть RGBI фьючерс. С ним можно еще и расхождения торговать, да и просто как хедж брать.

Что касается 248, то я бы её рассматривал если есть ожидания снижения ставки. Собственно как любая длинная. Да, у неё большой купон YTM - это хорошо. Но я уже с 98 года не планирую далее 3-х лет. А сейчас и более полугода. Так что предпочитаю собирать доход сейчас, а не потом.

Сейчас ОФЗ тоже под налогом. Если только не ИИС на длительный строк.
Основная идея облигаций не в этом, а в том, что они позволяют получать доход как от купона, так и от переоценки тела. И без потери начисленных купонов.
Также стоит учитывать, что эти 24% вклада - это итоговая ставка дохода, сложный процент будет ниже. А вот в облигациях как раз можно реальную доходность получить выше, т.к. выплата купонов может быть раз в квартал или даже в месяц. А если говорить о том, что облигации тоже ходят каждый день на 0.5% и более, то и это можно торговать сеткой. Иногда в день до 5-10 сделок бывает.

Скорее наоборот. Эти 24 в банке - это, скорее всего, без капитализации и на длительный срок. С облигациями это не так. Например, облигации с купоном каждый месяц уже дают намного больший денежный поток.
Плюс еще переоценка тела. Также облигации, как и любой торгуемый инструмент позволяет собирать волатильность, т.е. торговать небольшие движения. Это как выйти из вклада через неделю без потери процентов. Так что нет, вклады хоть и спокойней, но облигации могут дать намного больше. Правда для этого надо приложить немного усилий.

Что касается ожиданий, то да 38-мые могут выстрелить. Впрочем, ОФЗ - как вклады в банках. Можно зафиксировать доходность на года и выйти в любой момент. А для спекуляций, например, совсем недавно облигации Самолет давали под 50%. Или Россети ЛЭ, да и тот же недавно размещённый Магнит. Я люблю короткие облигации с 30-и дневной выплатой.

Они рекомендую как раз два параметра STATUS и TRADINGSTATUS. Первый не все брокеры транслируют. Второй, вроде, все.

Если для параметра TRADINGSTATUS вернулся result == '1', то можно увидеть идут ли торги по значению param_value из возвращаемой таблицы.
Здесь на форуме были как-то написаны значения.

Правда для срочного рынка надо еще смотреть на параметр CLSTATE.

Речь о поведении данных в таблице money_limits поле limit_kind. Вы предложили реализацию через перебор данных и поиск максимального. Такой подход возможен, да. Но возникает вопрос - почему вносимые изменения потребовали использования такого подхода.

limit_kind - это режим торгов инструмента, он задан в его спецификации и не изменится в течении торговой сессии. Наоборот, это достаточно постоянный параметр. То что дата расчётов в связи с выходными может быть дальше, не означает, что необходимо теперь переходить на хранение даты. То что в течении торговой сессии произошли с сделки с инструментом, не означает, что его режим торгов изменится. Он как был Т+1, так и остался. Просто позиция будет той же завтра, если нет сделок, не более. Сейчас же происходит замечательная вещь - нет сделок, получаем режим торгов Т+0 (текущая дата), совершили сделки, получаем Т+1 (следующая дата). Т.е. можно было бы добавить дату расчётов в таблицу, чтобы знать когда произойдут взаиморасчёты, но базовый фильтр limit_kind почему был изменён - совершенно не ясно. Это не дата расчётов. С этим можно было жить как раньше, если бы он не изменялся в течении торгов, но и это не так. Теперь действительно необходимо постоянно сканировать на поиск максимального значения.

Хотя нет, это ваша реализация так работает. Прямой фильтр по money_limits требует точного соответствия. Это, конечно, просто великолепно вносить изменения ломающие обратную совместимость в ключевые механизмы по работе с инструментами.

В данной схеме обнаружена она проблема, затрудняющая её использование. В таблице money_limit поле limit_kind может изменится в процессе работы. Например, считываем данные по инструменту, по которому нет позиции, получаем текущую дату. Открываем позицию и в поле limit_kind уже дата +1. Не очень понятно как предлагается работать, если данные параметр будут постоянно изменяться. Если только просто не прибавлять всегда 1, т.к. заявляется, что вернётся ближайшее значение.

Проблема не в инструкции, а в невозможности выполнить действия, сформулированные там. В данном руководстве предлагается использовать платный продукт, который на данный момент не поддерживается на территории где работает терминал. И даже если бы поддерживался, предлагается ради получения имён параметров купить программный продукт за 6000 руб. Спрашивается - это как понимать? Т.е. вывести набор полей в инструкцию - так сложно, что пусть пользователи сами с этим возятся.

Это похоже на то, что есть, но явно не то, что есть в ТТТ. Для примера, параметр MINSTEP в описаниях в Квике уже SEC_PRICE_STEP, а параметра MINSTEP нет.

Я уже не раз писал об этом. У меня, например, MS Office нет. Нет желания платить деньги, а устанавливать сломанное тем более. Тем более, что есть бесплатный облачный от того же MS. Раза два в год открыть документы достаточно. Но точно это не нормально - устанавливать тяжеленный пакет с потенциально опасными приложениями (вспоминаем про исполнение скриптов даже не открывая файл) только для того, чтобы узнать формальное описание полей. Мне проще собрать DDE сервер на С для этой задачи. И всё это потому что их описания нет в документации.

Вот исходная статься из 2011 года https://tr8dr.wordpress.com/2011/03/04/detecting-price-direction-in-order-flow/
Прошлая ссылка была перевод, не сразу нашёл у себя в закладках исходник.

Обычно не обсуждаю торговые стратегии, у всех свои предпочтения. Но регулярно выходят стратегии основанные на перевесе сторон стакана. При этом я помню как был период, когда перевес стороны означал движение в их пользу, потом наступил период, что всё наоборот - движение в сторону плотности. Как сейчас не знаю, возможно опять власть поменялась. Это к тому, что стакан - это половина данных. Основываясь только на неё сложно что-то сказать.Тем более, что если использовать типовой поток данных, то видимая часть в лучшем случае  - это всего 50 линий. Суммарные величины тоже малопоказательны, т.к. где там эти плотности - не видно.

В уже далёкие 00-е, когда восходили кванты, сразу стало ясно, что необходимо соотносить информацию из стакана с лентой сделок. Сопоставляя, понимать что исполнилось, что сняли, что переставили, с какой скоростью идут все эти события. И анализируя это, получать паттерны поведения. Вот, для примера, статья из 2017 года - https://www.quantalgos.ru/?p=2833

Поэтому уже давно всё переведено на чтение состояния сессии по конкретному инструменту. Он же может и в обычные дни встать на стоп торги в середине торгового дня. Если бы этот параметр ещё не транслировался с задержками, было бы замечательно.

В Junior транслируется в поле limit_kind дата в виде числа. Т.е. можно взять максимум. У меня в скриптах параметр "Режим торгов" не задаваемый, а определяемый. Работает как на реальном счёте, так и на демо. Вы же не будете для каждой бумаги руками указывать режим торгов, тем более, что до недавнего времени были как Т+2, так и Т+1. Какие-то бумаги переводили на другой режим. Т.е. это получаемая биржевая информация, а не задаваемая.

Подход особо не изменился - найти максимальное числовое значение в таблице money_limit по полю limit_kind. Либо, если версия терминала выше 10.2.0, передавать не число, а строковое значение "Tx" - это такое тихое нововведние.

Есть простой, прямой вопрос - можно ли в окружении терминала выполнить другой скрипт, контролировать его состояние. Ответ - нет.
Вы же говорите о том, что давайте вместо поставленной задачи преобразуем её к виду, когда другие скрипты - это модули, выполняющий какие-то действия и контролируемые и выполняемые в окружении скрипта дирижёра. Т.е. по сути - это не отдельные скрипты, а один.

Да, такой подход возможен. Но это не то же самое. Понимая, что прямой вариант невозможен, можно попробовать решить через второй вариант. Но он не всегда применим, т.к. есть скрипты не с открытым кодом, с сложным окружением и т.д. Любители использования dofile могут попробовать запустить так два модуля, использующих переменные с одинаковым именованием.

Т.о. ответ должен быть таким - окружение скрипта, запускаемого в терминале не предоставляет информацию о состоянии других скриптов, не имеет методов запуска/остановки других скриптов, содержащихся в окне списка доступных скриптов LUA терминала.

При этом обмен данными между скриптами сделать можно. А значит существует и третий подход - это иметь два контура в контролируемых скриптах: холостой и рабочий. Тогда скрипт будет отдельной сущностью, его можно отдельно запустить в терминале. Скрипты постоянно работают, но переходят в разные состояния по командам из контролирующего скрипта, через обмен данными. В таком подходе важно обеспечить перехват ошибок, чтобы контролируемый скрипт не "упал". Но опять же - необходимо иметь открытый код скриптов.

Если под котировками подразумеваются бары-свечи, то вот писал как-то давно  https://github.com/nick-nh/qlua/tree/master/barsSaver

Совершенно бесплатно.

Нет, штатных средств для этого нет.

Подниму тему.

Читаем справку:

Универсальный формат позволяет отправлять любые транзакции, если известно их  описание

Описание набора полей транзакции можно посмотреть в окне создания кармана транзакций.

Ок. Смотрим на поля окна для фондовой секции по акциям. Есть такое поле "Код клиента". Собственно оно обязательно для акций.
Вводим в карман транзакций заявку, указывая код клиента. Сохраняем в файл. Смотрим - а кода клиента нет. Ну ладно, бывает.
Пробуем отправить транзакцию в этом формате, добавив поле "Код клиента" (выше же сказано, что поля можно увидеть в окне).

Получаем:

Ошибка выставления лимитной заявки: Не найдено поле "Код клиента" для транзакции "Ввод заявки" по классу "Акции 1-го уровня (эмулятор)"

Убираем поле "Код клиента" - работает. Но как же так, код-то нужен. Код видно только в поле "Примечание" вместе с введённым комментарием.


Внимание вопрос: это так демо-сервер работает или лыжи не едут...

Этот квест с универсальным форматом просто великолепен. Если бы сделали перенос заявки в фиксированном формате, то, видимо, никто бы не задавал больше вопросов. Но нет...

Согласен, но иногда просто слов нет. Да и в двух словах не опишешь проблему.

Индексы от 0. Т.е. первая строка - это индекс 0.

Да, у меня выделенный IP адрес. Но я очень сомневаюсь в его влияние. В 90-е, ещё можно было ожидать, что как-то будут его учитывать, но уже с 00-х он стал бесполезен. С учётом того, что большинство участников живёт за разными шлюзами, прокси серверами, используя "плюшевые" адреса, совершенно не подозревая какой у них адрес. Подозреваю, что здесь связь по типу P2P с использованием некого уникального ключа-токена установленного соединения.

Ну и если говорить о смешивании пакетов в терминах баз данных, я бы понял если бы было полное соединение, а здесь левое. Только в одном терминале подмешана информация от другого, и только таблица ордеров. Баланс счёта, да и сами счета субсчета не смешаны.

Да, оба терминала версии 11.4.0.54

Брокер Сбербанк. Действие 24.01.2025

Есть два брокерских счёта у него. Два терминала Квик. После очередного обрыва связи, которые на этой неделе почти каждый день, ордера из одного брокерского счёта стали видны в таблице Квика другого брокерского счёта. Буквально - есть записи с несуществующим кодом клиента для этого счёта, терминала. Что ещё забавно, если снять ордер в этом терминале (хотя этот ордер не принадлежит этому брокерскому счёту), то он также снимается и в другом. Вот такая загогулина. Если бы не было печально, то, наверно, можно было бы посмеяться. Возникает вопрос - как серверная часть терминала допускает такое? А если бы стали видны ордера совсем другого клиента?

Прикладываю картинку. Один терминал и окно другого терминала. Видны ордера из первого во втором. Если это не критическая уязвимость связки терминал-сервер, то я не знаю что это.
И просьба не говорить о том, что брокер может что-то настроить у себя на серверной части. Такого просто не может быть, ни при каких обстоятельствах.

Это скорее всего из-за того, что в этот момент происходит очистка всех справочников и в момент транзакции они ещё не загрузились с сервера. После какой-то версии терминала это стало повально почти у всех брокеров. Пришлось изменить процедуру запуска скриптов, с ожидающей задачей, пока всё что необходимо не будет загружено.

sleep обычно небольшой от 10 до 60 млс. Зачем 200 сразу.
Сделки надо учитывать, да. Но их можно очищать уже через день. Даже на след. день, исключая те, что в вечернюю сессию на срочном рынке. Их и с колбеками необходимо учитывать, т.к. колбек может и приходит несколько раз на одно событие. А значит чтобы исключить повторный учёт, необходимо их запомнить. Особой проблемы в этом нет.


Да, будет. По одному ордеру может быть неограниченное число сделок, если представить такой ордер.

Биржа в последнее время не транслирует купон для флоатеров. Данные же терминал не сам формирует. Даже на очень многих ресурсах перестали ставку показывать, т.к. они тоже просто брали поток биржи. Приходится идти в проспект эмисии.

Я предпочитаю таблицы. Кто-то колбеки. Причина выше - всё равно необходимой пройтись по сделкам, ордерам, чтобы проверить что случилось с момента прошлого запуска скрипта.
Да и надёжней это. Хоть и кто-то скажет - как можно, это же "прошлый век". Но в том-то и дело, что если задача надёжно получить информацию, то необходимо в реальном времени постоянно опрашивать датчик. Так и здесь. Мы же про деньги говорим и алгоритмы в реальном времени работают.

Логика проста. Колбек - это реакция на событие, в терминале - это изменение соответствующей таблицы. Например, установили ордер - появилась запись в таблице ордеров. Ордер исполнился - изменился статус (флаг состояния). Всё, вроде, красиво. Обработай колбек - получили результат. Минимум усилий, скрипт почти всё время работает в холостую, ожидая колбеки.

Но, как говорил выше, реальность же сложнее. Скрипт может быть остановлен, а ордер исполнился в это время. Пользователь решил руками закрыть или открыть позицию - а почему нет, спрашивается. Сдвинул ордер на графике и т.д. Да и просто может выключить терминал вечером, когда ещё идет вечерняя сессия. Не у всех терминал на постоянно работающем VPS.

Т.е. есть разные ситуации. Если Вы пишите скрипт для себя и прекрасно понимаете что можно, а что нельзя делать, то да, используйте колбеки, понимаю их риски. Плюс учитывая, что они приходят не один раз на одно событие. А вот если скрипт не для себя, то уже приходится писать с расчётом на то, что будет выполнено всё то, что Вы не предполагаете. Могут даже пожаловаться на то, что сделка не открылась после выключения терминала. Я же скрипт запустил, выключил терминал чтобы не сидеть перед ним - где сделка?

Это уже новая информация. Какая минимальная версия терминала, поддерживающая данную функциональность?

И сразу возникает вопрос: как будут работать методы, где есть входной параметр limit_kind?

Сообщение в терминале увидел. Вот оно, чтобы было понятно остальным:

Здравствуйте.С 16 января сервер QUIK Junior переведен на современную схему ведения позиций - по календарным датам. Если ранее каждой позиции соответствовал код расчетов (T0, T1, T2), то теперь - конкретная дата.
Например, если сегодня 16.01.2025, значит код расчета T0 соответствует дате расчета 16.01.2025, код T1 - 17.01.2025 и так далее. Ожидается, что в будущем на эту схему перейдет большинство брокерских компаний. Кроме того, теперь расчеты по всем инструментам на сервере происходят по схеме T+1, что соответствует режиму реальных торгов на Московской Бирже.
В связи с этим в таблицах с позициями по инструментам и деньгам следует заменить параметр "Срок расчетов" на "Дата расчетов". В таблице "Состояние счета" вместо кодов расчета теперь подставляется конкретная дата.


Правда это, конечно, несколько неожиданно, не говоря уже о каких-то формальных документах. Спрашивается а как теперь для инструментов, торгуемых в разных режимах определять позицию. До этого можно было найти максимальный limit_kind и по нему фильтровать записи. И он не изменялся. Теперь же схема работы становится печальной - каждый день этот параметр будет изменяться, т.е. необходимо заново его обновлять, и это если брокеры не придумают чего-то еще. На сайте биржи да и в транслируемых данных есть показатель режима торгов для инструмента. Никаких расчётных величин нет. Зачем это, какую проблему решает это нововведение? Представляю, что ждет работающие скрипты при переходе брокеров на этот режим.

Сегодня на тестовом контуре в таблице depo_limit получил такое:

limit_kind = 20250116

Это что? Ясно что дата. Но с какой такой... Я не слышал о новом режиме торгов в виде даты. Есть Т0, Т+1, Т+2, TOD, TOM и новое Т365, отображаемое в терминале Тх.

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

Так что я лучше проверю руками в самом источнике информации. Тем более, что этот контур всё равно необходимо реализовывать, например, при перезапуске скрипта. Колбеки прошли давно, а понять ситуацию необходимо сейчас.

Позицию же необходимо вести самостоятельно. Да, бывают ситуации когда сделка прошла вне работы скрипта и необходимо провести выравнивание. Но в целом, прошла сделка - запомнил. Запустил скрипт - просканировал сделки и убедился, что запомненная позиция корректна с точки зрения количества. Где запоминать - это выбор по предпочтениям. То ли в файле состояния, то ли в базе данных. Не важно. Лог файл не предназначен для хранения информации, это инструмент анализа.

Не видел таких проблем для единого счёта. Вы бы вывели поля каждого счёта, да посмотрели что у него в поле классов.

Пишите сервере на lua, открываете наружу порт и пожалуйста. Правда смелость этого решения высока.

В папке socket должны быть еще файлы lua, реализующие протоколы.

Ищите библиотеку socket. Она поддерживает http. Безопасное соединение не поддерживает, для этого необходимы дополнительные библиотеки, в частности luasec.

Справедливости ради - это не среда Linux. Вот если бы терминал был нативный для Linux - это было бы прекрасно.

Проще сделать автосинхронизацию каталогов. Изменяя базовый, остальные зеркалируются.

В самом lua нет методов сетевого взаимодействия. Но Вы можете по подключить библиотеку socket (дополнительная) и уже сделать это. Правда если требуется безопасное соединение, то необходимы ещё дополнительные библиотеки, обеспечивающие это.

А причём здесь Квик? Где изменение данных в переменой localtime. Оно как осталось от инициализации так и не изменяется.

Как пользователь MacOS уже более 15 лет был бы раз видеть это. Но так уж сложилось в мире финансов - основные профессиональные инструменты на Windows. И это не только здесь, но и по всему миру так.
Это положение изменяется  постепенно, но не в ту сторону как хотелось бы. Теперь все делается на серверах Linux как backend, а интерфейс рисуют через Web приложение, что ужасно. Это пусть для масс. Проф. участники продолжают использовать свои решения и Mac там представлен минимально.

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

Тестовый контур Quik Junior 11.3.2.2

Ответ транзакции:
[INFO  2024-09-18 13:13:09] : OnTransReply all trans count: 8 | sec_code SiZ4 result_msg: Ответ из торговой системы не получен, статус исполнения транзакции неизвестен. За уточнением просьба обратиться к Вашему брокеру. status: 4 trans_id: 50553350 order_num: 0 price: 80013 qty: nil account SPBFUT000i4 client_code SPBFUT000i4 firmid nil brokerref SPBFUT000i4//NTR01


Не то чтобы нужен ответ, но просто хотелось бы понять причину. Это что-то новое: запрос сделан, ответ - кто же знает что там случилось.