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

Вопрос по DDE экспорту таблиц:
можно ли со стороны подписчика как-то инициировать переотправку Квиком таблицы целиком (так, как происходит при изначальном старте экспорта)

Спасибо BlaZed, можно и так сформулировать.  В поле "Комментариq" в таблице заявок всегда прилетает номер счета.

1. вне зависимости от того что пишем в параметр CLIENT_CODE транзакции подаваемой через trans2quik
2. вне зависимости от того что пишем в окне подачи заявки в терминале в полях "Код клиента" и "Поручение".

Проблема конкретно у АЛОРа и сильно осложняет жизнь алготрейдерам.

Если в терминале в окне заявке указывать произвольные, то они должны использоваться?

А в таблице заявок получается Счёт=Комментарий=Код-клиента= SPBFUT1234F

Ага, пробовал поковыряться c этим.
По-моему, это влияет только на подстановку в окне ввода заявки?

В любом случае, как не меняй эти настройки, и в ручной заявке из терминала, или в заявке подаваемой через trans2quik, - всё равно в "Комментарии" к заявке всегда оказывается номер счета.  Рабочая гипотеза такая что это какая-то настройка у брокера.

            string asynchstring = "ACTION=NEW_ORDER"
               + "; TRANS_ID=" + transid
               + "; CLASSCODE=" + classCode
               + "; SECCODE=" + secCode
               + "; ACCOUNT=" + account
               + "; TYPE=L; OPERATION=" + operation
               + "; QUANTITY=" + absamount
               + "; PRICE=" + price
               + "; CLIENT_CODE=" + comment;


И далее содержимое comment у нас будет в столбце "Комментарий" в таблице ордеров  (или в колбэках это brokerref).
Комментарий пользователи обычно использовали чтобы помечать ордера для внутреннего учета в своем ПО.

Сейчас столкнулись с тем что у Алора игнорируется то, что мы передаём в CLIENT_CODE, и в "Комментарии" всегда будет номер счёта.
Невозможность как-либо пометить ордера сильно осложняет их учет для разных стратегий, роботов и т.д.

И всё-таки хотелось бы ответ от тех.специалистов ARQA.


Такая настройка сделана именно на стороне сервера(брокера) и никак со стороны клиента не изменить такое поведение?

Столкнулись с тем, что в брокере А..р    не получается указать произвольный коммент к ордеру в CLIENT_CODE.     По итогу постановки заявки там всегда оказывается номер счета
SPBFUT1234F.     Невозможность пометить ордера ломает логику менеджмента заявок...

Вопрос такой:    замена CLIENT_CODE происходит на стороне брокера из-за каких-то особых настроек сервера ?     Или может всё-таки в локальных настройках терминала как-то можно подшаманить?

А через trans2quik ?

"Новый тип заявки будет доступен в квиках  начиная с версии 10.0, вышедшей 26.10.2022 г. Значение «Только пассивная» появится в параметре «Условие исполнения» в окне ввода заявки."

А как выставлять их через транзакции?

Всё-таки не NetOptionValue.  Не понятно что транслируется в эту колонку.

Да, судя по всему, в столбец "Премия по опционам" транслируют NetOptionValue, которая отрицательная для проданных опционов.

Решил потестировать на отдельном пустом счете новые опционы на акции. Брокер Финам.
Продал пару штук до вечернего клиринга.
После клиринга смотрим таблицу "ограничения по клиентским счетам".
Параметр "премия по опционам"  - почему то отрицательный, соответствует сумме премий с минусом.
В итоге вижу что цифры бьются таким образом:
План.Чист.Поз = Лимит откр.поз  - Тек.Чист.поз(ГО) + премия по опционам.    
Получается, в итоге и ГО, и премии от проданных (!) опционов уменьшили свободные средства.   Но почему? Я же должен получить эти премии?
Не мог ли брокер налажать с настройками?

В тему, может, связано с этим:

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

