MOVE_ORDERS

Страницы: 1
RSS
MOVE_ORDERS
 
Пробую такие транзакции на срочном рынке в MODE=1.

1) в OnTransReply перестал работать бит, определяющие куплю или продажу - (tr.flags>>17&1). В ответе на NEW_ORDER это работает. Просьба доработать. Уверен, при перестановке цены на данном этапе уже известно, купля это или продажа. Если нет, просьба не оставлять его незаполненным, а копировать из перемещаемого ордера. Считая по умолчанию, что ордер не меняет свою "ориентацию". По умолчанию это лучше, чем пустое поле.

2) Если SECOND_ORDER_NUMBER = nil , то, по хорошему, сервер должен игнорировать SECOND_ORDER_NEW_PRICE и SECOND_ORDER_NEW_QUANTITY, даже если они заполнены. Но есть подозрение, что они могут переопределять соответствующие FIRST в этом случае.. Прошу разъяснить.

3) Если заполнены все поля FIRST и SECOND, то должно прийти 2 OnTransReply? Это вообще просто способ сократить кол-во sendTransaction, а так эти поля совершенно независимы и аналогичны 2м sendTransaction (для MODE=1)?
 
А собственно ордер и не меняет ориентацию. Если цена перешагивает барьер, он просто исполняется по рынку. Так что направление в onTransReply однозначно определено.
 
Андрей, добрый день!

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

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

3) Нет, только один. Это одна транзакция, в которой переставляются две заявки.
 
Цитата
Roman Azarov написал:
Андрей, добрый день!

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

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

3) Нет, только один. Это  одна  транзакция, в которой переставляются две заявки.
1) Код здесь будет лишним. Просто делаю { ACTION = "MOVE_ORDERS", MODE = '1',.. }., Ордер переставляется. А в колбеке flag имеет не праильный признак направления (покупка\продажа). За это отвечет вот такой бит (tr.flags>>17&1) у вас.Он не корректен для MOVE_ORDERS.

3) Очень странные вещи вы говорите. А как же тогда интерпретировать все поля OnTransReply(TABLE trans_reply) ? Они расчитаны на передачу данных по одному ордеру данной транзакции. Например order_num.
 
И судя по описанию происходит именно 2 транзакции на бирже. Причем может и только одна из них сработтать.
 
Андрей,

1) Прошу прощения, в прошлый раз немного поторопился с ответом. На данной транзакции (MOVE_ORDERS) в принципе нет признака направления. Соответственно, во флагах Вы его и не увидите.

3)
Цитата
Андрей написал:
И судя по описанию происходит именно 2 транзакции на бирже
Не совсем понимаем, о каком описании идет речь? Это одна транзакция вида MOVE_ORDERS, соответственно, ответ по ней так же будет один.
В данном случае рекомендуем получать номер и прочие поля, относящиеся к заявке из OnOrder().
 
Цитата
Roman Azarov написал:
Андрей,

1) Прошу прощения, в прошлый раз немного поторопился с ответом. На данной транзакции (MOVE_ORDERS) в принципе нет признака направления. Соответственно, во флагах Вы его и не увидите.

3)  
Цитата
Андрей написал:
И судя по описанию происходит именно 2 транзакции на бирже
Не совсем понимаем, о каком описании идет речь? Это одна транзакция вида MOVE_ORDERS, соответственно, ответ по ней так же будет один.
В данном случае рекомендуем получать номер и прочие поля, относящиеся к заявке из OnOrder().
Послушайте, мы тут делаем предложения по улучшению, а вы даете ответы в стиле "этого нет и такого функционала не предусмотрено". Я вам говорю, что он нужен и легко реализуем.
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) Признак направления заявки есть в самой заявке и он не меняется. Ничто не мешает для унификации его проставлять во flags так же, как для других транзакций. Чтобы в реплае понимать, реплай это на покупку или на продажу. Польза этого сомнений не вызывает, стоимость реализации низкая.
Речь идет про транзакцию, а не про заявку.
Повторимся, на биржевой транзакции MOVE_ORDERS нет поля "Направление". Направление не уходит в транзакции и не возвращается биржей.

Цитата
Андрей написал:
В торговую систему отправляются две новые заявки
Транзакции и заявки это две совершенно разные вещи. В данном случае, транзакция одна, а заявки две, все верно.

Цитата
Андрей написал:
Что же тогда считается успешной одной транзакцией, если успех принятия заявок может быть различным?
Если указан номер одной заявки и эта заявка была успешно заменена, либо, если указаны номера двух заявок и обе заявки были успешно заменены. В иных случаях будет ошибка.

Цитата
Андрей написал:
Мое предложение - отправлять 2 реплая, с еще одним битом во флаге с указанием на какую заявку из двух каждый. Обоснуйте, почему это не будет улучшением.
Реплай отправляется биржей по достаточно понятной логике - 1 транзакция = 1 реплай.
Подробнее можно ознакомиться в документации к биржевому интерфейсу - http://ftp.moex.com/pub/ClientsAPI/Spectra/CGate/prod/docs/p2gate_ru.pdf

Можем предложить зарегистрировать пожелание на возможность получения в OnTransReply номеров обеих заявок. Такой возможности на данный момент действительно нет.
 
Цитата
Roman Azarov написал:

Если указан номер одной заявки и эта заявка была успешно заменена, либо, если указаны номера двух заявок и  обе  заявки были успешно заменены. В иных случаях будет ошибка.

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

