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

Выбрать дату в календареВыбрать дату в календаре

Страницы: 1
заявки ALGO_GTD, TransID заявок ALGO_GTD?
 
Цитата
Alexander Kopyatkevich написал:
Здравствуйте, Иван Иванов!
Да, TransID меняется по той причине, что Вами указывается TransID для регистрации именно Алго-заявки.
Далее же, во время работы алго-заявки происходит выставление биржевой заявки, транзакция которой будет уже иметь другой номер TransID.
То есть, по итогу, будет две заявки с разными TransID - для алго-заявки и для биржевой заявки, которая была выставлена по алго-заявке.


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

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

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

Как вы рекомендуете сопоставлять ордерколбэки с ранее поданными транзакциями на алгозаявку? Неужели по комменту? "//67698" в примере (и до этого придется отследить OrderNum=67698 из колбэка на транзакцию) ?
Алго-заявки по волатильности
 
1.  Цена БА  используемая для расчета нужна более быстрая, актуальная стакану
2.  Время до экспирации должно считаться корректно  
Алго-заявки по волатильности
 
Есть ли новости по улучшению алгозаявок по волатильности? В таком виде как сейчас никто не использует их)
заявки ALGO_GTD, TransID заявок ALGO_GTD?
 
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
 
Есть ли возможность в TRANS2QUIK_TRADE_STATUS_CALLBACK получить вот эти параметры?

2. В таблице «Сделки» поддержано отображение новых типов сделок Срочного рынка МБ:
— «Сделка исполнения фьючерса»;
— «Сделка исполнения опциона»;
— «Сделка истечения опциона».
Протокол FIX
 
Кто знает какая ситуация на 2021 год с FixClientConnector?  Может, кто-то из брокеров предоставляет недорого этот коннектор?  
Алго-заявки по волатильности
 
Вопрос по использованию алго-заявок, а именно заявок, которые котируют заданную волатильность.

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

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

Какие варианты предлагает 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. Как массового клиента, настоящего и потенциального, так и разработчиков ПО.  
Да и с радостью бы уже отказались, если бы это не был "стандарт" нашего рынка, и единственный кросс-брокерный терминал.
Подмена TransId c версии сервера 5.4.2
 
+100 дней с багрепорта.
Протокол FIX
 
Все определения я знаю. Понятно же о чём речь - о возможности взаимодействия своего ПО с терминалом или сервером для алготорговли.
Если нет нормального API, то применяют разные костыли.  Все варианты взаимодействия с QUIK мне знакомы.

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

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

Просто разработчиков приучили к пляскам с бубном с DDE/LUA для QUIK, но это не от хорошей жизни.
Протокол FIX
 
будем собирать по зёрнышку..
В Открытии такого модуля нет.
Протокол FIX
 
действительно, сложно через обычных консультантов добиться ответа, есть ли у брокера FIX к серверу QUIK.  Даже на начальном уровне тех.поддержки, по-моему, могут ответить неверно (путая с услугой FIX прямого доступа).
Может кто знает у кого из брокеров такой функционал точно есть?
Подмена TransId c версии сервера 5.4.2
 
есть ли новости, когда версию ждать?
Подмена TransId c версии сервера 5.4.2
 
Ок, ждём. Костыль пока сделали.
Подмена TransId c версии сервера 5.4.2
 
Такое поведение сломало у меня (вероятно, не только у меня) учет заявок по ID транзакций (для чего они, вроде бы, и задуманы).
Раньше после move_order приходили события "заявка с TrID1 снята", "заявка с TrID2 активна", что логично.  
Замена TrID у прежней заявки, по-моему, нелогична.  Если это останется, придётся добавить учёт по Orderid, а TrID теряет смысл.
Подмена TransId c версии сервера 5.4.2
 
имеем: выставлена заявка (активная) с 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 транзакции.  
является ли такое поведение ошибочным или это новая логика?
Страницы: 1
Наверх