3. Изменения в расчете свободных средств ТКС Spectra под опционы на акции Так как новые опционы являются премиальными, то к ним применяются особые правила исполнения требований и обязательств. В первую же клиринговую сессию после заключения сделки, производится взаиморасчёт по премиям. То есть расчет происходит "тут же", без ежедневного перечисления вармаржи, как в случае с маржируемыми опционами. Премиальные опционы имеют стоимость и (по просьбам участников) будут использоваться в качестве обеспечения по портфелю, а также влиять на объём свободных средств (FreeMoney). Величина корректировки FreeMoney будет доступна в виде нового параметра NetOptionValue (NOV), который будет рассчитываться в ближайшую клиринговую сессию как сумма произведений учетных стоимостей и объемов соответствующих опционных позиций в портфеле с учетом знака: NetOptionValue= voli * RCi * MinStepPricei / MinStepi • voli – объем позиции в i-м опционном контракте по итогам текущей клиринговой сессии; • RCi – расчетная цена i-го опционного контракта по итогам текущей клиринговой сессии. Величина NetOptionValue (поле net_option_value таблиц part и part_sa потока FORTS_PART_REPL) определяется по каждому уровню учёта позиций (7CC, BF, SA). Для фьючерсов и маржируемых опционов на фьючерсы значение NOV всегда равно нулю. 4. Новый индикатив - величина премии подлежащей к уплате/получению в ближайшую клиринговую сессию Поскольку по премиальным опционам на акции вариационная маржа отсутствует, значения VM, выдаваемые ТКС всегда будут нулевыми по таким инструментам. В связи с этим появляется новый индикатив по премиям (поле premium в таблице opt_vm потока FORTS_VM_REPL), отражающий величину премии к уплате/получению в ближайшую клиринговую сессию. Вычисляемое значение не включает в себя финансовый результат исполнения опционной позиции в день экспирации опционов на акции. Данная величина рассчитывается индикативно, исключительно для информирования Участников клиринга. А поскольку расчеты могут производиться не только в рублях, то трансляция премии в валюте расчётов будет осуществляться в отдельном поле premium_in_settl_currency таблицы opt_vm потока FORTS_VM_REPL. При начислении или списании валютной премии будет меняться торговый лимит на 7CC и на БФ (с опцией свободного управления лимитом). Величина изменения лимита равна объёму премии в валюте, пересчитанному в рубли по курсу валюты, зафиксированному на момент клиринга.

Возможно, для ALGO_VOLATIL или айсбергов, где одна алго-заявка может порождать много биржевых.. внутренний нумератор транзакций и нужен..  (Кстати, по какому принципу он работает? Просто инкремент счетчик?)

Но может ли одна ALGO_GTD порождать больше одной биржевой заявки?

Сейчас в order_status_callback поле dwTransID вообще ни о чем пользователю не говорит, он это значение нигде ранее не получает...

Как вы рекомендуете сопоставлять ордерколбэки с ранее поданными транзакциями на алгозаявку? Неужели по комменту? "//67698" в примере (и до этого придется отследить OrderNum=67698 из колбэка на транзакцию) ?

1.  Цена БА  используемая для расчета нужна более быстрая, актуальная стакану
2.  Время до экспирации должно считаться корректно  

Есть ли новости по улучшению алгозаявок по волатильности? В таком виде как сейчас никто не использует их)

00:37:07.155 > TRANS_ID=111456712;CLASSCODE=ALGO_GTD;ACTION=Ввод заявки;Торговый счет=4100***;Направление=Продажа;Класс=SPBOPT;Инструмент=Si85250BB2;Цена=2500;Количество=1;Тип=Лимитированная;Код клиента=test;Комментарий=;Условие исполнения=До времени;Дата истечения=20220121;Время истечения=203730;Оповещения об исполнениях=Нет;Использовать временной интервал=Нет;Время старта=0;Время окончания=0;Внутренний комментарий=;
00:37:07.447 > TrRes=0 TrResStr=TRANS2QUIK_SUCCESS TrExErrCode=0 TrReplyCode=3 TrID=111456712 OrderNum=67698 ResMsg=Алго-заявка № 67698 успешно зарегистрирована.
00:37:07.758 > order_status_callback: mode=0 dwTransID=2314 dNumber=1892947002523673248 classCode=SPBOPT secCode=Si85250BB2 price=2500 balance=1 direction=1 account=4100*** clientCode=4100*** comment=test//67698
00:37:33.344 > order_status_callback: mode=0 dwTransID=2314 dNumber=1892947002523673248 classCode=SPBOPT secCode=Si85250BB2 price=2500 balance=1 direction=1 account=4100*** clientCode=4100*** comment=test//67698
00:37:33.591 > order_status_callback: mode=0 dwTransID=2314 dNumber=1892947002523673248 classCode=SPBOPT secCode=Si85250BB2 price=2500 balance=1 direction=1 account=4100*** clientCode=4100*** comment=test//67698