1) Обе заявки успешно изменены, либо не изменена ни одна, либо ошибка. Это уже можно понять по реплаю.

2) sec_code не может отличаться у двух данных заявок. Регистрируем пожелание на возможность получения price, quantity и order_num второй заявки?

3) Мы не добавляем в транзакцию поля, которые отсутствуют в биржевом интерфейсе. Так как для данной транзакции в принципе отсутствует направление, добавить его в реплай возможности нет.
Сама задача в принципе не ясна. Данной транзакцией нельзя изменить направление заявки. Зачем необходимо его получать в onTransReply?

На данный момент, рекомендуем получать номер второй заявки из поля result_msg.
Всю прочую информацию же можно получить из таблицы заявок по данному номеру.
 
Цитата
Roman Azarov написал:
Андрей, здравствуйте!

1) Обе заявки успешно изменены, либо не изменена ни одна, либо ошибка. Это уже можно понять по реплаю.

2) sec_code не может отличаться у двух данных заявок. Регистрируем пожелание на возможность получения price, quantity и order_num второй заявки?

3) Мы не добавляем в транзакцию поля, которые отсутствуют в биржевом интерфейсе. Так как для данной транзакции в принципе отсутствует направление, добавить его в реплай возможности нет.
Сама задача в принципе не ясна. Данной транзакцией нельзя изменить направление заявки. Зачем необходимо его получать в onTransReply?

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

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

Цитата
Андрей написал:
Это новость про либо обе, либо ни одна. Об этом хорошо бы написать в документации.
Это уже указано в документации к биржевому протоколу.
Так как результат возвращает биржа и, соответственно, он в любой момент может поменяться, мы не считаем правильным фиксировать его в нашей документации.

Цитата
Андрей написал:
На момент onTransReply нет еще onOrder и записи в заявках
Если в OnTransReply вернулся номер заявки(ок), это значит, что новая заявка была зарегистрирована, что приведет к срабатыванию OnOrder и появлению соответствующей записи в таблице заявок.
Зарегистрировали пожелание на добавление полей price, quantity и order_num для второй заявки. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожелания в будущих версиях ПО.
Касательно направления на данной транзакции, с данным пожеланием рекомендуем обратиться на биржу.


Цитата
Андрей написал:
Еще вопрос. Чем обусловлено наличие MODE=0 и MODE=1? Неужели неизменность количества позволяет как-то по особому, заметно эффективнее и т.п. релизовать? Настолько, что даже выделили отдельный режим, а не в рамках частного случая с заданием кол-в MODE=1.
Данный вопрос также следует адресовать специалистам биржи.
 
Цитата
Roman Azarov написал:
Обе заявки успешно изменены, либо не изменена ни одна, либо ошибка. Это уже можно понять по реплаю.

Не совсем так:
Цитата
Если при сдвиге пары заявок одна из них наткнулась на кросс-сделку (сведение с заявкой от того же ИНН, либо клиентского регистра), она откатывается, а другая заявка сдвигается.


Цитата
Roman Azarov написал:
Цитата
Андрей написал:
На момент onTransReply нет еще onOrder и записи в заявках
Если в OnTransReply вернулся номер заявки(ок), это значит, что новая заявка была зарегистрирована, что приведет к срабатыванию OnOrder и появлению соответствующей записи в таблице заявок.
OnOrder сработает потом когда-нибудь, а информация по новой заявке нужна уже сейчас в OnTransReply.

Цитата
Roman Azarov написал:
Зарегистрировали пожелание на добавление полей price, quantity и order_num для второй заявки.
Присоединяюсь.
 
Незнайка, добрый день!

Цитата
Незнайка написал:
Не совсем так:
Цитата - Если при сдвиге пары заявок одна из них наткнулась на кросс-сделку (сведение с заявкой от того же ИНН, либо клиентского регистра), она откатывается, а другая заявка сдвигается.
Да, действительно. Большое спасибо, что поправили.

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

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

Ваше письмо получено, проблема изучается. Постараемся в ближайшее время дать ответ.
 
Здравствуйте.
Цитата
Roman Azarov написал:
Андрей,

Цитата
Андрей написал:
Это новость про либо обе, либо ни одна. Об этом хорошо бы написать в документации.
Это уже указано в документации к биржевому протоколу.
Так как результат возвращает биржа и, соответственно, он в любой момент может поменяться, мы не считаем правильным фиксировать его в нашей документации.

Цитата
Андрей написал:
На момент onTransReply нет еще onOrder и записи в заявках
Если в OnTransReply вернулся номер заявки(ок), это значит, что новая заявка была зарегистрирована, что приведет к срабатыванию OnOrder и появлению соответствующей записи в таблице заявок.
Зарегистрировали пожелание на добавление полей price, quantity и order_num для второй заявки. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожелания в будущих версиях ПО.
Касательно направления на данной транзакции, с данным пожеланием рекомендуем обратиться на биржу.


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

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

Цитата
Незнайка написал:
Не совсем так:
Цитата - Если при сдвиге пары заявок одна из них наткнулась на кросс-сделку (сведение с заявкой от того же ИНН, либо клиентского регистра), она откатывается, а другая заявка сдвигается.
Да, действительно. Большое спасибо, что поправили.

Цитата
Незнайка написал:
Присоединяюсь.
Зарегистрировали аналогичное пожелание и от Вас.

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

Сообщаем, что ваши пожелания были реализованы в версии 10.0.0 терминала QUIK.
Страницы: 1
Читают тему
Наверх