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

"В последнее время несколько раз наблюдал такое: приходит OnTrade, в котором trans_id=0. Я знаю, что это промежуточная версия, поэтому в мой алгоритм вписано игнорировать такие вызовы, ожидая более полных. И почти всегда они приходят. Но в среднем 1-2 раза за день случается так, что полный OnTrade с ненулевым trans_id так и не приходит. В чём может быть причина?"
Ответ очевиден может.

Ситуация, которую вы описываете, связана не с багом в вашем коде, а с особенностями того, как QUIK и брокерский шлюз доставляют информацию о сделках. Подобную ошибку в событийной модели допускают даже грамотные, опытные разработчики на QUIK. Используя "умную заявку" (один trans_id=const на весь жизненный цикл инструмента, для 3 таблиц) в своих подходах, отлавливал такую же проблему.

Почему полный OnTrade может не прийти? То, что за день теряется 1-2 полных события, — это тревожный, но, к сожалению, не уникальный случай для распределенных систем.

Вот наиболее вероятные причины:

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

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

 * Особенности логики брокерского шлюза: Хотя это менее вероятно, существует возможность, что в редких случаях логика шлюза, отправляющего два события (служебное и полное), дает сбой, и второе событие не генерируется.

Наверняка список можно расширить.

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

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

Или вот это, До обсуждались, про супер: А Не смущает то что мы ее задаем и вынуждены контролировать? Постоянно так Quik Ни чего нигарантирует?

А вот это обидно! А Вы уберите sleep   и по рассуждаем чья инженерия кода лучше?

Это маленькая толика, возможных ситуаций, довьёт еще свои. и будем обсуждать Ваши, подход ваш так себе.

User12501, Скажите на русском читаете, если нет, то какие слова Вам не понятны

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

Вы рано радуетесь все работает не корректно в части секции срочного рынка

Спасибо действительно. Здесь видимо дело вот в чем, ломается глобальный 30 летний тренд "Carry Trede", все разом поменяли маржинальные требования. А товарные рынки перекредитованы больше всего.

У себя даже собрал рабочий “BoJ-радар” в TradingView, как систему ранних предупреждений. Цель: увидеть глобальное сжатие ликвидности за 1–10 дней до падения рынков.
Все просто на грани, а ниточка на которой все весит тоненькая. Стоит  BoJ пошевелить в сторону увеличения, и "медный таз" неизбежен, накроет.

Я торгую лимитными ордерами а там 0 за сделку.

Но согласен, брокер не для срочного рынка. Вот и смотрю куда податься, без ответственность ARQA и смешивания всего на брокеров приводит к тому что чудят все брокеры. Вот и хотелось бы понять кто в меньшей степени. Стоит менять "Шило на мыло"?

А Стакан 50 очень удобно  я им активно пользуюсь на срочном, супер!

Начал искать куда бы сбежать от этих "талантов", так ка и другие чудеса демонстрировали без стеснений. Обратил внимание на ВТБ, не стакан а целая книга ордеров на срочном? Кто торгует поделитесь мнением?

Izotova Liliya,  И причем тут рабочее место? Чудит брокер Сбер. А виновато рабочее место. Проблемы ТРЕТИЙ день с лимитами на срочном рынке, Ни чего не отображается. Допустим у меня просто пропал торговый счет == коду клиента.

nikolz,  Вывожу по основному счету и фильтрую по виду, так хоть количество видно, а денег нет? Вот чудеса, а Сбер брокер самый "талантливый", у других брокеров проблем не вижу.

TGB,  Ну так это же просто двойная очередь, с которой я разбирался и только ленивый меня "по столу носом не возил". Более медленный вариант, чем скажем кольцевой буфер? Можете архитектуру привести или пример?

Просто разбираюсь с тем же самым, и вот что удалось выяснить не который слой ошибок. Почему роботы закрываются "просто так" и как это фиксят в проп-торговле?
Это класс ошибок, который случается даже с идеально спроектированными системами. И причина всегда одна: > Расхождение между биржевой реальностью и состоянием в QUIK!

Вот конкретные механизмы  (примеры).

1. Главная причина: Асинхронность данных в QUIK. Здесь помним QUIK — это клиент терминал, а не биржа!

