Иван Иванов (Автор тем)

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

Страницы: 1
DDE request to all table?
 
Вопрос по DDE экспорту таблиц:
можно ли со стороны подписчика как-то инициировать переотправку Квиком таблицы целиком (так, как происходит при изначальном старте экспорта)
COMMENT и CLIENT_CODE
 
Столкнулись с тем, что в брокере А..р    не получается указать произвольный коммент к ордеру в CLIENT_CODE.     По итогу постановки заявки там всегда оказывается номер счета
SPBFUT1234F.     Невозможность пометить ордера ломает логику менеджмента заявок...

Вопрос такой:    замена CLIENT_CODE происходит на стороне брокера из-за каких-то особых настроек сервера ?     Или может всё-таки в локальных настройках терминала как-то можно подшаманить?
Заявка типа BoC - Book-or-Cancel
 
"Новый тип заявки будет доступен в квиках  начиная с версии 10.0, вышедшей 26.10.2022 г. Значение «Только пассивная» появится в параметре «Условие исполнения» в окне ввода заявки."

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

В тему, может, связано с этим:
Скрытый текст
заявки 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. В таблице «Сделки» поддержано отображение новых типов сделок Срочного рынка МБ:
— «Сделка исполнения фьючерса»;
— «Сделка исполнения опциона»;
— «Сделка истечения опциона».
Алго-заявки по волатильности
 
Вопрос по использованию алго-заявок, а именно заявок, которые котируют заданную волатильность.

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

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