Юрий Балашов (Все сообщения пользователя)

А почему?!
Планируется ли введение этой операции в следующих версиях, если нет, то возможно ли это зарегистрировать как пожелание?

Спасибо, я понял, буду пробовать. Правда скриншоты не отразились, попробуйте вставить их еще раз.Отдельное спасибо, я не знал.

Правильно ли я понимаю, что начиная с версии Квик 9,2 можно передавить 19-тизначный номер заявки по ODBC в FB или Вы имеете ввиду что-то другое?
И большая просьба, нельзя ли инициатору темы на е-мэйл отправлять сообщение о появлении ответа на его вопрос на форуме? Дело в том, что ошибку Вы исправили только через год и согласитесь, вряд ли кто будет так долго следить за темой. Я, например, обнаружил этот ответ случайно.

При попытке передвинуть заявку спреда между фьючерсами с помощью .tri-файла заявка не передвигается с сообщением: "Указанная транзакция по указанному классу не найдена: "FUTSPREAD"." Выставление и снятие заявки проходит нормально. По классу SPBFUT мув-ордер работает нормально. Что, по этому классу не предусмотрено передвижение заявок или это недоработка?
Брокер КИТ-финанс, Квик 8.5.2.11, Windows 7х64.

Спасибо.

Ели транзакция прошла успешно, то номер снимаемого ордера мне не нужен.
Ели транзакция не прошла, то безусловно, я могу восстановить номер снимаемого ордера, но только в том случае, если я его сохранил. Т.е. я должен вначале сохранить параметры этой заявки, потом, если снятие этого ордера не произошло, по ID провести поиск этого номера и только затем повторить снятие этого ордера или убедиться, что он исполнен. Зачем эти "танцы с бубном"?  Насколько проще бы было если можно вытащить номер СНИМАЕМОЙ заявки из колбэка и прямо по нему произвести необходимые действия.
Поэтому и был вопрос - возможно ли это?
Ответ хотелось бы получить в форме:
Нет, не возможно или Да, возможно, вот таким образом.
Странно, почему молчит техподдержка?

