MOVE_ORDERS

Андрей, добрый день!

1) Можете привести пример описанного поведения? Желательно с фрагментом кода

2) SECOND_ORDER_NUMBER = nil, но для второй заявки указана цена/количество, то sendTransaction вернет соответствующую ошибку

3) Нет, только один. Это одна транзакция, в которой переставляются две заявки.

И судя по описанию происходит именно 2 транзакции на бирже. Причем может и только одна из них сработтать.

Послушайте, мы тут делаем предложения по улучшению, а вы даете ответы в стиле "этого нет и такого функционала не предусмотрено". Я вам говорю, что он нужен и легко реализуем.
1) Признак направления заявки есть в самой заявке и он не меняется. Ничто не мешает для унификации его проставлять во flags так же, как для других транзакций. Чтобы в реплае понимать, реплай это на покупку или на продажу. Польза этого сомнений не вызывает, стоимость реализации низкая.
3) В описании про заявки, да.
Перестановка заявок на рынке FORTS выполняется по следующим правилам:

• Если MODE=0, то заявки с номерами, указанными после ключей
  FIRST_ORDER_NUMBER и SECOND_ORDER_NUMBER, снимаются. В торговую систему
  отправляются две новые заявки, при этом изменяется только цена заявок,
  количество остается прежним;
  
• Если MODE=1, то заявки с номерами, указанными после ключей
  FIRST_ORDER_NUMBER и SECOND_ORDER_NUMBER, снимаются. В торговую систему
  отправляются две новые заявки, при этом изменится как цена заявки, так и
  количество;
  
• Если MODE=2, то заявки с номерами, указанными после ключей
  FIRST_ORDER_NUMBER и SECOND_ORDER_NUMBER, снимаются. Если количество
  инструментов в каждой из снятых заявок совпадает со значениями, указанными после
  FIRST_ORDER_NEW_QUANTITY и SECOND_ORDER_NEW_QUANTITY, то в торговую систему
  отправляются две новые заявки с соответствующими параметрами.
  

Что же тогда считается успешной одной транзакцией, если успех принятия заявок может быть различным? И, как сказал, информативности в реплае максимум наполовину. OnOrder ему не замена, он может и не прийти. В такой ситуации механизм sendTransaction(MOVE_ORDERS) + onTransReply явно недоработан. Продумайте как полноценно доносить информацию в реплае. Мое предложение - отправлять 2 реплая, с еще одним битом во флаге с указанием на какую заявку из двух каждый. Обоснуйте, почему это не будет улучшением.

1) Нужно по реплаю однозначно понимать статус по обеим заявкам (по отдельности).
2) Добавьте тогда как минимум эти поля по второй заявке (если она есть): sec_code, price, quantity, order_num.
3) Желательно добавить сюда и направление заявок. Даже если этого нет в биржевом интерфейсе, там нет и многих других полей, которые есть в реплае. Вы обогощаете ими. Так включите сюда же и направление 0\1. Например битом, по аналогии как оно заполняется для обычных транзакций (см выше). Но теперь это нужно тоже по обеим заявкам в одном реплае. Поэтому может и отдельным полем сделать. И дублировать его как все вышеуказанные в п.2 для второй заявки, если она есть.

Это новость про либо обе, либо ни одна. Об этом хорошо бы написать в документации.
Насчет направления и "из таблицы заявок по данному номеру":
На момент onTransReply нет еще onOrder и записи в заявках. Но в onTransReply есть почти вся смысловая информация о новой заявке. Не хватает только направления и именно для MOVE_ORDERS. И тогда не нужно вести свою базу заявок, ожидающих подтверждения. Ради этого одного поля.

Еще вопрос. Чем обусловлено наличие MODE=0 и MODE=1? Неужели неизменность количества позволяет как-то по особому, заметно эффективнее и т.п. релизовать? Настолько, что даже выделили отдельный режим, а не в рамках частного случая с заданием кол-в MODE=1.

Не совсем так:


OnOrder сработает потом когда-нибудь, а информация по новой заявке нужна уже сейчас в OnTransReply.

Присоединяюсь.

Здравствуйте,
В MOVE_ORDERS появился mode=3? По крайней мере квик этот режим принимает и не выкидывает ошибку.
Он как в плазе работает?
Описание от туда:
Установить объемы заявок равными присланным за вычетом сведенной части заявки (не меньше 0). Если присланный объем
меньше сведенной части заявки, удаляются обе заявки.

Дополните документацию квика тогда, а то там нет такого режима.

Здравствуйте.
Мы рассмотрели Ваше пожелание. По итогам его анализа сообщаем Вам, что  реализация пожелания признана потенциально целесообразной. Если по  результатам дальнейшего анализа, включающего юридические аспекты, анализ  на непротиворечивость с общей политикой компании, никаких возражений не  возникнет, мы постараемся включить Ваше пожелание в план доработок при  выпуске одной из следующих версий нашего ПО.

Добрый день, Незнайка, Андрей.

Сообщаем, что ваши пожелания были реализованы в версии 10.0.0 терминала QUIK.

Ziveleos, добрый день.

Это был единственный случай, или подобное поведение воспроизводится регулярно?
Просим уточнить используемую версию Рабочего места QUIK, а также дату, когда наблюдалась данная ситуация.