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

В соответствии в этим документом пробовал именовать поля, не помогло. Хотя там тоже странно, например поле CLIENTCODE. Я использую в новой заявке CLIENT_CODE и оно работает. Исходя из этого непонятно, кто и где осуществляет конверсию полей, либо есть какие-то допустимые варианты написаний. Как например во всех ответах присутствует как ordernum, так и order_num.

отправил на емейл

хорошо, подготовлю код. А документации совсем нет, где структура данных описана?

не могли бы вы уточнить, какие поля являются строго обязательными для изменения и какие они могут принимать заданные значения?

Трудности именно с транзакцией "Изменение заявки".
Пробовал разные комбинации названия полей и их значений (на русском, на английском), но так и не смог ни разу добиться изменения хотя бы цены активной заявки. Эксперименты ставил на коротком скрипте, который больше ничего не делает, только ставит и пытается изменить заявку.

Что-то никак не удается мне победить эту команду.
Посмотрите пожалуйста.
Вот как у меня формируется транзакция:
sell_transaction = {  # Все значения должны передаваться в виде строк
'TRANS_ID': str(sell_order_id),  # Номер транзакции задается клиентом
'CLIENT_CODE': '62665',  # Код клиента. Для фьючерсов его нет
'ACCOUNT': 'L01-00000F00',  # Счет
'ACTION': 'NEW_ORDER',  # Тип заявки: Новая лимитная/рыночная заявка
'CLASSCODE': class_code,  # Код площадки
'SECCODE': symbol,  # Код тикера
'OPERATION': 'S',  # B = покупка, S = продажа
'PRICE': str(sell_order_lmtPrice),  # Цена исполнения. Для рыночных фьючерсных заявок наихудшая цена в зависимости от направления. Для остальных рыночных заявок цена = 0
'QUANTITY': str(int(order_size / lot_size)),  # Кол-во в лотах
'TYPE': 'L'}#,  # L = лимитная заявка (по умолчанию), M = рыночная заявка

Что тут необходимо передать, чтобы изменить заявку?
Я пробовал все из того, что вы писали выше, поля на русском, ничего не получается, мне возвращается моя строка.

Просто не нравится этот вариант, тк есть уникальный trans_id, зачем еще один индекс городить. Пока попробовал переделать все на обработку по trans_id, но остается открытым вопрос как быть если система не вернула order_num за разумное время. Пока что приходится такую заявку "забыть" и идти дальше.

это конечно вариант, но мне он не нравится отсутствием изящества, громоздкостью что ли. Кроме того, как справедливо раньше вы подметили, при работе с питоном приходится экономить операции.
На эту проблему накладывается возможное отсутствие trans_id в сообщениях, который я поддерживаю уникальным на своей стороне. Городить два индекса совсем не хотелось.
И что делать, если order_num не приходит? Ждать? Сколько? получается заявка в неопределенном статусе может находиться неопределенное время.

Уникальность номеров заявок order_num поддерживается только внутри одного торгового дня. Также как и trade_num для сделок.
Получается при использовании этих параметров в качестве индекса может возникнуть ситуация, что записи имеющиеся совпадут по индексу с новыми заявками и сделками дня, что может привести к труднопредсказуемым последствиям.
Использовать trans_id  в качестве уникального индекса тоже ненадежный способ, т.к. логика его передачи в сообщениях нестабильна. Также например случаются существенные задержки с поступлением OnTransReply и тогда невозможно отменить заявку, т.к. для этого необходим order_num, которого у нас еще может не быть.
Кто как решает эту проблему?

Спасибо, с учетом вашего ответа, стоит ли заморачиваться с реализацией или более надежно отменить старую и поставить новую заявку?

Здесь "Заявка" это order_num?
"Примечание"   "W1//ORDER_AMEND" это значимое поле с жестко заданным значением?
В поле цена "Цена"  в качестве десятичного разделителя точка?
Значение поля "К/П" в случае продажи "Продажа"?
Как себя ведет эта транзакция в случае если исходная заявка была частично исполнена до изменения?

Антон, пожалуйста, можете все-таки помочь разобраться, как отправить транзакцию на изменение заявки в английских терминах?

