OrderId is being changed by the Ninjatrader Broker

[Irauan]

Hello all,

I developed an strategy and for some reasons I need to know the OrderId in advance, and one of my reasons is to control if my trade has ended or not. When developing and runing in playback I hadn't this issue, but when using it in my production account I noted that the Id of the order is different of the Id in my trade, making it impossible for me to update the orders if I have to.

The code that I used to create the order was this one


and after that I do the submission with this code


The other utility for the orderId is to create the Stop Loss order and the Target Order, so I have one of this for each entry, so I'm using the order id of the entry as the oco id of the target and stop loss and in the next image you can see that the ids are different.



Entry - 1 -> ID: 8491912 | Targe -> OCO_ID: 56b8a81

How can I solve this issue? I can't use the methods available, because it may not return a order object.

[QuantKey_Bruce]

Have you read this? https://ninjatrader.com/support/help...storicaltolive
And this? https://ninjatrader.com/support/help...ltimeorder.htm

[bltdavid]

Or this? https://ninjatrader.com/support/help...html?order.htm

"The property <Order>.OrderId is NOT a unique value, since it can change throughout an order's lifetime."

[NinjaTrader_ChelseaB]

Hello Irauan,

Bruce and bltdavid are providing good insight.

The orderID generated by NinjaTrader is only used temporarily as a placeholder until the actual order id for the order as it gets created on the brokerage servers is returned.

I would suggest tracking the orders by the signalName instead.

[bltdavid]

Good reading here.

I think you'll find that the undocumented 'Id' field might give you what you want.

[bltdavid]

The links provided appear to be broken.

Hmm, I clicked all of them, and they work fine Firefox in Windows 7.

I simply pasted in the entire URL address into my posting.
That has has always worked before (but usually I embed
the links behind some keyword, using the Link button above)

Did Bruce and my links not work for you?

[NinjaTrader_ChelseaB]

Thanks bltdavid,

Looks like it was a browser issue on my end. I was able to resolve.

[Irauan]

thank you everyone, I changed my logic to use the order id that is creted by e and never changes. I had a map with my orders where I used the order id as the key to find the order and after that update it with the order update event. since the order id is changed by the broker it was lossing the reference of the first Id.

Since the order id is a value returned by the broker I would sugest the removal of the Set property and the creation of the ID only after the submit method, so that the behavior stays as close as possible of what would be in prod.

[jeronymite]

Irauan It's relatively easy to work with the current behaviour, once you understand what is happening.

Based on extensive usage, I have found that the change of OrderId happens once only, at the time of the first response from the broker for a submitted Order. At that time, the NinjaTrader-internally-generated OrderId (e.g. 1bd2fd3d9a3947f19fce3f773e63b867) is replaced by a broker-generated OrderId (e.g. 141356999). This is easily detected in OnOrderUpdate as a change of only OrderId for an Order with the OrderState remaining unchanged.

The only additional thing needed to ensure correct identification of the change for a particular Order is a unique identifier for the Order that is not the OrderId. Typically, this is easily achieved using an Order naming convention that uses unique elements per Order.

The thread highlighted by bltdavid above has more details.

Thanks.

[QuantKey_Bruce]

Irauan It's relatively easy to work with the current behaviour, once you understand what is happening.

Based on extensive usage, I have found that the change of OrderId happens once only, at the time of the first response from the broker for a submitted Order. At that time, the NinjaTrader-internally-generated OrderId (e.g. 1bd2fd3d9a3947f19fce3f773e63b867) is replaced by a broker-generated OrderId (e.g. 141356999). This is easily detected in OnOrderUpdate as a change of only OrderId for an Order with the OrderState remaining unchanged.

The only additional thing needed to ensure correct identification of the change for a particular Order is a unique identifier for the Order that is not the OrderId. Typically, this is easily achieved using an Order naming convention that uses unique elements per Order.

The thread highlighted by bltdavid above has more details.

Thanks.

Good information here. This is what you should pay attention to.

[Irauan]

Irauan It's relatively easy to work with the current behaviour, once you understand what is happening.

Based on extensive usage, I have found that the change of OrderId happens once only, at the time of the first response from the broker for a submitted Order. At that time, the NinjaTrader-internally-generated OrderId (e.g. 1bd2fd3d9a3947f19fce3f773e63b867) is replaced by a broker-generated OrderId (e.g. 141356999). This is easily detected in OnOrderUpdate as a change of only OrderId for an Order with the OrderState remaining unchanged.

The only additional thing needed to ensure correct identification of the change for a particular Order is a unique identifier for the Order that is not the OrderId. Typically, this is easily achieved using an Order naming convention that uses unique elements per Order.

The thread highlighted by bltdavid above has more details.

Thanks.

I'm not saying its difficult to work, just that is error prone... and as I said, it's a suggestion so that they can better their software.

[jeronymite]

Irauan It can be error prone, but it really is only as error prone as one's own code. The actual events are reliably repeatable. I say this with several tens of thousands (literally) of Orders being explicitly tracked at every OnOrderUpdate in my own software. If you follow the method I've elaborated, it should work reliably for you.

Thanks.

[Irauan]

Irauan It can be error prone, but it really is only as error prone as one's own code. The actual events are reliably repeatable. I say this with several tens of thousands (literally) of Orders being explicitly tracked at every OnOrderUpdate in my own software. If you follow the method I've elaborated, it should work reliably for you.

Thanks.

I'm not questioning the proccess of update of the order, I'm okay with it. I'm question the fact tha there is fields that I can update, and as expected of any software, if I update a field and it is persisted, I expected that my value is persisted to whatever place it is saved and not replaced by someone.

So if the value is for the broker or whatever to fill, I think that would be better to let it be only readable and change the place where it is created.

Instead of creating a placeholder value on the Account.CreateOrder, change it to when the order is submited, this last, only for development pourpose (since this is the default behavior for real account) so that my playback environment has the same behaviour as when I'm using a real account

Again, not saying there is any thing wronk, just trying to help to better the software that is alredy pretty good.