Время в QUIK ~= Время на бирже
local q_time =  -- локальное время QUIK
local e_time = -- время биржи (если доступно)
Разница может быть ~ 0.1-5 секунд, а то и более!

Что происходит:
1. Биржа. Цена прошла стоп > стоп сработал;
2. QUIK (через 0.5-2 сек). Получил тик > показал в стакане;
3. Робот. Увидел в стакане > решил "стоп сработал";
4. Но, Стоп уже сработал на бирже, а в QUIK ещё не отобразился.
Результат: робот пытается отменить уже исполненный стоп > получает ошибку!
--------------------------------

2. "Призрачные" стопы в QUIK. QUIK показывает активный стоп.
stop_order = getItem("stop_orders", index)
if stop_order.flags == 1 then
   -- Считаем активным
   -- Но на бирже он мог уже сработать!
end

Это случается при:
* Лаге данных (биржа > шлюз брокера > QUIK);
* Частичном исполнении (часть уже исполнилась, QUIK ещё не обновил qty);
* Ошибках протокола (QUIK не получил подтверждение удаления).
--------------------------------

3. Классический кейс рассинхрона. Таймлайн (реальный):
[00:00.000] Цена Bid = 100 000 (на бирже)
[00:00.100] Цена достигает стопа 100 000
[00:00.150] Биржа исполняет стоп
[00:00.300] QUIK получает обновление стакана
[00:00.350] Робот видит Bid = 100 000 > думает "стоп ещё не сработан"
[00:00.400] Робот пытается изменить стоп > ошибка

Извините, странно работает сегодня сайт у меня. Возможно так понятней:

local function round(num, idp)
 
  -- Если num некорректное, вернуть как есть
  if not num or type(num) ~= "number" then return num end

  -- Если idp не указан, использовать 0 (округление до целого числа)
  idp = idp or 0
  local mult = 10^idp

  -- Универсальное Округление для любого числа
  local rounded = num >= 0 and math.floor(num * mult + 0.5) / mult or num < 0 and math.ceil(num * mult - 0.5) / mult or 0
 
  -- Если число целое, убрать .0
  if rounded == math.floor(rounded) then
      return math.floor(rounded)
  end

  return rounded
end

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

Если в двух словах, так мониторю интернет. Кроме любителей для частного использования, пишут и применяют подходы:
1. Проп - трейдинг. Управление капиталом до не большой суммы M руб, несколько инструментов одновременно, с Квартальной надёжность > 99.9%;
2. Алготрейдинг для фондов. Обязательно исполнение крупных заявок (iceberg, TWAP), хеджирование портфелей, арбитражные стратегии;
3. Инфраструктурный проект. Базовый фреймворк для других разработчиков, возможное решение для брокеров или платформа для обучения risk-менеджменту.
Такие системы называю - промышленный уровень, так как к ним предъявляются более жесткие требования.

Эмуляция разных видов сбоев QUIK, приводит к необходимости оценки не только кода. Что должно подлежать оценки и что оцениваю в настоящий момент: Архитектура, Надёжность, Безопасность, Производительность, Production готовность, Общая оценка на соответствие - Промышленному уровню..

ВЫВОД: в условиях ограничений QUIK нужно создать система, которая отвечает следующим требованиям:
*  Признаёт реальность - QUIK ненадёжен, и мы строим защиту;
*  Разделяет ответственность - каждый компонент делает одно дело;
*  Самовосстанавливается - любая ошибка не фатальна;
*  Гарантирует безопасность - риск никогда не увеличивается;
Это пока база. Нужно добавить Session Risk Manager, система станет законченным продуктом уровня проп-десков?

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

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

А задача стоит, приврать систему если не в «надежную» то, в предсказуемо безопасную и рассуждая о ней как о risk - engine, а не просто коде? Что думаете не возможно?

Сказать "Просто" - это просто, сделать, вот вопрос. Отлавливая ситуации при которых квик может похоронить все твои начинания, превзошли все мои ожидания! Не ведь, крутился же скрипт, да и ладно.

