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

Постройте график и посмотрите.
Очевидно же, если на графике такая же ситуация значит проблема на стороне брокера, если нет значит на стороне скрипта

Здравствуйте.
нет.

Добрый день,

Мы рекомендуем отказываться от использования Lua 5.3 и переходить на Lua 5.4. Какие-либо доработки в Lua 5.3 не планируются.

Это строковые параметры, а не числовые. Значит выводить надо param_image

А если открыть график и посмотреть, там так же?

Выпуск такого API не планируется, потому что уже есть FIX приборы.


таких планов у нас также нет.

Проблема изучается. Постараемся в ближайшее время дать ответ.

Здравствуйте,
Проблема не воспроизводится.


Проверьте еще раз Ваш код

Да он не нужен

Нужен полный код на котором воспроизводится

точно ли код класса указан верно?
Такой класс есть только на нашем демо контуре, у брокеров нужно указать TQBR

Для заявок OrderNum+ClassCode+TradeDate
Для сделок TradeNum+Operation+ClassCode+TradeDate
Для обезличенных сделок TradeNum+ClassCode+TradeDate+SecCode

на сделках (не обезличенных) нумерация на разных инструментах одного класса не совпадает.
Да это значит что номер одной сделки в обезличенных, и в обычных, может быть разным

Старатель,
Уже был развернутый ответ

Старатель,
Речь о некоторых зарубежных шлюзах, где номер обезличенной сделки может быть один на разных инструментах одного класса.
В свое время, из-за этого SecCode был добавлен в список первичного ключа таблицы AllTrades в модуле экспорта биржевой информации.

Старатель,
К сожалению в ответе произошла ошибка.
Заявки не могут быть с совпадающим номером на одном классе.
И SECCODE на транзакции KILL_ORDER не нужен.
И в Lua тоже. Почему у автора не получилось снять заявку не понятно.
На самом деле номер в разрезе инструмента может совпадать только на обезличенных сделках

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

Проблема изучается. Постараемся в ближайшее время дать ответ.

Речь была именно про запрос на сервер. те запрос к серверу, сколько есть на сервере в такой-то таблице.

Вы боитесь что сервер подсчитает сколько лимитов отправить пользователю с задержкой, т.е. пользователь получил класс и право им торговать, но сам сервер еще не одумался есть ли у пользователя лимиты? Такая ситуация невозможна, если бы она существовала то это была бы дырень в безопасности.

Мы же договорились что getServerNumberOf вернет данные в момент запроса. Хотите запрашивайте ДО описания параметров таблицы Торговые счета, хотите после. Вам уже решать


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

Если второй шлюз подключился, и засылает те же бумаги что и первый, с теми же фирмой и счетом, значит у пользователя УЖЕ есть нужные лимиты (получил при первом шлюзе) и условие сработает т.к. грузить просто ничего не надо.

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

Если счет и фирма та же, но бумаги другие, значит либо будет лимит по новым бумагам (условие не сработает), либо лимитов вообще нет и не будет (это допустимо т.к. ранее уже был лимит с нужным счетом).

ответ УЖЕ был:

Ошибаетесь.
Если лимит есть на сервере, но еще не загружен в терминал то условие НЕ выполнится и getNumberOf("depo_limits") покажет МЕНЬШЕ чем getServerNumberOf("depo_limits").


Ошибаетесь.
Раз данные получены с сервера, значит либо лимит есть и тогда Вы его увидите в depo_limits.
Либо лимита нет, просто нет, а не "еще не загружен".

Mixa,
Пожелание уже было зарегистрировано (см соседнюю ветку).

И что это меняет? Пожелание было зарегистрировано с оговоркой чтобы гипотетическая функция getServerNumberOf будет работала для всех таблиц из списка getItem, в том числе и trade_accounts.
Таким образом, Вы сможете проверить наличие прав при условии что getServerNumberOf("trade_accounts") == getNumberOf("trade_accounts")
т.е. после того как (getServerNumberOf("depo_limits") == getNumberOf("depo_limits")) и (getServerNumberOf("trade_accounts") == getNumberOf("trade_accounts")), проверяем по trade_accounts наличие прав на нужный класс и ищем в depo_limits нужный лимит, уже уверенные что данные получены с сервера.

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

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

Для того чтобы снять стоп, параметр TRANS_ID вообще не нужен.
В транзакции на снятие стопа есть только номер стоп заявки, это НЕ тоже что TRANS_ID.

TRANS_ID - Нужен исключительно Вам т.е. Вашему роботу. QUIK на него вообще никак не смотрит.
Нам не известно какая логика заложена в Вашем роботе, следовательно не можем ответить на вопрос о его поведении.

Не понятно что Вам мешает это сделать
Есть понимание какой смысл в TRANS_ID Вам нужен? Если нет, тогда определитесь и далее исходя из этого действуйте.

