Общие вопросы по написанию скриптов LUA. (Страница 1 из 10)

1. Не совсем понятно: что-то не работает, заявка не снимается?
Или вы ищите логику?

2. Про какой поле какой структуры речь?

1. Нет, заявки снимаются, это проверенная функция. Если кратко, то какие поля обязательные. В частности интересует "ORDER_KEY", т.к. именно с его получением будут проблемы. Точнее думается мне не с самим получением, а скорее с необоснованным разрастанием кода чтобы их получить. Хотелось бы избавиться от этого поля и обойтись самым минимумом "ACTION", "CLASSCODE", "SECCODE", "TRANS_ID". Все это мне известно даже в случае любых сбоев в работе скрипта. А вот "ORDER_KEY", в отличие от "TRANS_ID"(его я формирую в строгом соответствии своей системе), формирует брокер по своей системе. Соответственно его надо выдергивать из терминала, а по сути он мне вообще не нужен.
2. Вот про эти, взято из справки.

Флаги для таблиц «Заявки», «Заявки на внебиржевые сделки»

Флаг установлен Значение 
бит 0 (0x1)  Заявка активна, иначе – не активна  
бит 1 (0x2)  Заявка снята. Если флаг не установлен и значение бита «0» равно «0», то заявка исполнена  
бит 2 (0x4)  Заявка на продажу, иначе – на покупку  
бит 3 (0x8)  Заявка лимитированная, иначе – рыночная  
бит 4 (0x10)  Исполнить заявку по разным ценам  
бит 5 (0x20)  Исполнить заявку немедленно или снять (FILL OR KILL)  
бит 6 (0x40)  Заявка маркет-мейкера. Для адресных заявок – заявка отправлена контрагенту  
бит 7 (0x80)  Скрытая заявка  
бит 8 (0x100)  Снять остаток  
бит 9 (0x200)  Айсберг-заявка  
бит 10 (0x400)  Заявка отклонена торговой системой  
бит 20 (0x100000)  Поле «linkedorder» заполняется номером стоп-заявки  

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

Из "собственной практики" в данном случае что-то подсказать не смогу.

1. Понял, буду пробовать.
2. Заявки лимитные конечно же.
Суть вопроса не в этом. Как ведут себя эти флаги при частичном исполнении лимитной заявки(либо же есть другие флаги, либо их просто напросто не существует. В справке я их не нашел)? Например, есть лимитка на 25 лотов. По каким то причинам, неважно каким, она исполнилась только частично, например, не 25, а 15 лотов купилось, остальные 10 остались висеть. Теперь роботу надо принять решение, ждать дальше или убить заявку с остатком. Вот и думаю как это организовать с прицелом на будущее. В будущем еще планирую обрабатывать этим же роботом заявки, выставленные или снятые вручную(именно поэтому я и стал заморачиваться с флагами). Это необходимо мне, если вдруг посчитаю необходимым вручную подкорректировать работу робота, но это на следующем этапе написания.

Вообще здравому смыслу, заявка не может быть одновременно и активной, и снятой. Да и пробовал я читать эти флаги во всех возможных вариантах, значений 3 и 7 нет. А вот прочитать флаги у частично исполненной заявки мне так до сих пор и не удалось. Возможно что эти значения и интерпретируются как частично исполненные...

Так вобщем проблем не вижу честно говоря

if bit.band(flag,0х7) == 0х0 then   -- Маскируем ненужные биты и сравниваем
  message("Покупка свершилась!")
end

Лично код не проверял, но думаю как то так. На си постоянно подобным образом поступаю, правда там вообще нет битовых операций Шестнадцатиричные числа всегда применяю при таких операциях, это визуально отделяет битовые операции от математики. Да и удобнее это.

Замечательно, тогда и противоречий нет, раз не бывает таких значений.

Но здесь вы проверяете сразу 3 бита, а не один; вернее проверяете, что все три младших бита не установлены.
Это именно то, что вы хотели проверить?