Получается выставлять алго-заявки со сроком действия через trans2quik. Однако удивило, что меняется TransID.  Это так и задумано?
Для обычных заявок внутренний учет в своем ПО происходит через TransID.  А в вышеприведенной логике, где id меняется, надо придумать как сопоставлять ордер-колбэки с тем, что до этого отправил..

Есть ли возможность в TRANS2QUIK_TRADE_STATUS_CALLBACK получить вот эти параметры?

2. В таблице «Сделки» поддержано отображение новых типов сделок Срочного рынка МБ:
— «Сделка исполнения фьючерса»;
— «Сделка исполнения опциона»;
— «Сделка истечения опциона».

Кто знает какая ситуация на 2021 год с FixClientConnector?  Может, кто-то из брокеров предоставляет недорого этот коннектор?  

Вопрос по использованию алго-заявок, а именно заявок, которые котируют заданную волатильность.

1. Из документации стало понятно что для расчета цен опционов по БШ используется "Расчетная цена" базового фьючерса (12 срезов цен каждые 5 секунд плюс умедиванивание согласно биржевой методике).  Для ликвидных фьючерсов такие сглаживание видится избыточным.  Пожелание от опционщиков - использовать Цену последней сделки (можно опционально на выбор пользователя).

2. Есть вопрос по тому как берется время до экспирации (опять же для рассчета цен опционов из БШ).  Некоторые говорят что раньше был глюк, т.к. брались (дней до экспирации / 365). При этом дни до экспирации брались только целые (такое, конечно, совсем не годится).  Прошу уточнить как именно сейчас рассчитывается время до экспирации в модуле алго-заявок. Хотелось бы секундной точности, т.е. что-то вроде (DateExp - DateTimeNow).TotalSeconds / 31536000).

В общем, подведу некоторые итоги.

Какие варианты предлагает ARQA для алготрейдеров и разработчиков сопутствующего ПО для взаимодействия с QUIK (терминалом/сервером)? (LUA и QPILE не рассматриваем).

1) отправка заявок Trans2quik, получение данных через DDE/(LUA+dll).  Нельзя назвать полноценным API, неудобно, но схема работает.
Плохие новости: когда при очередном обновлении появляется баг в Trans2quik, ломающий всю вашу логику, то баг так и не будет устранён по прошествии 100 дней и перспективы неясны (forum.quik.ru/forum12/topic2025/).

2) знаем, что существует нормальный серверный API, через который работают мобильные приложения poсketQUIK/iQUIK и другое официальное ПО.  Казалось бы, вот она, золотая середина - вариант с удобным алгодоступом для тех, кому не нужно очень-высокоскоростное и высоко-затратное-финансово прямое подключение к бирже.  И что-то вроде 250-400 руб в месяц (типичный тариф у брокера за включение галочки API для клиента) - адекватная цена всех сторон.
Представим: сторонние разработчики делают разный софт для клиентов, клиенты платят брокеру адекватные 250-400 руб, брокер платит ARQA - все счастливы...
Плохие новости: ARQA не даёт в паблик серверный API. Почему - никто не знает. Есть упоминания о "хакерских" вариантах (forex.kbpauk.ru/showflat.php/Cat/0/Number/318297/an/0/page/0#Post318297) Кстати, если у кого-то есть такой работающий вариант - напишите, плз.

3) знаем, что есть модуль, позволяющий использовать протокол FIX подключаясь напрямую к QUIK-серверу. Стандартный протокол для алготорговли, куча библиотек - хороший вариант...
Плохие новости: модуля нет почти ни у кого из брокеров, и, главное, цена - порядка 6000 руб. в месяц.  Т.е. сопоставимо со стоимостью прямого биржевого доступа (что странно) и явно не отвечает запросу "кому не нужно очень-высокоскоростное и высоко-затратное-финансово прямое подключение к бирже".

