Возникло желание привязывать сделки к ордерам из внешней системы через ID транзакции. Из документации на таблицу заявок: "Значение уникального номера заявки TRANS_ID при импорте заявок из файла" Из документации на таблицу сделок: "Значение уникального номера заявки TRANS_ID, породившей сделку"
Импортируем сделки по API - всё хорошо. Создаём сделку руками: 1. В таблице заявок TRANS_ID пуст 2. В таблице сделок TRANS_ID не пуст. Там используется какой-то другой счётчик.
Судя по всему, этот счётчик стартует с 10 и растёт на 1 для каждой новой транзакции, порождённой заявкой, сделанной в терминале вручную. По логике вещей, там тоже должно быть пусто, как и TRANS_ID заявки
Проблема-то даже хуже, чем я думал. Тестирую сейчас импорт рыночных заявок, общая задача привязать сделки к заявке. Экспорт данных по DDE. Итак, 1. Передаём TRANS2QUIK_SEND_SYNC_TRANSACTION строку ACCOUNT=L01+00000F00;SECCODE=MTLR;CLASSCODE=TQBR;ACTION=NEW_ORDER;TYPE=M;OPERATION=B;QUANTITY=1;PRICE=0;TRANS_ID=36; 2. Функция отвечает: orderId=36;result=0;resultCode=TRANS2QUIK_SUCCESS;status=3;statusMessage=транзакция выполнена;transactionId=0; 3. Транзакцию в системе, как мы видим, функция возвращать не желает. Ладно. 4. Терминал отправляет результат из таблицы сделок раньше, чем из таблицы заявок, т.е. нарушена причинно-следственная связь (я тестировал в однопоточном режиме, 4 раза - сделка оказывается раньше заявки). Таким образом, я даже не знаю, как тут быть. - TRANS_ID ненадёжен, ибо ненулевой для ручной заявки - Связь по ИД заявки невозможна, а) потому что ордер в момент обработки сделки ещё не пришёл.
Есть вариант всадить большой начальный TRANS_ID, чтобы с запасом и без шансов налепить вручную столько (счётчик ручных сделок стартует с 10), но непонятно почему этот счётчик для ручных вообще есть и что ему мешает тоже стать большим, после какого-нибудь изменения.
Добавьте что-то к полю CLIENT_CODE через слэш и поймаете это что-то в поле "комментарий" таблицы, таким образом отделите свои заявки от несвоих, а уж у своих TRANS_ID вы знаете.
Спасибо. Действительно что-то добавляется. Но пока думал, обнаружил проблему почему не возвращается ИД заявки. В документации неправильно указан тип - указан double*, но это не так, в реальности это указатель на int_64. Может, на С# пофиг что пихать, 8 байт и 8 байт, то на Яве это было не так. Думаю, это наилучшее решение проблемы.
Что на шарпе, что на сях даблы в IEEE754, так что тоже не пофиг. На возвращенное в бинарном виде не смотрели, там точно ноль или некий "битый дабл"? Вроде как у явы big endian, помнится, кто-то как-то попадал с необходимостью байты переворачивать, правда, не помню, в каком контексте.
Anton написал: Что на шарпе, что на сях даблы в IEEE754, так что тоже не пофиг. На возвращенное в бинарном виде не смотрели, там точно ноль или некий "битый дабл"? Вроде как у явы big endian, помнится, кто-то как-то попадал с необходимостью байты переворачивать, правда, не помню, в каком контексте.
Я получал "какие-то 8 байт" и кастил их в лонг, на выходе получался ноль, потому что внутреннее представление в Double было меньше 1. В общем, документацию не мешало бы поправить и так проблем хватает :)
Но использование TRANS_ID всё-равно удобнее, потому что его знаешь даже до отправки ордера. Когда всё асинхронное очень хочется иметь что-то постоянное. Транзакции для рыночного ордера действительно выгружаются быстрее чем сам ордер. А так можно вычитать обе DDE очереди, собрать по TRANS_ID и вернуть на клиента.
Здравствуйте! К сожалению, в текущей реализации для заявок, выставленных вручную, ID транзакции не проставляется. Параметр проставляется только для заявок, выставленных с явным указанием TRANS_ID, например, через API или *.tri файл. Можем зарегистрировать пожелание, чтобы параметр проставлялся и на заявках, выставленных вручную. Регистрируем?
Проблема немного иная: для ручных заявок ID транзакции не проставляется и это правильно, так как TRANS_ID заполняется внешней системой (согласно документации). Но для порождённых такой заявкой сделок, ID транзакции заполняется. Счётчик стартует с 10 в начале торговой сессии и растёт согласно числу сделок по "ручным" ордерам. Надо убрать TRANS_ID из сделок, если породивший их ордер не имеет TRANS_ID.
Ваше пожелание зарегистрировано. Мы постараемся рассмотреть его и сообщить Вам результаты анализа. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожелания в будущих версиях ПО.