UNIX TIME - это просто количество секунд начиная с какой-то даты (1 января 1970г).
можно получить через тот же os.date
Судя по всему, Вам не это нужно.
Просто сами определите для себя какое число Вам требуется и сгенерируйте. тех поддержка в этом месте не причем.
Вопрос только и только на Вашей стороне.
Хотите, считайте тот же UNIX TIME но с 2000 года
или "сожмите" дату до нужного размера (например сложив чила)
Или другие варианты которые Вам понравятся.

Определите самостоятельно, это не так трудно.

Еще раз. Если количество строк в таблице терминала равно количеству строк на сервере, это УЖЕ факт того что данные загрузились.
Какие данные? Вы УЖЕ можете проверить т.к. есть факт что они загрузились.

А Вы понимаете, что Вам уже несколько раз было предложено?
И в чем разница:
"если количество строк в таблице = количеству на сервере, значит данные загружены, а раз нужных данных в таблице нет, значит их действительно нет.

??
Докажите что Ваше предложение хоть чем-то отличается от нашего?
разница только в том что наше в разы проще в реализации.

Выше было сказано, цитата:
Ситуация:
Запись {Firm2 = {D, E}} в trade_accounts есть, значит права есть. И это точно.
флаг, что все данные в таблице загружены получили.
Нужного лимита среди данных нет, значит его просто нет (брокер не загрузил)

Это легко проверить самостоятельно

У нас нигде нет никакой структуры определяющей строгость загрузки тех или иных данных.

Иван,
Дополним,
судя по всему вопрос не технический, а логический. Нам не важно что вы напишите в TRANS_ID, главное чтобы размер был не больше «2 147 483 647»

Вы сами решите для себя нужна ли Вам вообще os.date("%d%H%M%S"), может ее не надо там указывать и все?
если нужна, сами для себя решите зачем, может там достаточно краткого формата ДДММГГ

Если вопрос в том, как в os.date указать выходной формат, то ответ есть в документации на Lua

Иван,
Вы же сами сказали что от «1» до «2 147 483 647»
В чем сложность сгенерировать число входящее в этот диапозон не понятно.
Если хочется получить его из даты, тот же UNIX TIME вполне в него влезает

Если фирмы нет, значит в правах на классе только одна фирма.
Возможность торговли от разных фирм доступна только сотрудникам брокера.

Mixa,
По сути Вы хотите две разные вещи. Флаг загрузки данных (его нет) и флаг наличия прав (уже есть в trade_accounts).
Вы же всеми силами пытаясь объединить два разных флага в одну функцию по косвенным признакам. А это вызывает вопросы и примеры трудности реализации.
Проще говоря, возникает слишком много разных "если".
Предложенный пример не будет надёжно работать т.к. наличие прав не всегда равно наличию данных.

Ранее Вы сами предложили
Вам предлагалось зарегистрировать такое пожелание. А именно проверку количества строк в таблице с количеством строк доступных на сервере.
Если количество совпадает то данные загружены, если нет грузятся.
И на наш взгляд такая реализация вкупе с проверкой trade_accounts решает поставленную Вами задачу, без излишних "если".


В данном конкретном примере функция isLimitsLoaded вообще не нужна, и даже "Флаг загрузки данных" не обязателен, хотя его можно было бы добавить при желании:

После подключения первого шлюза сервер сверяет транслируемые классы с правами пользователя и отправляет клиенту trade_accounts в которой уже есть данные вида {Firm1 = {A, B}}
Пользователю приходят лимиты по бумагам, содержащимся в классах A и B, в т.ч. по бумаге X. Как обычно,  в этой части никаких изменений не требуется!
Пока лимиты грузятся можно было бы добавить проверку "Флаг загрузки данных".
Но в trade_accounts нет {Firm2 = {D, E}}, поэтому скрипт ждет.

Далее запускается второй шлюз.
И клиенту транслируются лимиты по бумагам D и E. Поскольку лимиты по бумаге X уже были раннее загружены, то повторно не транслируются. Все как обычно,  в этой части никаких изменений не требуется!
Клиент уже может проверить наличие {Firm2 = {D, E}} в trade_accounts
Если есть  =>  Лимиты по бумаге X  загружены (скрипт может это проверить в таблице лимитов), можно торговать в  классе E.

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

_sk_,
Если права одинаковые, тогда да.

Конечно нет, это исключено. Только брокер может видеть заявки других клиентов.

Задача не решаема в том контексте который Вы просите. Ранее Вам предлагался признак загрузки всех строк в таблице лимитов - такое пожелание возможно.
Как уже было сказано, в предложенном варианте, серверу понадобится проверить ранее отправленные лимиты, сверив их с поступившим набором инструментов. Чтобы убедиться что отправка действительно была. Иначе вариант с правами не надежен.


Да, сервер проверяет права на классе. Фирма счет (код клиента) и отправляет клиенту те лимиты которые им удовлетворяют.
Что это даст не понятно.
Например на СПБ американские бумаги, на ФР российские, права одинаковые, лимиты разные. В результате только проверки прав недостаточно.

Cервер так и делает, было же сказано что если прав нет то и лимитов нет.

В зависимости от настроек на стороне брокера, код клиента и комментарий могут разделяться либо "/" либо "//".
Посмотрите как оно выглядит у Вас в таблице заявок