Николай мне ответил неправильно:(.
Внимательно прочтите пой предыдущий пост.
Еще раз повторю - мне не нужен ID отправляемой заявки, как вы правильно отметили, я его знаю и в колбэке он естественно приходит. Мне нужен номер заявки или ID той транзакции которую он должен снять. Этот номер заявки (которую необходимо снять) я отправляю в Килл ордере, но вот в колбэке, если снятие заявки по какой-то причине не произошло, я его выловить не могу.
Ребята, без обид, кто не очень въехал о чем речь, не надо отвечать.
По прежнему жду ответа от ТЕХПОДДЕРЖКИ возможно ли это в принципе или нет?

Николай, Вы немного не понимаете о чем идет речь, по-видимому Вы никогда не сталкивались с подобной ситуацией. Нет задачи перехватить ответ для ОТПРАВЛЕННОЙ Килл/Мув транзакции, ее ID и так известен, задача в том, чтобы узнать номер транзакции (или ID) того ордера который она снимает/передвигает, если вдруг заявка Килл/Мув неудачна, что бывает достаточно часто, особенно последнее время.

Прошу ТЕХПОДДЕРЖКУ ответить на поставленный вопрос.

Затем, что заявок на снятие и передвижение может быть несколько и если одна из них прошла с ошибкой, надо знать какая, чтобы скорректировать поведение робота. ID заявки на снятие/передвижение есть, а вот номер ордера СНИМАЕМОЙ заявки я получить не могу.Если это теоретически возможно, то я не понимаю как? Хотя действительно номер снимаемой заявки передавался в Килл/Мув ордере.  

Собственно весь вопрос в заголовке: возможно ли в OnTransReply получение номера снимаемой/передвигаемой заявки при использовании Kill/Move order по ID этого ордера?

Иван, как Вы состыковали свою программу с Trans2QuikAPI_1.3_x64 ?
Вам удалось написать Quik.pas или Вы используете не Delphi?

Вы наверное описались, когда пишите, что "передать параметр номера заявки в виде ЧИСЛА нельзя" и имели ввиду что в виде СТРОКИ нельзя?
Не могли бы Вы дать ссылку как создать таблицу при помощи QPILE.
Это секретные данные???
MSSQL слишком специфичная база, не могли бы Вы сказать будет ли работать на базе Oracle 8?

Вы можете сказать, на каких КОНКРЕТНО базах данных, желательно с версией базы, такая передача данных проверялась.

В соседнем обсуждении Вы пишите, что номер заявки передается как строковый, я попробовал, но Квик (версия 8.5) не дает возможности передать в базу данных строку "Номер" заявки как строковую переменную, только как числовую.

Версия конечно существует, но к ней нет образца Quik.pas на Delphi, который был у версии 1.2, а так как они принципиально отличаются мне, например, не удается его написать.
Кстати просьба ко всем форумчанам, если кому-то удалось это сделать, не могли бы Вы поделиться, я был бы очень признателен.

Вдогонку, можно ли передать номер заявки как строковый?

Да, проблема действительно в FB, Квик передает данные, но усеченные, не все 19 цифр. Поэтому и был вопрос, на какой базе данных тестировали передачу данных по ODBC?
На какой тип данных изменить, в самой базе у меня стоит DOUBLE PRECISION?

Сегодня, при переходе на 19-тизначный номер заявки произошел сбой передачи данных по ODBC и соответственно робот встал :(. База на FB сервере, система Win7, Квик 8.5.2.11, Брокер - Кит_Финанс. Насколько я понимаю причина в том, что FB не поддерживает 19 знаков. На какую базу можно перейти? Надеюсь разработчики не отказались полностью от передачи данных по ODBC и тестировали ее хоть на какой-то базе?

Кстати, теперь номер заявки идет не по порядку выставления заявки, а по какому-то другому принципу. Например заявки по SiU0 имеет меньший номер чем GDU0, даже если она была выставлена намного позже. Так и было задумано или это какой-то сбой? И как теперь упорядочить таблицу заявок?

В версии Квик 8.3 эти ошибки исчезли.
Выходит я был прав, 8.2 была не полностью рабочей и на тот момент полностью рабочих версий не было :(((.

Добрый день.
По Вашему требованию я перешел на Windows7(х64) и Квик 8.2.1.13. Однако в этой связке также ошибки на позволяющие работать. При передаче данных по ODBC из "Таблицы заявок":
1. В базу данных не передается ID_транзакции (причем сбой весьма странный, как правило передается значение "null" и лишь иногда передается правильное значение).
2. Параметр "Состояние" передается правильно только в первый раз, а именно состояние "Активна", при снятии заявки или ее исполнении, в базу данных по прежнему передается состояние "Активна". Если же прекратить передачу данных и снова возобновить ее при активном пункте "Чистить таблицу перед выводом" изменившиеся ранее данные передаются правильно, но во вновь выставленных заявках состояние по прежнему всегда  "Активна" вне зависимости от произошедших изменений. Такое ощущение, что передается только первое поступившее значение, дальнейшие изменения уже не передаются.
Остальные, используемые мной параметры передаются правильно.
Файл  quik_odbc.log в этом случае заполняется, причем чрезвычайно быстро (за несколько дней до 11Гбт).
По-видимому Вам требуется архив рабочего места QUIK и quik_odbc.log? Скажите, как их передать?  

Т.е. как? Получается, что на данный момент не существует полноценно работающей версии Квик? Версия 7 не передает данные по ODBC и Вы не собираетесь ничего исправлять, а версия 8.2, как сказал мне брокер, не является рабочей и распространяется только в тестовом режиме.
И какие доработки? Просто укажите тип данных для поля "Номер" из "Таблицы заявок", ведь Win32 позволяет передать 15-ти значное целое число, в чем проблема?

Нет, я пробовал с Квиком версии 7.25.1.3.
А что относительно существующей проблемы на Win32? Есть какие-либо сдвиги в ее решении?

Уважаемые разработчики!
Пугает отсутствие реакции на мои последние сообщения. Ответьте хотя бы, что Вы их видели, занимаетесь ли вопросом и когда приблизительно можно ожидать разрешение проблемы?
Поймите меня правильно, у меня работа ПОЛНОСТЬЮ стала!
Может быть нужна какая-либо помощь с моей стороны?

При попытке логирования, создании файла quik_odbc.log и последующем воспроизведении проблемы он также, как и на WIN32 остается пустым.

Несмотря на отсутствие возможности мне удалось проверить на 64 разрядном Windows.
Ситуация с передачей данных по ODBC усугубилась: не только не передаются данные из таблицы заявок (напомню в базе все поля передающиеся из этой таблицы равны null), но и перестала передаваться часть данных из "Текущей таблицы параметров", а именно, поля соответствующие параметрам "Спрос", "Предл.", "Цена послед." также стали равны null.

Какая версия не будет работать в Win32 моя 7.25.1 или 8.2.1?
Если Вы говорите, что в версии 8.2.1 была исправлена похожая проблема, то почему бы ее не исправить в версии которая всеми используется сейчас - 7.25? Т.е. проблема все-таки есть и не думаю, что я один использую протоколы ODBC и DDE. К тому же я не очень понимаю в чем принципиальная сложность, ведь в Win32 при типе данных DOUBLE PRECISION спокойно передается 15 цифр?
В будущем я планировал постепенно переходить на 64 разрядную систему, но в данный момент это практически невозможно. К тому же я вовсе не уверен, что без частично переделки программы она будет работать на Win64, а это время, и немалое, а работать мне надо СЕЙЧАС! И согласитесь, не очень прилично, без предварительного предупреждения, менять что-то, что приведет к остановке работы Ваших клиентов?
С моей стороны, я готов на любую помощь в устранении этой ошибки, при необходимости могу прислать архив программы или саму базу, провести любое логирование.

Добрый день!
Не все моменты Вашего ответа понятны:
1. Что значит архив пустой? Все таблицы пустые? Такое вообще возможно? Или он не полностью прошел? По совету брокера я перед архивацией архива удалил папки archive, backup, Doc, м.б. дело в этом? Давайте я снова перешлю Вам архив, только укажите почту куда отправлять.
2. Не понятен смысл фразы "Сообщите какой именно номер экспортируется (посмотрите в QUIK)", что имеется ввиду, где в Квике смотреть и какой номер (брокер в этом вопросе тоже помочь не смог)??? Если имеется ввиду столбец "Номер" из таблицы заявок, то структуру базы привожу ниже.
3. Структура базы данных для таблицы заявок:
Столбец таблицы Квик (Список параметров)                                             Поле, соответствующее параметру
1. Номер *                                                                                                ORDERKEY (DOUBLE PRECISION)
2. Операция                                                                                             OPER (VARCHAR(10))
3. Цена                                                                                                    P (DOUBLE PRECISION)
4. Количество                                                                                           V (INTEGER)
5. Остаток                                                                                                OST (INTEGER)
6. Состояние                                                                                            SOSTO (VARCHAR(15))
7. Код инструмента                                                                                  KB (VARCHAR(12))
8. ID транзакции                                                                                       TRANS_ID (INTEGER)
9. Код класса *                                                                                        KODK (VARCHAR(10))


Кроме того если в базу данных в поле соответствующее полю "Номер" из "Таблицы заявок" вручную ввести 14 цифр, то они прекрасно сохраняются там, однако Квик их по каким-то причинам передать не может.

Архив отправил.
Добавлю, что удалось выяснить мне:
1. Сбой идет при передаче данных по ODBC из "Таблицы заявок" (ошибка в Квике появляется при запуске вывода из этой таблицы)
2. Сбой связан со столбцами либо "Номер", либо "Код класса" (оба параметра обязательны), т.к. я в базе пробовал убирать остальные параметры, но ошибка не исчезает.
3. Наиболее вероятно, что ошибка связана со столбцом "Номер", т.к. его длина поменялась 13.12.2019, а "Код класса" не менялся.
4. По документации параметр "Номер" д.б. "DOUBLE PRECISION" (как стоит у меня), в порядке эксперимента я пробовал менять его на  NUMERIC, Size 15, Scale 1, и DECIMAL 15, 1 - не помогает.
Все вышесказанное только мое мнение и написано только для дополнения информации. Ошибка м.б. в чем-то совершенно другом.
Еще раз напомню База на FB сервере, система WinXP32.

Перепроверил, файл называется quik_odbc.log

Да, забыл уточнить, заявок по режиму GCTR нет.

Спасибо за быстрый ответ.
Логирование провел.
Однако, после запуска Квика и воспроизведения проблемы файл quik_odbc.log остается пустым, хотя во время работы Квика он недоступен. Чтобы устранить возможные ошибки с моей стороны опишу как проводил логирование: выключил Квик, в папке где расположен файл info.exe создал текстовый документ, который переименовал в quik_odbc.log, запустил Квик, при его  запуске автоматически запустилась передача данных по ODBC, в Квике по прежнему выскочила ошибка (Dynamic SQL Error SQL error code =-104 Token unknown - line1 column 862) в количестве, равном количеству строк в "Таблице заявок". Выставил заявки, в Квике появились еще строки с указанной ошибкой. Остановил Квик. Пустой лог-файл выслал через брокера (т.к. пустой лог-файл не отправлялся пришлось его заархивировать).

После изменений на бирже от 13.12.2019 данные из "Талицы Заявок", не передаются по ODBC, по-видимому изменился тип данных одного из столбцов. Если это так, прошу уточнить какого (или каких)?  Если причина другая, поясните, что надо исправить? База на FB сервере, система WinXP32, Квик 7.25.1.3, Брокер - Кит_Финанс.

Возвращаясь к проблеме ORDERKEY (ordernum) равен 0. Кто-нибудь сможет объяснить ответ на транзакцию, который прислала биржа:
"ORDERKEY = 0; Message = (210) Снято заявок: 1. Снято количество: 40. Нельзя снимать: 0."
С одной стороны пишет, что заявка снята и снято все количество, а с другой стороны - "Нельзя снимать: 0" - как это понимать?

Спасибо!
1. Как проверить причину по которой биржа сняла заявку?
2. Всегда ли когда ORDERKEY (ordernum) оказался равен 0 заявка не выставляется (или соответственно не передвигается, не убивается - в зависимости от вида заявки move, kill )? Или возможны варианты, что она все-таки выставилась, передвинулась, убилась?

Это единичный сбой, до этого подобных ошибок не было, но тем не менее, раз случилось, то может повториться:
При синхронной отправке транзакции на продажу акций пришло сообщение об успешном ее исполнении, а также ее TRANS_ID, но ORDERKEY (ordernum) оказался равен 0. Количество акций необходимых для продажи присутствует.
Вопросы:
1. Как такое возможно?
2. Что делать, чтобы такое не повторялось?
3. Как контролировать такую ошибку?

Сейчас ACTION = MOVE_ORDERS на рынке акции ММВБ не работает.
1. Существует ли веская причина этого?
2. Планируется ли ввести передвижение заявок для акций, с целью снижения нагрузки на сервера биржи?
3. Если этот вопрос не поднимался, прошу зарегистрировать его как пожелание.

Sergey Gorokhov,
Мне казалось, что код TQBR правильный, а EQRP_INFO это что-то не то, просто потому, что так написано в таблице и на сайте биржи.
Но, допустим EQRP_INFO тоже правильный код, тогда почему при следующем запросе:для фьючерса значение спроса и его объема выдаются, а для акций нет?

Что, никто не может ответить???
Звонил брокеру - сказали вопросы к разработчикам.
Мне самому кажется подобная ситуация невероятной, ведь в таблице class_code отражается верно. Но ведь против фактов не попрешь, или у Вас не воспроизводится данный результат?

При запросе из скрипта QLua "Код класса" из "Текущей таблицы параметров" для фьючерсов код выдается правильный - "SPBFUT", а для акций - нет: вместо TQBR выдается код EQRP_INFO. Хотя в самой таблице он отображается правильно. Естественно, что при попытке использовать полученный class_code в функции OnParam(classs,sec) нужные данные не получаются. Что нужно сделать для исправления?
Код запроса:
Квик - 7.7.0.89, Брокер - КитФинанс, Винда - ХР.

Спасибо!

При обращении к Квику, даже если в этот момент Квик не обновляет данные и не производит никаких вычислений, происходит потеря 16 млсек. Поясню на примере. Если выполнить следующий простенький скрипт, написанный на Lua:

IsRun = true
    local time = os.clock()
    for i = 0, 20 do
       message(string.format('Цикл № %0.0f ,Время %0.3f сек',i, os.clock()-time), 1)
    end
function main()
   while IsRun do
   sleep(1000)
   end
end
function OnStop()
  IsRun = false
end

то увидим следующий результат:
Дата    Время    Сообщение
15.02.2017    13:24:11    Цикл № 0 ,Время 0.000 сек
15.02.2017    13:24:11    Цикл № 1 ,Время 0.016 сек
15.02.2017    13:24:11    Цикл № 2 ,Время 0.016 сек
15.02.2017    13:24:11    Цикл № 3 ,Время 0.032 сек
15.02.2017    13:24:11    Цикл № 4 ,Время 0.032 сек
15.02.2017    13:24:11    Цикл № 5 ,Время 0.032 сек
15.02.2017    13:24:11    Цикл № 6 ,Время 0.032 сек
15.02.2017    13:24:11    Цикл № 7 ,Время 0.047 сек
15.02.2017    13:24:11    Цикл № 8 ,Время 0.047 сек
15.02.2017    13:24:11    Цикл № 9 ,Время 0.063 сек
15.02.2017    13:24:11    Цикл № 10 ,Время 0.063 сек
15.02.2017    13:24:11    Цикл № 11 ,Время 0.079 сек
15.02.2017    13:24:11    Цикл № 12 ,Время 0.079 сек
15.02.2017    13:24:11    Цикл № 13 ,Время 0.079 сек
15.02.2017    13:24:11    Цикл № 14 ,Время 0.079 сек
15.02.2017    13:24:11    Цикл № 15 ,Время 0.094 сек
15.02.2017    13:24:11    Цикл № 16 ,Время 0.094 сек
15.02.2017    13:24:11    Цикл № 17 ,Время 0.094 сек
15.02.2017    13:24:11    Цикл № 18 ,Время 0.110 сек
15.02.2017    13:24:11    Цикл № 19 ,Время 0.110 сек
15.02.2017    13:24:11    Цикл № 20 ,Время 0.110 сек
Из которого видно, что в среднем, за каждые 3-3.5 обработки в Lua теряются 16 млсек (иногда 15 млсек). При этом никаких вычислений у нас не происходит и Квик может даже не получать никаких данных (я проверял и в выходные - результат тот же). Аналогичное время теряется и при выводе через ODBC, думаю, что при выводе данных через DDE будет то же самое ( не проверял). Отсюда логично сделать вывод о том, что это какие-то потери Квика.
При исполнении данного примера, но, если вывод происходит внутри function main(), потери 16 млсек тоже наблюдаются, но существенно реже.
Хотелось бы понять из-за чего это происходит? Можно ли каким-то образом уменьшить это время потерь или хотя бы частоту их появления?
Допускаю, что что-то можно изменить в настройках Квика или его загрузке, тогда подскажите что? "Вывод по ODBC", "Экспорт в системы тех.анализа" и "Внешние транзакции" никак не влияют.
Возможно, что потеря именно данного времени (16 млсек) может быть как-то связана с характеристиками машины и операционной системы ( у меня Win XP, Квик 7.7.0.89), поэтому, кто сможет, проверьте на своих машинах и выложите сюда результат, было бы интересно сравнить.

Все проще, я могу брать одни и те же данные из разных таблиц. Хотелось бы знать из каких предпочтительнее., т.е. никакого желания схалтурить нет:). А на счет "все приезжает в случайном порядке" Вы не правы, я сам, правда давно, больше 3 лет назад, наблюдал, как в некоторые таблицы информация приходила с запазданием. Вот и хотелось услышать от создателей, что к чему, т.к. брокер полностью прояснить данный вопрос не смог.

Для оптимизации работы робота хотелось бы узнать в какой очередности данные поступают в различные таблицы Квика и насколько (в % или млсек) отличается скорость постановки этих данных?
Интересуют следующие таблицы:
"стакан"
Таблица заявок
Текущая таблица параметров
Позиции по клиентским счетам
Таблица лимитов по бумагам
Таблица транзакций
Таблица лимитов по денежным средствам
Ограничения по клиентским счетам

В свободном доступе я этой информации не нашел.
С уважением

Да, похоже Вы правы, поэтому прихожу к заключению,что придется писать скрипт на Lua по передачи данных через DLL в Delphi.
Если кто-нибудь знает, подскажите примеры таких DLL, никогда не поверю, что их никто не писал.

Хочу написать робота-арбитражера для парного трейдинга с акциями и фьючерсами, главные требования:
1. Скорость работы – максимально быстрая скорость постановки, снятия и перестановки заявки при изменении цены в стакане – желательно не более 0.1сек.
2. Отсутствие торможения – отсутствие замедления и сбоев в работе при выставлении заявок по 15-20 парам инструментов, при отслеживании до 40-60 пар (отслеживание возможно не в режиме реального времени, а периодически – 1раз в 1-5 минут).
Не нужно: никаких графиков, индикаторов, проверки на истории, возможностей постановки заявок вручную.
Собственно такой робот у меня есть (написан мной на Delphi), но он работает через передачу по ODBC в базу данных и затем чтения из нее, что замедляет постановку заявки более чем на 1.5 секи и при работе более чем с 8-10 парами начинаются сбои в постановке/снятии заявок.
Вопрос: возможно ли написание подобного робота, отвечающего указанным выше требованиям на, Lua или Lua + внешняя программа (С#, Delphi)?
Поскольку Lua не знаю совершенно, не хотелось бы оказаться в положении человека изучившего Lua, написавшего на нем робота и вдруг выяснившего, что скорость постановки заявки будет медленная и работать можно будет только с 2-3 парами инструментов :).

Все запрошенные файлы отправил

Уважаемый Stanislav!
Спасибо, что откликнулись, т.к. Ваш коллега из техподдержки, который отвечал мне на почту, просто вежливо "послал" меня, не пожелав даже вникнуть в суть вопроса. Хотелось бы, что бы в дальнейшем рассмотрением проблемы занимался не он.
Отправил на саппорт оба запрашиваемых Вами файла, созданных таким образом, чтобы можно было проще разобраться в теме: в МетаСток передаются только 2 инструмента VolSi - волатильность опциона на фьючерс доллара SiZ5, который передается с ошибкой и VolBr - волатильность опциона на фьючерс нефти BRZ5, который передается без ошибки.
В строчках файла quik_metastock.log я различий не нашел, но я и не специалист в этой области. Однако в файле __iwr.log четко видны различия, так  VolBr передается со знаками после запятой, а VolSi  без знаков после запятой, т.е. с ошибкой:
[2015-11-20 10:02:34.218] EXE: Sending quote to client: (2015-11-20 10:00:00 1 VOLSI 19
[2015-11-20 10:02:34.218] EXE: Sending quote to client: (2015-11-20 10:00:00 1 VOLBR 43.08

Надеюсь эта информация поможет Вам разобраться с ошибкой передачи данных в МетаСток.

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

"Позволим себе усомниться в Ваших выводах, т.к. в quik_metastock.log данные пишутся уже на выходе из QUIK, и в дальнейшем никак нашим софтом не трансформируются. То есть в данном файле данные находятся уже в том виде, в котором их будет принимать Метасток. По какой причине он округляет эти данные - для нас непонятно. Мы рекомендуем Вам обратиться в поддержку Метасток и после обнаружения причины проблемы, если Вам не сложно, сообщить её решение нам."

Вы зря сомневаетесь в моих выводах, поскольку  МетаСток ничего не знает из какого источника мы присылаем ему данные, файл в который мы отправляем эти данные мы специально не меняем, меняя только источник данных в Квике. Значит данные передаваемые правильно и передаваемые неправильно чем-то отличаются (не смотря на то, что в quik_metastock.log конкретные цифры волатильности отражаются со знаками после запятой), иначе МетаСток их просто не смог бы отличить.
Очень прошу Вас воспроизвести описанную ранее процедуру вывода данных в МетаСток на своих компьютерах и, если Вас не затруднит, сообщить мне результат.
Обратиться в поддержку МетаСтока я к сожалению не могу, т.к. последняя известная мне служба поддержки перестала работать. Если у Вас есть такая возможность, я был бы Вам очень признателен, если бы Вы обратились к ним, думаю Вам это намного проще, чем мне. Хотя я по прежнему уверен: проблема в том, что в МетаСток из Квика передаются несколько разные данные (возможно по формату, возможно по каким либо другим параметрам).

Ошибка при выводе волатильности возникает не для всех опционов, например для BR, ED ее нет, а для Si, RI, LK, GZ она наблюдается и связана она абсолютно точно с Квиком. Это очевидно если провести следующие действия:
1. Создать в DownLoader МетаСтока новое Security с любым Именем.
2. В Экспорте Данных Квика добавить новую Бумагу - например Опционы FORTS - BRZ5 - выбрать любой опцион - В "Обозначение в системе ТА" ввести выбранное Имя из созданного Секьюрити Метастока -  выбрать "Таблица истории значений параметров" - Волатильность опциона.
3. Начать вывод по бумаге.
4. Подождать несколько минут, убедившись, что волатильность в МетаСток выводится без ошибки (т.е. без округления)
5. Затем в  Квике "Прекратить вывод по бумаге" - нажать кнопку "Изменить"
6. Заменить опцион BRZ5 на опцион SiZ5 не меняя "Обозначение в системе ТА" - т.е. выводить данные в тоже самое Секьюрити МетаСтока.
7. Начать вывод по бумаге
8. Подождать несколько минут и убедиться, что Волатильность в МетаСток выводится с ошибкой (т.е. с округлением).
Очевидно, что Секьюрити МетаСтока осталось прежним, т.к. мы его вообще не трогали, а меняли только Инструменты в Квике, тем не менее ошибка появляется.

Я выслал Вам скриншот отражающий результат описанных выше действий. Уверен, вы Сами можете воспроизвести это на своем компьютере с тем же результатом.

Я не проверял все опционы на предмет данной ошибки и не знаю полный список ошибочных, но наиболее популярные и ликвидные выводятся с ошибкой - их я указал (Si, RI, LK, GZ).

Как Вы просили, я создавал  текстовый файл quik_metastock.log, в него все данные выводятся без ошибки, т.е. без округления, вне зависимости от вида опциона (если это необходимо, я могу его выслать). Однако, как мы видим по описанному выше, ошибка все-таки на стороне Квика, а не МетаСтока.

При выводе волатильности из Квика в метасток, в последний поступают только округленные целочисленные значения, тогда как волатильность расчитывается с точностью до 3-го знака после запятой.Работать с такими данными затруднительно.
Может быть существуют какие-то настройки? Я их не нашел, брокер подсказать не смог.
Более 4-х лет назад я уже поднимал эту тему на данном форуме ссылка: http://forum-archive.quik.ru/forum/iwr/67940/68021/ , высылал скриншоты графиков из Квика и Метастока, однако ошибка как была, так и осталась!
Неужели ничего нельзя сделать?