Проверка подхода, надёжной архитектуры: "FSM + события терминала как единственный источник истины",  приводит к такому количеству ситуаций, при которых сервис если не падает, то надежным точно не назовёшь. А ведь задача отслеживать позиции и их защищать, в круглосуточном режиме.
Нет и уверенности, что все причины возможных сбое установлены?
Другой вопрос возникает, а снимут ли корутины часть проблем?

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

dimka,  По пробуйте, выводить значения индикатора, используя этот подход. [CODE][local function round(num, idp)
   
   -- Если num некорректное, вернуть как есть
   if not num or type(num) ~= "number" then return num end
 
   -- Если idp не указан, использовать 0 (округление до целого числа)
   idp = idp or 0
   local mult = 10^idp

   -- Универсальное Округление для любого числа
   local rounded = num >= 0 and math.floor(num * mult + 0.5) / mult or num < 0 and math.ceil(num * mult - 0.5) / mult or 0
   
   -- Если число целое, убрать .0
   if rounded == math.floor(rounded) then
       return math.floor(rounded)
   end

   return rounded
end/CODE]

Просто решил переписать выставление стоп - лосс. Не  просто «скрипт», а сервис сопровождения позиций. Архитектура stop-manager для QUIK как конечный автомат (FSM).
В QUIK такой подход, единственная надёжная архитектура: FSM + события терминала как единственный источник истины?

Создаем источник данных:
local ds, err = CreateDataSource(...)
После ~30–80 инструментов в QUIK возникает потенциальная утечка?
Что в свою может привести: начнет тормозить, потом перестанет обновлять бары?
Тогда возникает вопрос простой а где и когда правильно ставить ds:Close()? На что держать ориентир?

Дело обстоит далеко не в величине коррекции или то что она приходит на смену тренду. Картинка проставленная выше VPM, подходит как как для графика серебра так и золота.

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

Вы о чем? Из Вашей картинки ничего не понятно.

nikolz,  На мой взгляд это из одной области и все туда же к "Сивой кобыле". Ну вышла и вышла, еще показать себя надо. Ну или падение на 1.2%? Даже комментировать не буду.

А вот что важно, не найти. На пример почему Шанхай дает премию по серебру ~ 30$ за унцию серебра? Куда реки текут? На наших глазах делаются состояния. А расскажут потом. Но я собственно ответы нашел и тема стала не интересна.

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

Нашлись и миллиарды зеленых, их просто пере парковали в юани. Интересный факт вызывает еще один момент. Запасы золота Центробанков стран "колонистов" находятся на уровнях ~ 65% (для примера в РФ ~30%)!  А как дела во второй экономике? Называется оценка порядка 8% хотя гребут все последние годы, и цена их ни очень смущает. И при этом строится мировая валютная инфраструктура, в том числе и "автомагистраль" параллельная, дороге под названием SWIFT. Вот в общем то все и стало на свои места, "богатые богатеют бедные беднеют". Вот и сказочке конец, а кто слушал молодец! Всем хорошей торговли.

Время сказочек наступило, моя для тех, кто торгует фьючерс на золото.

Сказочка раз - "Наш паровоз вперед летит, в коммуне остановка ...". Вот и рынки золота и серебра.

Данные события наверняка попадут в книги как исторические события 29.01.26 г., и позже будет высказано много мнений, по этим ситуациям. Но сегодня ничего не найти. У меня была открыта небольшая позиция в лонг на GOLD - 3.26, в конец основной торговой сессии (MOEX)  пятница. Наблюдаю такую картину: Просто как по команде начали закрывать позиции, а деньги выводить с рынка, крупными участниками. В разы увеличились "медведи" и куда то подевались "быки" (не кроме меня конечно). Сам торгую технический анализ, и ни чего не понимаю, что происходит фундаментально. Поискал новости - Предполагаемая смена главы ФРС, ну бред "сивой кобылы"! Так как моей цель был гэп понедельника, оставил позицию. Это и сделало меня не просто наблюдателем - участником.  Эти удивительные фундаменталисты, от куда только "не трубили" о приобретениях, и ни чего в исторический момент?
Про то как все было дальше в общем то не интересно. А вот что интересно, остановка - "коммуна". Всего лишь нажата кнопка: "Повышения маржинальных требований", и колеса паровоза закрутились в обратную сторону, а стоимость билета превратилась в триллионы зеленых. Нужно тут добавить, что после этой бумажной манипуляции, спрос на фактическое золото и серебро не упал, и по всей видимости они в дефиците, но это уже к нашим коллегам фундаменталистам.
Почему исторический - такой или примерно такой сценарий  уже исполняли и не раз. А быть участником каково?

