как видно, на игровом сервере limit_kind закодирован датой расчета. В моем случае они бывают 20250426, 20250427, 20250428 и так далее на боевом сервере limit_kind изменяется от 0 до 3.
Соответственно, скрипт, работающий на демо, разваливается на боевом.
Вопросы.
1. Как понять ситуацию, когда разные терминалы одной версии дают данные в разных форматах? 2. Как написать скрипт, чтобы он нормально работал везде сейчас и в дальнейшем? Мне нужно получить позицию по инструменту, разбивка по датам расчета не нужна
Существует ли какая-нибудь внятная документация, где сформулировано, что есть дата расчета, откуда она берется, по каким правилам формируется, что такое Тх и все остальное? Чтобы не бродить впотьмах, а просто понять.
Мне нужно следующее. Терминал, в нем происходят сделки. Нужно в колбеке ondepolimit в момент изменения позиции по инструменту найти ПОЛНУЮ позицию по этому инструменту без каких либо дат расчета и скажем, вывести ее не экран.
Есть ли какой нибудь разумный алгоритм, который позволит это сделать и у втб-подобного брокера, и у тех, кто уже исполнил перестройку и гласность?
tohoki написал: Существует ли какая-нибудь внятная документация, где сформулировано, что есть дата расчета, откуда она берется, по каким правилам формируется, что такое Тх и все остальное? Чтобы не бродить впотьмах, а просто понять.
Мне нужно следующее. Терминал, в нем происходят сделки. Нужно в колбеке ondepolimit в момент изменения позиции по инструменту найти ПОЛНУЮ позицию по этому инструменту без каких либо дат расчета и скажем, вывести ее не экран.
Есть ли какой нибудь разумный алгоритм, который позволит это сделать и у втб-подобного брокера, и у тех, кто уже исполнил перестройку и гласность?
В данном случае - это нововведение разработчиков терминала, впрочем, даже скорее всего менеджеров. На бирже есть понятие "Режим торгов (расчётов) Т+", и ранее limit_kind вполне повторял его. Теперь же это не так, т.к. там дата и режим - это разница текущей и даты в параметре (условно). Что уже не соответствует понятию "Режим торгов", т.к. уже отражает дату проведения расчёта. Скорее всего решения было принято для того, чтобы было видно в какую дату произойдёт расчёт, что режим торгов Т+ не давал, т.к. могут быть выходные, праздники и т.д.
Впрочем, как и ранее, алгоритм такой же - найти максимум limit_kind в таблицах - это и будет необходимо значение. Правда теперь стоит учитывать, что дата в limit_kind может изменится в течении сессии. В начале, когда не было ни одной сделки, там будет текущая дата, что соответствует Т+0, а после там может быть завтра, что уже будет Т+1. Что тоже явно противоречит спецификации инструмента, т.к. режим расчётов условно постоянен и не изменяется в течении сессии.
на вопрос, почему в разных терминалах мы видим разные представления данных, ответа не нашел.
Там же написан ответ:
Ожидается, что в будущем на эту схему перейдет большинство брокерских компаний.
Получается, что программист должен располагать информацией, к какому брокеру подключен терминал, обновила ли эта брокерская компания схему подачи данных и предусмотреть разную их обработку.
Как минимум, удивлен. А вообще - такой восторг я испытываю, когда разбираюсь в шедеврах от индусов
Nikolay, спасибо. Проверю подход с поиском максимального limit_kind
В общем и целом, утверждение, что depolimit с максимальным номером limit_kind дает общее количество лоток/контрактов, выглядит верным. А вот когда нужно смотреть что у нас там в T0,T1,... то начинается мазохизм с разборками "а это новый или старый вариант depolimit? Старый? Тогда вызываем обработчик1. Новый - тогда делаем обработчик2". И страшный нерешаемый геморрой с торговыми датами, когда накладываются выходные и особенно праздники, так как календаря праздников и тем более переноса рабочих дней в доступе нет. Индусы среди нас, без вариантов.
Пока ковырял весь этот варёный рис, нарвался на ситуацию. Отправляю транзакцию на установку рыночного ордера. Получаю ответ
17:10:11.497 > Ответ на транзакцию: {result_msg="(161) Заявка N 9560658713 зарегистрирована и снята из-за отсутствия встречных котировок",date_time={day=30,week_day=3,min=10,hour=16,month=4,ms=601,mcs=601153,sec=10,year=2025},quantity=4,price=0,first_order num=0,got_local_time={day=30,week_day=3,min=10,hour=13,month=4,ms=497,mcs=497542,sec=11,year=2025},uid=3765,flags=2490369,firm_id ="NC0011100000",sec_code="AGRO",time=161010,sent_local_time={day=30,week_day=3,min=10,hour=13,month=4,ms=433,mcs=433926,sec=11,ye ar=2025},error_source=0,exchange_code="",class_code="QJSIM",trans_id=103070188,error_code=0,client_code="qtest658",account="NL001 1100043",gate_reply_time={day=1,week_day=1,min=0,hour=0,month=1,ms=0,mcs=0,sec=0,year=1601},balance=0,order_flags=4,status=3,orde r_num=9560658713,brokerref="qtest658//",server_trans_id=26}
Что мы тут видим? status = 3, что в руководстве по камасутре означает
«3» – транзакция выполнена;
Ну раз выполнена, то ждем исполнения рыночного ордера. Но исполнения, понятное дело, нет.
Существует ли нормальный вариант отследить эту ситуацию? Чтение текстовой диагностики или священные танцы, пожалуйста, не предлагайте.
Предположу следующее транзакция выполнена - это правда, так как заявка доставлена без ошибок в ней и принята биржей но заявка не выполнена и причина указана в ответе. Что не так?
nikolz написал: Предположу следующее транзакция выполнена - это правда, так как заявка доставлена без ошибок в ней и принята биржей но заявка не выполнена и причина указана в ответе. Что не так?
Судя по вашему ответу, вдобавок к статусу = 3 необходимо читать текст сообщения.
Ну ок, давайте подумаем.
1. а какие еще могут быть текстовые ответы, кроме "нет встречных котировок", чтобы понять, что ждать исполнения не нужно? В камасутре я ничего даже похожего не нашел
2. Я тут видел, что терминал знает русский и английский языки (но почему то не знает хинди). Получается, нужен еще список ответов на английском?
3. А как узнать, на каком языке сейчас трудится это чудо? Я не нашел камасутре по этому поводу ничего. grep нашел в каких-то файлах терминала ключ Language, но всему должна быть мера
И вопрос к здравому смыслу. Если терминал знает, что заявка была снята (он ведь эту информацию дает) почему бы ему не вернуть не 3 в статусе а 333? Это же нормально и логично. Он же возвращает статусы типа Транзакция не прошла контроль дополнительных ограничений, или Кросс-сделка, а чем наш случай принципиально отличается? В чем разница между Зитой и Гитой?
Получается, чтобы писать нормальный текст, а не песни Болливуда, нужно после отправки транзакции, получения ответа ontransreply со статусом 3 в процессе ожидания колбеков onorder еще асинхронно проверять состояние заявки на предмет снятия. и если приехал бит снятия в заявке, прекращать ожидание сделок по заявке.
Терминал в данном случае - это просто труба, что пришло с биржи, то и показал. Сам не придумывает. Такой ответ, кстати, возможен если тип ордера вышел "исполнить или снять". Раз встречных нет, то снята.
Код ответа, конечно, мог бы быть более разнообразным, но мы уже привыкли. Также все же это больше зависит от алгоритма. Отправляя рыночный ордер не стоит ожидать, что он исполнится, как раз наоборот, стоит ожидать, что нет. Плюс не стоит отправлять рыночный ордер не проверив есть ли встречные ордера. Когда их нет - это не имеет смысла.
Также пока пакет дойдёт до биржи в стакане может стать пусто - и это нормально и надо это предусматривать. К тому же рыночный ордер - это абстракция. В ядре бирже есть только лимитные ордера по ценам внутри допустимого диапазона. Рыночный - это просто ордер по границе, чтобы встречный был с очень большой вероятностью. А вот когда встречных нет, то и выходит проблема.