Сорри, не только по отмене, но и по исполнению тоже.
На самом деле, может прийти несколько сообщений, в некоторых будет 0, а в некоторых корректное значение.

Обратил внимание, что по отмене заявки приходит trans_id=0.
Это либо баг, либо недосмотр, т.к. нарушает логику сквозной нумерации. Почему 0?
Практически во всех остальных случаях trans_id приходит корректный.
Возможно это исправить?

да уже увидел тесты

Спасибо, очень познавательно.
У меня задача немного проще сейчас: адаптировать существующего робота для работы с Quik. В принципе не сказать, что медленно, цикл проверок на триггер занимает около 50-150мс (вместе со всеми транзакциями). Для моих задач этого пока достаточно. В вашей системе какое время обработки получается?

перебор тоже вариант  
Чаще всего отключение происходит ровно в 10:00:05. Не знаю, может какое-то технологическое переключение в начале сессии, которое триггерит выкидыш. Не думаю, что если бы дело было в core.dll оно бы так выглядело.

Спасибо, попробую  

Не очень понял, т.к. QuikPy это и делает. Он работает на питоне в связке с QuikSharp, который запущен в QUIK. Вот между ними связь и теряется периодически.  

Не могли бы вы еще привести такой же пример кода для английских наименований полей и их значений?
Например, у меня используется 'ACTION': 'NEW_ORDER', а тут как будет для изменения?

В качестве примера реализации могу привести IB API: https://interactivebrokers.github.io/tws-api/message_codes.html
То есть попросту удобно иметь исчерпывающий перечень сообщений об ошибках с кодами, их удобно обрабатывать. Тем более если необходимые поля в структуре данных имеются.

Такой error_code приходит, например:
{'error_code': 8635230, 'flags': 2359297, 'trans_id': 12345, 'quantity': 0.0, 'brokerref': '', 'order_num': 0, 'class_code': 'TQBR', 'uid': 214786, 'status': 5, 'client_code': '62665', 'result_msg': 'Вы не можете снять данную заявку', 'server_trans_id': 260, 'gate_reply_time': {'day': 1, 'sec': 0, 'hour': 0, 'min': 0, 'week_day': 1, 'ms': 0, 'mcs': 0, 'month': 1, 'year': 1601}, 'price': 0.0, 'date_time': {'day': 28, 'sec': 53, 'hour': 20, 'min': 16, 'week_day': 4, 'ms': 960, 'mcs': 960393, 'month': 12, 'year': 2023}, 'sec_code': 'SBER', 'balance': 0.0, 'exchange_code': '', 'time': 201653, 'first_ordernum': 0, 'error_source': 2, 'account': '', 'firm_id': 'MC0058900000'}

Я использую QuikPy для python, он коннектится к QuikSharp. Есть какие-то другие решения?

Да, именно так, от QuikSharp отваливается, при этом сервер подключен.

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

Случается так, что периодически отключается клиент от терминала Quik. Соединение с сервером при этом остается рабочим.
Подозреваю, что есть какие-то ограничения на количество передаваемых данных, после которого случается падение, тк явление наблюдается в периоды повышенной активности, например на открытии.
Кто-нибудь сталкивался? как это лечится?

Я постоянно вижу в сообщениях коды, например:
(210) Снято заявок: 1. Снято количество: 1. Нельзя снимать: 0.
(160) Заявка на покупку N 30534448 зарегистрирована.
ОШИБКА: (916) Заявка не может быть отменена. Указанная заявка уже не активна. Текущий статус заявки 'W'
также при разборе ответов:
8635230 Вы не можете снять данную заявку
и тп
Есть документация по всем кодам ошибок и структуре данных об ошибках?

Кто-нибудь пользуется QuikPy?
Подключение реализуется:
app = QuikPy()
В случае потери соединения на стороне Quik, он переходит в режим ожидания подключения клиента.
Как корректно восстановить соединение со стороны клиента?
При попытке пересоздания app=QuikPy() рушатся треды, т.к. не видят нового подключения.

Кто-нибудь знает какие существуют коды ошибок и формат данных сообщения об ошибке?

Помогло это решение?