И что, собственно, остаётся? Ничего, кроме ощущения, что ARQA всячески уговаривает, намекает и стимулирует отказаться от системы QUIK. Как массового клиента, настоящего и потенциального, так и разработчиков ПО.  
Да и с радостью бы уже отказались, если бы это не был "стандарт" нашего рынка, и единственный кросс-брокерный терминал.

+100 дней с багрепорта.

Все определения я знаю. Понятно же о чём речь - о возможности взаимодействия своего ПО с терминалом или сервером для алготорговли.
Если нет нормального API, то применяют разные костыли.  Все варианты взаимодействия с QUIK мне знакомы.

В копилку базы знаний - Церих предоставляет FixClientConnector.   6000 руб в мес без НДС.

В плане разработки ПО под FIX затраты как раз меньше - есть куча готовых библиотек.

По-моему была бы логичная линейка API, условно:
а) нужен алгодоступ, но не нужна скорость :   FIX >> QUIK сервер.    200 руб в мес.
б) стала нужна скорость - легко мигрируем:  FIX >> биржа.         10 тыс в мес.

Просто разработчиков приучили к пляскам с бубном с DDE/LUA для QUIK, но это не от хорошей жизни.

будем собирать по зёрнышку..
В Открытии такого модуля нет.

действительно, сложно через обычных консультантов добиться ответа, есть ли у брокера FIX к серверу QUIK.  Даже на начальном уровне тех.поддержки, по-моему, могут ответить неверно (путая с услугой FIX прямого доступа).
Может кто знает у кого из брокеров такой функционал точно есть?

есть ли новости, когда версию ждать?

Ок, ждём. Костыль пока сделали.

Такое поведение сломало у меня (вероятно, не только у меня) учет заявок по ID транзакций (для чего они, вроде бы, и задуманы).
Раньше после move_order приходили события "заявка с TrID1 снята", "заявка с TrID2 активна", что логично.  
Замена TrID у прежней заявки, по-моему, нелогична.  Если это останется, придётся добавить учёт по Orderid, а TrID теряет смысл.

имеем: выставлена заявка (активная) с TrID=1, пробуем переставлять заявку

сейчас происходит так:
19:09:09.084 >> send_async_transaction ReRegisterOrder TrID=1 > TrID=2  (ACTION=MOVE_ORDERS ... ; TRANS_ID=2 ...)
19:09:09.175 >> TrRes=0 TrResStr=TRANS2QUIK_SUCCESS TrExErrCode=0 TrReplyCode=3 TrID=2 OrderNum=22453644074 ResMsg=Перестановка заявок завершена успешно. New Order1 ID: 22453644074, new Order2 ID: 0.
19:09:09.297 >> order_status_callback: Orderid=22453641959 TrID=2 nstatus=2 (снята)
19:09:09.297 >> order_status_callback: Orderid=22453644074 TrID=2 nstatus=1 (активна)

раньше было бы:
19:09:09.084 >> send_async_transaction ReRegisterOrder TrID=1 > TrID=2 (ACTION=MOVE_ORDERS ... ; TRANS_ID=2 ...)
19:09:09.175 >> TrRes=0 TrResStr=TRANS2QUIK_SUCCESS TrExErrCode=0 TrReplyCode=3 TrID=2 OrderNum=22453644074 ResMsg=Перестановка заявок завершена успешно. New Order1 ID: 22453644074, new Order2 ID: 0.
19:09:09.297 >> order_status_callback: Orderid=22453641959 TrID=1 nstatus=2 (снята)
19:09:09.297 >> order_status_callback: Orderid=22453644074 TrID=2 nstatus=1 (активна)

т.е. проблему можно сформулировать: у снимаемой заявки подменяется TransId.
визуально в терминале это тоже выглядит так: заявка висит как активная с TrID1, а со сменой статуса заявки на "снята" меняется и ID транзакции.  
является ли такое поведение ошибочным или это новая логика?