Где нет битовых операций? в Си??

В смысле практического применения это не отличимо, считаю

std::bitset в C++

Но это так, в порядке off-top

Сейчас обдумываю как отрабатывать частично исполненные заявки. Посмотрел в сторону колбэка OnOrder(), в его описании достаточно расплывчато прописано "при получении новой заявки или при изменении параметров существующей заявки.". Если с новой заявкой более менее, как минимум для рыночных и лимиток точно, то расплывчатое "при изменении параметров существующей" следует понимать параметры самой таблицы(такие как balance, value и прочие) или что-то еще???
1. OnOrder(TABLE order), опять же мне не понятно, в таблице будет только изменившаяся заявка или будут все до единой, что придется их перебрать по образу и подобию? Хотя в этом случае теряется смысл колбэка.

function DL()
    local n = getNumberOf("depo_limits")
    local quantity    = 0
    local price        = 0
    local block        = 0
    local y            = 0
    for y = 0, n-1 do
        trade = getItem("depo_limits", y)
        if    (trade.client_code == CLIENT_CODE)            and    
            (trade.sec_code ==    SEC)            and
            (trade.trdaccid == TRADE_ACC)        and
            (trade.limit_kind == 2)            then
                quantity    = Rounding(trade.currentbal, 0)
                price        = Rounding(trade.wa_position_price, PRICE_SCALE)
                block        = Rounding(trade.locked_sell, 0)    
                break
    end
   end
    return quantity, price, block
end

Ребята, привет!
Сорян, что вмешиваюсь, но если порыться по форуму, то тут полно решений.
На транс_ид вообще не нужно обращать внимания, т.к. на нем логику невозможно построить без костылей
сразу прописываете
для новой заявки:
trans_id = "777"

для снятия заявки
trans_id = "666"

и всё на этом. смотрите в сторону brockerref(описание заявки) - оно есть везде и можно унифицировать каждую заявку в отдельности, дробным числом, строкой - пофик, главное не больше 20 символов, включая код клиента(для моекс)

Без логгирования текущего состояния заявки вы не сможете торговать, допустим у вас не было 1 день тока и ппц, данных в терминале через день не будет и взять негде.

Сейчас на выходных, пока биржа закрыта торгую на демо счете. Стоит квикджуниор. У меня вопрос, вот эта функция не хочет брать данные из

function DL()
    local n = getNumberOf("depo_limits")
    local quantity    = 0
    local price        = 0
    local block        = 0
    local y            = 0
    for y = 0, n-1 do
        trade = getItem("depo_limits", y)
        if    (trade.client_code == CLIENT_CODE)            and    
            (trade.sec_code ==    SEC)            and
            (trade.trdaccid == TRADE_ACC)        and
            (trade.limit_kind == 0)            then
                quantity    = Rounding(trade.currentbal, 0)
                price        = Rounding(trade.wa_position_price, PRICE_SCALE)
                block        = Rounding(trade.locked_sell, 0)    
                break
    end
   end
    return quantity, price, block
end

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

возможно на квикджуниор другие коды классов

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

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

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

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

для такой конструкции вам понадобится 2 уникальных составных ключа, которые имеют общую составляющую "класс_код_инструмента"(эт по минимуму, неплохо вкрутить в ключ - код клиента, счет, краткое название стратегии) -  по одному ключу для заявок на покупку и заявок на продажу.
оба ключа должны быть известны обеим структурам для разделения обязанностей, т.к. структуры могут быть выполнены в разных луа-машинах
и да, ключи должны получаться из полей таблиц(заявки/сделки) и колбэков одинаковым алгоритмом:
"260026_TQBR_SBER_B1" - где B1 => B - стратегия, 1 - покупка, 2 - продажа
"260026_TQBR_SBER_B2"
B1/B2 пихаете в описание заявки при выставлении - поле brokerref, остальные параметры - как душе угодно и какие угодно.