Эти "внутренние признаки" есть только на транзакции.
Сервер получает транзакцию и запоминает  "внутренние признаки"
Далее транзакция отправляется на биржу и там регистрируется заявка.
Обратно на сервер отправляется две сущности, ответ на транзакцию (текст типа "ваша заявка зарегистрирована...") и тело заявки (то что в таблице ORDERS биржевого интерфейса).
Далее серверу нужно найти исходную транзакцию и связать ее с заявкой, происходит это через ответ на транзакцию.
В ответе на транзакцию есть номер заявки, в теле заявки тоже есть номер заявки. Таким образом, зная это, сервер может найти исходную транзакцию и взять из нее "внутренние признаки" которые потом установить на теле заявки.
Все усложняет то что тело заявки и ответ на транзакцию едут разными потоками, которые никак между собой не синхронизируются.
Если ответ на транзакцию приехал раньше тела заявки то проблем нет, сервер заранее определяет "внутренние признаки" и когда заявка приедет, отправит ее клиенту вместе с признаками.
Но т.к. потоки не синхронизируются бывают случаи когда тело заявки приезжает ДО ответа на транзакцию. Т.е. сервер получает тело заявки и не может найти исходную транзакцию, тогда тело заявки сразу передается клиенту, а потом, когда поступает ответ на транзакцию, сервер делает еще одну отправку тела заявки, но с уже проставленными "внутренними признаками"
Исходя из этого, отвечаем на вопрос, мы не можем своими внутренними признаками определить, ручной ордер или нет до тех пор, пока не получен ответ на транзакцию.


Да brokerref, там должен быть комментарий. Проверьте еще раз.

Никто не говорил про повторную загрузку.
Говорилось про проверку доступности, а не загрузку. Это не одно и то же.

По сути это и есть "повторная проверка доступности", разве нет?
И как уже было сказано, trade_accounts это как раз и есть проверка прав по firmid + class_code и Вы сами сказали что задачу это не решает.

К сожалению, наш внутренний регламент не разрешает связь клиента с разработчиком.

Еще раз, trans_id это наш параметр, его в принципе никогда нет в ордере. Наш сервер его проставляет, а не биржа.

Это описано в биржевом протоколе, который не является тайной.
описание на сайте биржи:
http://ftp.moex.com/pub/ClientsAPI/ASTS/Bridge_Interfaces/Equities/Equities3­8_Broker_Russian.htm

К сожалению разговор уже идет по кругу.
Никак нельзя определить что лимиты загружены по firmid + class_code.
Просто нет и все.
Дорабатывать как то сервер ради этого нецелесообразно, значит работать только с тем что есть.
А того что есть недостаточно, альтернативный вариант Вас не устраивает.
Итого задача не решаема а значит считается закрытой.
Ок?

CLIENT_CODE - это биржевой параметр. Вы отправляете транзакцию на биржу и в OnOrder приезжает тело заявки с биржи, включая CLIENT_CODE.



Мы не можем что-то добавить в биржевой протокол, только биржа это может.
Добавить свои собственные параметры, да можем, и UID и trans_id мы как раз и добавили.
Добавить к ним еще один? Зачем он ведь будет работать точно так же. И с ним будут точно такие же проблемы.

От чего же, Вы хотели
таблица trade_accounts ровно это и покажет.
Да она не показывает именно лимиты, но Вы сами же сказали что это и не требуется
Ок, смотрите trade_accounts
Если там нет нужной "firmid + class_code" значит и лимитов по ним нет. И это точно.
Если есть, значит лимиты есть, потому что запись там не появится пока не будет получен лимит по любой бумаге связывающей фирму+счет+код клиента.

Нет, лучше trade_accounts (Торговые счета), там есть связка фирма+счет+список классов

Тогда смысл в чем? Смотрите колбек OnFirm или таблицу firms, там правда нет класса, есть торговая площадка (по сути рынок). Вот Вам и isLimitsLoaded

Еще раз.
Лимиты не привязаны к классам.
Есть лимит, в нем фирма и инструмент, класса нет.
Как по Вашему, сервер должен понять по  firmid + class_code что например лимит по LKOH из TQBR должен вернуть true, при условии что лимит уже был отправлен в EQRP_INFO?
Допустим, для первого класса EQRP_INFO все понятно, сервер может его запомнить при первой отправке и функция сработает.
Но как он должен понять что по TQBR тоже должен вернуть true? только если залезет в "отправленные" и еще раз проверит лимит по LKOH на доступность.
"Доступность" это ведь не только фирма и класс, но и инструмент же. Если какой то инструмент снимут с торгов (со всех классов), сервер не отправит лимит.
Получается серверу придется выполнить одну работу уже два раза. А у брокера миллионы, десятки миллионов, лимитов по 236 классам и это только ФР. Представьте как север будет их все проверять.

Сейчас сервер не проверяет те лимиты которые уже были отправлены.
Если делать по Вашему, то серверу придется при появлении каждого инструмента по каждому классу проверять все ранее отправленные лимиты. Такая нагрузка потенциально увеличит время готовности сервера в разы.