"Разделяй и Властвуй"

Вновь и вновь возвращаюсь к примеру автор Nikolay №558,  Назову его "ФУНДАМЕНТАЛЬНЫМ" для QUIK / QLUA. Попробую разобраться с подходом, что здесь за модель и как из неё сделать универсальный боевой модуль, не сломав фундаментальные допущения?

Что уже реализовано — это кооперативный неблокирующий планировщик задач (cooperative task scheduler) в одном Lua-потоке, с:
* отсутствием ожиданий по времени;
* отсутствием блокировок;
* отсутствием предположения о задержке (assumptions о latency);
* прогрессом по факту изменения состояния.
И это НЕ очередь задач в классическом смысле. Это конечный автомат, опрос, управляемый событиями, (event-driven polling FSM).
Главное архитектурное решение (и оно единственно верное): > Мы не знаем, сколько времени займёт операция. Следовательно,

Нельзя:
* sleep(n)
* while not ready do end
* «ждать 30 секунд»
* «ждать 2 минуты»

Можно:
* проверять факт изменения состояния;
* делать это часто;
* не блокировать выполнение.

В коде "task" — это: > Объект проверки состояния, а не операция.
task.process = function()
   if условие_выполнено then
       return done
   end
   -- иначе ничего не делаем
end

И это принципиально, по следующим причинам:
* task.process() не делает работу,
* она проверяет, завершилась ли работа,
* сама работа выполняется вне task (QUIK, брокер, сервер).

И это правильная модель для:
* DataSource;
* транзакций;
* подписок;
* внешних сервисов.

Почему модель классная, а главное масштабируется. Очень важный плюс текущего подхода:
* можно иметь 100 DS
* можно иметь 1000 задач
* ни одна не блокирует другие
* все живут в одном цикле

И это уже:
* не потоковая модель;
* не callback-ад;
* не FSM в лоб.
Это кооперативная многозадачность, и для QLUA она оптимальна! Ну хоть и "опосля", ну доходит!

Главный вывод (ключевая формулировка).

Этот пример кода — с: > Неблокирующий кооперативный планировщик проверок состояния внешних асинхронных процессов. И это ровно то, что нужно для:
* DataSource;
* транзакций;
* брокерских ответов;
* пользовательских команд;
* UI;
* логики стратегий.
и что там еще нам нужно в нашей деятельности.

Это изначально, выбор правильного фундамента. И тут можно было бы закончить, поблагодарив автора за столь мощный "ФУНДАМЕНТАЛЬНЫЙ" пример.

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

Как только появляется:
* DS, которые живут часами,
* транзакции с неопределённым задержками (latency),
* стратегии, подписанные на бары,
* команды пользователя,
* аварийные события.
список превращается в плоскую кашу, и дальше начинается:
* If-ад
* флаги поверх флагов
* неявные зависимости
* ошибки, которые невозможно воспроизвести

Кто это знает, кто уже туда смотрел, и переходит к формированию задачи "планировщик + типы задач (DS, TX, UI)".
Вариант 2 — естественное развитие кода, возможно даже единственно правильный подход для боевого модуля?

Танго,  Попробуйте так:
-- вывожу в таблицу
-- SetCell(TableNaladka,2,2,actualPrice);

Ок, спасибо Izotova Liliya, все так!

Izotova Liliya,  Пользуясь случаем подскажите, при этих настройках я смогу  заказывать получать эти данные с помощь функции CreateDataSource используя четвертый параметр? Или этого недостаточно? За ранее благодарю!

Все подгрузилось на графики, но теперь не понимаю радоваться этому или нет? На сколько скорость терминала упадет, и главное тут чтоб сам устоял, "ни пал лицом в грязь".

"Не что не вечно под луной". Заглянул в настройки котировок, а там классов по "наплодили"   ,  какие торговые, за полгода не разобрать? Пробежался вроде все нужны, парочку только отключил.

