Вопрос: как агрегировать принты по ордерам? 13 ноября 2025, 15:43 Bob Ross Вот в QScalp. например, есть галочка «Агрегировать сделки по заявкам» и все лимитные заявки, съеденные ОДНИМ маркет-ордером, появляются в виде ОДНОЙ сделки (прямоугольника). Тоже задался этим вопросом. На текущий момент я качаю данные из таблицы обезличенных сделок Квика. Как это делается, как можно принты по сделкам отделить? Меня интересует параметр, на основе которого можно разделять принадлежность сделок к тому или иному ордеру, который их исполнил. В параметрах таблицы обезличенных сделок ничего подходящего не нашел. спецраздел: 17 комментариев … Меня интересует параметр, на основе которого можно разделять принадлежность сделок к тому или иному ордеру… По номеру заявки. В квике должно быть поле номер заявки и номер сделки их смотрите. В квике Вы видите только тейкерские сделки. Мейкерские в таблицу сделок не попадают. Ответить Bob Ross, ну тогда по номеру сделки объединяйте. Он будет у всех сделок один. Т.е. если тейкерский ордер исполнил икс заявок то будет икс сделок с одинаковым номером. Может поэтому в квике и не показывают номер заявки т.к. было бы икс сделок с одим номером сделки и одним номером заявки. в квике Вы видите так: сделка покупка 5 контрактов по 100 рублей. в на самом деле происходит так: (где-то в ордерлоге)заявка продать 5 контрактов по 100 рублей(номер заявки 1234567890) … другие заявки и сделки … (чуть позже) тейкерская заявка купить икс контрактов по 100(или дороже) рублей(номер заявки 9000000000) сделка покупка 5 контрактов по 100 рублей(номер заявки 9000000000)(номер сделки 5432109876) сделка продажа 5 контрактов по 100 рублей(номер заявки 1234567890)(номер сделки 5432109876) …(дальше тонкости в плане если исполнилась частично остаётся если нет снимается и т.п.) Ответить Какую-то ботву я конечно сказал про номер сделки. Тупанул. Номер сделки конечно будет у каждой отдельной сделки разный даже если это будут заявки от одного инн. Получается только по номеру заявки надо смотреть. Если в квике нет то скачайте с iss или ещё где нибудь там должны быть. +1 Дмитрий Овчинников, оказывается ни по номеру заявки ни по времени ни получится. Биржа убрала миллисекунды(из бесплатных данных в платных точность до наносекунд поэтому можно и по номеру заявки и по времени но за деньги(что правильно я считаю)) и номеров заявок тоже нет оказывается. « iss.moex.com/iss/engines/futures/markets/forts/boards/RFUD/trades.json »(либо .csv) TRADENO;BOARDNAME;SECID;TRADEDATE;TRADETIME;PRICE;QUANTITY;SYSTIME;RECNO;OPENPOSITION;OFFMARKETDEAL;BUYSELL;TRADE_SESSION_DATE 2012578029447938049;RFUD;NGX5;2025-11-13;19:05:00;4.591;1;2025-11-13 19:05:00;298447946512;719318;0;B;2025-11-14 2012578029447938050;RFUD;NGX5;2025-11-13;19:05:00;4.592;10;2025-11-13 19:05:00;298447946516;719338;0;B;2025-11-14 2012578029447938051;RFUD;NGX5;2025-11-13;19:05:00;4.592;1;2025-11-13 19:05:00;298447946520;719340;0;B;2025-11-14 Поэтому автору надо либо искать другой вариант либо за деньги. Бесплатно всё же есть вариант но раз биржа двигается в правильном направлении то я не буду говорить где и как(кто ищет тот всегда найдёт). __rtx, Биржа убрала миллисекунды Не знаю что там творится в Квике, но у меня в МТ5 миллисекунды как были, так и есть. Ответить Дмитрий Овчинников, я имел ввиду если данные качать с iss(т.к. предложил автору там искать решение с номерами). Получается из терминалов(по крайней мере MT5) тоже можно у Вас там кстати и номера ордеров есть(странно что в квике их нет). Если не брать Ваши сделки в МТ5 там тоже есть и миллисекунды и номера ордеров? Ответить … по времени исполнения… В целом да но нужно иметь данные у которых точность наносекунды т.к. если будут миллисекунды(как верно заметил Дмитрий Овчинников) будут расхождения. Если это не критично то ок но правильней по номерам заявки(если есть данные с наносекундной точностью то значит есть и номера заявок). Иначе с миллисекундной точностью будут проскакивать такие моменты это 2018 год SYMBOL,SYSTEM,TYPE,MOMENT,ID,ACTION,PRICE,VOLUME,ID_DEAL,PRICE_DEAL SRH9,F,B,20181228190000777,33948196146,1,21046.00000,2,, SRH9,F,B,20181228190000777,33948196146,2,21046.00000,1,2205001447,18940.00000 SRH9,F,S,20181228190000777,33948186708,2,18940.00000,1,2205001447,18940.00000 SRH9,F,B,20181228190000777,33948196146,2,21046.00000,1,2205001448,18943.00000 SRH9,F,S,20181228190000777,33948195658,2,18943.00000,1,2205001448,18943.00000 SRH9,F,B,20181228190000777,33948196147,1,21046.00000,1,, SRH9,F,B,20181228190000777,33948196147,2,21046.00000,1,2205001449,18947.00000 SRH9,F,S,20181228190000777,33948186500,2,18947.00000,1,2205001449,18947.00000 это 2024(кстати его можно проверить прямо сейчас если есть желание) —> « fs.moex.com/f/21687/orderlog20241001-a.zip »(начиная со строки 496600) SYMBOL,SYSTEM,TYPE,MOMENT,ID,ACTION,PRICE,VOLUME,ID_DEAL,PRICE_DEAL GZZ4,F,B,20240930191545517,1896046156434140619,1,14520.00000,1,, GZZ4,F,B,20240930191545517,1896046156434140619,2,14520.00000,1,1896046156434113494,14520.00000 GZZ4,F,S,20240930191545517,1896046156434140617,2,14520.00000,1,1896046156434113494,14520.00000 SRZ4,F,S,20240930191545517,1953467051683100903,0,28286.00000,7,, SRZ4,F,S,20240930191545517,1953467051683100984,1,28285.00000,7,, SRZ4,F,B,20240930191545517,1953467051683100844,0,28267.00000,7,, SRZ4,F,B,20240930191545517,1953467051683100985,1,28264.00000,7,, GZZ4,F,B,20240930191545517,1896046156434140620,1,14519.00000,7,, GZZ4,F,S,20240930191545517,1896046156434140609,0,14525.00000,2,, GZZ4,F,S,20240930191545517,1896046156434140621,1,14529.00000,2,, GZZ4,F,S,20240930191545517,1896046156434140605,0,14526.00000,2,, GZZ4,F,S,20240930191545517,1896046156434140622,1,14531.00000,2,, GZZ4,F,B,20240930191545517,1896046156434140607,0,14516.00000,5,, GZZ4,F,B,20240930191545517,1896046156434140623,1,14520.00000,5,, GZZ4,F,B,20240930191545517,1896046156434140516,0,14515.00000,5,, GZZ4,F,B,20240930191545517,1896046156434140624,1,14503.00000,5,, GZZ4,F,S,20240930191545517,1896046156434140615,0,14579.00000,5,, GZZ4,F,S,20240930191545517,1896046156434140625,1,14566.00000,5,, GZZ4,F,B,20240930191545517,1896046156434140626,1,14521.00000,22,, GZZ4,F,B,20240930191545517,1896046156434140626,2,14521.00000,22,1896046156434113495,14521.00000 GZZ4,F,S,20240930191545517,1896046156434140612,2,14521.00000,22,1896046156434113495,14521.00000 Для коллег которые не станут читать скажу что если агрегировать по времени исполнения и это время в миллисекундах то в «батч» будут попадать разные ордера/сделки(которые прилетели в одно время(при миллисекундной точности)) это ордера в ордерлоге по ссылке(2024 год)1896046156434140619 и 1896046156434140626 и ордера из ордерлога(2018 год) 33948196146 и 33948196147. Причём в 2018 цена сделки одна у разных ордеров а в 2024 разная. Если такие моменты не критичны то можно агрегировать по времени исполнения но я бы так не стал делать(просто из максималистических соображений/фетишей и т.п. заморочек). И ещё могу такой момент накинуть как раз подходит под кейс автора т.к. он хотел увидеть … съеденные ОДНИМ маркет-ордером, появляются в виде ОДНОЙ сделки (прямоугольника)… например такая ситуация — начался движняк и с сервера брокера(или квика или как там происходит это дело) полетели стоп-заявки. Они в миллисекундных масштабах прилетят в одно и тоже время(допустим например как на записях выше) и автор может их записать в «батч» как маркет ордер от «citadel»(к примеру) а это будут много мелких ордеров от брокера, викингов и т.д. Т.е. получится жёсткий косяк в плане корректности данных для анализа. пс. поэтому автору(на мой взгляд) стоит придерживаться варианта с номерами ордеров т.к. в противном случае есть момент охотиться на «статистические миражи». Для анализа «кто кого съел» это катастрофа т.к. будет провоцировать ставить ордера в сторону «умных денег» а по факту это вполне могут быть деньги «папкиных-бродяг-мамкиных-симпотяг»(нейросети и прочие «модели» за такое спасибо не скажут). Но опять же всё зависит от контекста как это применяется используется и т.д. и т.п. Для меня например это «костыль в данных» и я лучше вообще откажусь использовать то в чём не уверен на 100%(т.е. если бы я мутил такую тему то только по номерам). Source: https://smart-lab.ru/blog/1229727.php