Izotova Liliya,  Спасибо принято, действительно упусти этот момент, надеюсь, что и терминал теперь загрузится.

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

А да рад что порадовал Вас!!!

nikolz,  Кто бы не сидел в "песочнице со своим ведерком", ему нужно выбраться. Хотя если ведерко полнехонько то и ладно.
А я лишь о профессиональном подходе к написанию, а главное применению кода. Что касается "Промышленный" это перевод слова "production", значений в  слове на "ангельском" много, поэтому имею право переводить так. Некоторые стандарты к промышленному применению кода есть здесь, а так гугл в помощь.

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

Ответ на Ваш вопрос очевиден, "Промышленный" - это то чем пользуются хэдж - фонды, или закрытые отделы в банках под управлением у которых находятся собственные средства, а не клиентов. И такие торговые платформы отвечают не которым стандартом, где то выше уже какие то стандарты приводил.

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

Ну наконец то "ПрофЭсор" разбушевался. Это видимо то что Вы пропустили в детском саду?  

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

Изначально задача, сводилась  быстро собрать стратегию для проверки идеи, которая  должна была выносить на график множество линий, добавьте сюда мульти тайм фрейм. Только по этому и был выбран этот подход через getCandlesByIndex.
Попробуйте сделайте со своим алгоритмом, его прочитать сложно, не то что решать подобную задачу.

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

nikolz,  "У нас" - это те кто пользуется  инфраструктурой Квика, и я рассуждаю о разворачивании на ее основе торговой платформы на луа, а не вообще. Не нужны, тут ни какие драйвера, кроме того что предоставляет квик. Разворачивая торговую систему, приводя в порядок архитектуру  и дописывая модули, мне это напомнило порядок ОС (как пример DOS). Зная это, можно изначально закладывать архитектуру как промышленную. Сложно но можно!

Не я тоже возмущен почему, у "Условного Маркет Мейкера"  скорость 10 мк.сек. а унас 200 мл.сек., а кому повезет, ну хорошо кто следит, 100 мл.сек.
И это ни сколько не отменяет тот  факт что код может отвечать принципам и требованиям ОС?

Соглашусь с Вами!А Вы спросите у ГЕОЛОГОВ - специалистов? Это просто стереотип!Не не не удивляйтесь, в степях строили "мазанки", в Сибири из бруса, кому удавалось, в основном кругляк, боюсь сказать какие материалы применяются в современном мире.

Сам себе удивляюсь. Разработка концепции "Разделение ответственности", пример выше, привела к осознанию, того что можно строить "Операционную Систему". Да, да и я не описался. Скриптовый язык луа, для торговой системы QUIK, можно строить торговую "ОС" ни прибегая к стороним программам. НУ Хорошо пусть будет платформа. Так я проверил отвечает принципам ОС.
Просто в шоке! А где специалисты? Хоть кто то бы на это намекнул?  

Упёрся ровно в ключевое ограничение QUIK, и если решить его правильно — дальше всё встанет на свои места, очень чисто.
Продлема:
   ->  QUIK НЕ даёт напрямую получить параметры class_code и sec_code из легенды графика.
   -> Легенда — это "UI-строка", не идентификатор инструмента.
Но не обходное решение нашлось, и оно рабочее. Задача. Нужна универсальная функция (алгоритм) утверждающая "это мой инструмент", должна быть безопасна при переключении графиков.

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

Важно. Нельзя здесь конечно ни чего утверждать однозначно.
Так как строится данный алгоритм на гипотезе утверждающей: "Легенда графика всегда содержит short_name, но с хвостом вида: " [Price]" / " [Volume]" / " [ATR]" и т.п.".
Есть просто надежда, что еще какое то время, она просуществует, но ведь существовала же до сих пор.
Возможно это очередной "велосипед", и кто то решал уже подобную задачу, но я ни чего не нашел, поэтому будет "Трехколесный".

Ниже — по порядку.

Что у нас есть?
SecurityInfo.short_name = "Сургнфгз-п"
legenda = "Сургнфгз-п [Price]"

Правильная логика сравнения. Нужно убрать всё после '[' и сравнить "чистые" строки.

if short_name == legend_clean then
   -- это нужный график
end

Это единственный надёжный путь. Стратегия - обратное сопоставление: legend -> short_name -> sec_code + class_code
То есть:
1. Берём legend
2. Извлекаем short_name
3. Ищем инструмент, у которого SecurityInfo.short_name совпадает
4. Запоминаем class_code + sec_code
 
ВАЖНО: коллизии short_name. Это реальная проблема:
* GAZP (акции)
* GAZP-12.25 (фьючерс)
Как защититься (думаю), хранить список, а не один элемент.

Это значит, что мы можем построить полностью автоматическую библиотеку инструментов:

getClassesList()
   v
getClassInfo(class)
   v
getClassSecurities(class)
   v
getSecurityInfo(class, sec)

И уже по легенде графика восстанавливать: legend > short_name > sec_code + class_code.  

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

"А ларчик просто открывался!"

При описанным выше подходе "разделения ответственности", элегантно решаемся еще одна наедающая покоя задача. А именно передача параметра sec_coda из индикатора в луа скрипт. Конечно невозможно поучить во встроенных индикаторах, но всегда можно повторить его в луа, получить параметр и передать, как показано выше в моем  примере.

Добрый день TGB,  то что Вы описываете в определённых стратегиях конечно надежней, но задача далеко не тривиальна, особенно в скоростных алгоритмах. Да и автор вопроса применяет событийный подход. А вопрос звучит так:
Плюс учет различных комиссий в принятии решений, насколько помню точность в учете QUIK до шестого знака. Как же тут не сверять свою вторую бухгалтерию?
 

Концептуально, такую архитектуру можно свести к последовательным шагам взросления системы, в стиле боевого QUIK-safe.
Важных, самостоятельных 4 - логических слоя, как в профессиональных торговых платформах:

ШАГ 1. Цель QUIK-safe. Приведение индикатора к QUIK-safe стилю, для QUIK это будет означать:
1.  никаких глобальных переменных;
2.  никаких "висящих" состояний;
3.  чёткий lifecycle: "init -> bar -> return";
4.  "индикатор не знает про торговлю, только сигналы".

1.1. Новая контрактация индикатора (правильный подход). "Индикатор = детектор структуры рынка, не стратегии". Он должен:
* принимать index, settings, datasourсe;
* хранить локальный state;
* возвращать расчетные значения (для индикатора только линии).

ШАГ 2. Встраивание в SignalEngine. Теперь "SignalEngine — мозг, индикатор — сенсор".

2.1. Контракт SignalEngine (минимальный).
2.2. Использование данных от индикатора (и это уже по взрослому).
ШАГ 3. Indicator / TradingCore (разделение ответственности). Правило №1. "Индикатор не принимает решений".

| Слой              | Отвечает за |
| ------------------ | ----------------- |
| Indicator         | данные        |
| SignalEngine  | оценку         |
| Trader            | ордера         |

-- Trading Core (пример концепции)ШАГ 4. Auto-Regime + фильтры.

4.1. Определение режима.
-- 4.2. Режимно-зависимая (Regime-aware) фильтрация.
-- 4.3. Финальный ScoreИ ни какой магии, типа машинного обучения или нейросетей!  А главное безопасное изменение и замена модулей. Хочется думать так, а жизнь покажет, что опять не учитываю.    

Привел Вам просто базовую свою заготовку, в качестве примера не более. Если вы пишите на луа 5.4, то нужно отказаться от bit.band в пользу продвинутого метода. Что там точно за комиссии, подсказать  тоже не могу так как на каждом рынке есть особенности. Для Фондового API QUIK предлагает предварительный расчет через стандартную функцию. Для оценки можно ее воспользоваться. На срочном есть зависимость от гарантийного обеспечения и курсов ... Что касается моего подхода, то я применяю подход  Ральфа Винса, а именно, торговый капитал делю изначально на две части: пассивный и активный. Так как в процессе торговле всегда присутствует пассивная часть, нет необходимости вести четкий учет комиссий, сверяю по клирингу. Здесь более важен учет количества и цены, так как на прямую влияют на управление позицией.  

User12501,  И это еще не вся проблематика, ведь нужно данные периодически синхронизировать с данными QUIK.