An exit order placed. . . has been ignored

[whitmark]

I am using a basic EnterLongStopLimit order tagged with a SignalName that is also used to SetProfitTarget() and SetStopLoss() within the Initialize method. Once a position is established, I execute an early exit under certain conditions by submitting a ExitLongLimit command. However, I receive the following message:

2007-11-17 14:41:30:843 ERROR: An exit order placed at '6/11/2007 3:15:00 PM' has been ignored since there already is a pending 'Stop loss' in place. Please fix your strategy.

The "pending Stop Loss" condition is unexpected and I don't recall seeing it in 6.0. In this context, is there a way to execute an early exit stop limit when a stop market order is in play and without necessarily using the new advanced order handling? Using the simple order entry functions I don't see how I might be able to cancel the stop market before submitting the stop limit. Thanks.

Regards,

Whitmark

[NinjaTrader_Ray]

Correct, we have made things more strict with 6.5. Please check out the 6.5 Help Guide section NinjaScript > NinjaScript Language Reference > Custom Strategy Methods and Properties > Order Methods > Overview.

Check out the bottom section "
Interal Order Handling Rules that Reduce Unwanted Positions"

[whitmark]

I see, which leads me to a few questions . . .

1) If in a Long position in the as outlined in the previous example, can I assume using a IOrder signature for the ExitShortStop stop loss order vs the SetStopLoss will get around this check?

2) Can I be assured that if I place an early exit ExitShortLimit IOrder, in addition to the working stop loss and profit target IOrders, that if one of these three orders gets filled, the other two will OCO cancel if each is tagged with the same entry signal name?

3) Is there any built-in functionality to perform a "Close Position" on a NinjaScript order that works the same way as the close action button on the DOM or closing an ATM strategy to modify existing orders or must this be done programmatically?

Thanks,

Whitmark

[NinjaTrader_Ray]

1) Not sure if that will work or if it would be ignored. If you are long and you want to get out early, submit exit orders via ExitLongLimit() and ExitLongStop(), do this within the OnOrderUpdate() triggered by fill of entry order, that way you get orders to the market immediately and not on the close of a bar (see reference sample in forum for this) then modify limit price below market when you want to exit early. You could also cancel both stop and limit orders, wait for cancel confirmation in the OnOrderUpdate() and then submit market order to exit if none of the other two exit orders were filled or partially filled.

2) If it does work then once a position is flat, the other orders would immediately be cancelled.

3) No

[henry.omd]

I am kind of confused. In a previous thread (not this one), it seemed that NT 6.5 NinjaScript will offer a way to cancel orders entered from NS (e.g. EnterLongLimit() etc). But your discussion in thread makes me doubt, because I was expecting something like CancelOrder(orderId) method.

So... How do you cancel an order in NS before the end of the day is up? And will this work with historical data--you know, for strategy backtesting and optimization?

[NinjaTrader_Josh]

There is a CancelOrder() method available henry.omd.

Please check it out in your help guide for NT6.5.
NinjaScript > NinjaScript Language Reference > Custom Strategy Methods and Properties > Order Methods > CancelOrder()

[henry.omd]

Thanks Josh!
Since there is no ModifyOrder (is there?) I assume that I have to CancelOrder() and then place a new order?

[NinjaTrader_Josh]

That is one way of doing it. If you are using EnterLongLimit() or the likes I believe you can simply resubmit it at a different price and that will modify the order for you. Remember if you are using NS orders and you do not resubmit at the beginning of a new bar the order will be cancelled automatically (except for when you use the new liveUntilCancelled). If a resubmission is sent the order will be kept alive.

[henry.omd]

Interesting... Are you saying that if I use liveUntilCancelled = true, and call EnterLongLimit twice (let's say one yesterady and one today), NT will simply modify the existing order instead of creating a new order? I was thinking I would have to cancel the yesterday's order first before I can submit a new order with a new price...

What if I placed a buy order yesterday (with liveUntilCanceled) but want to do a sell short order today? Do I have to cancel the order then with CancelOrder().

[henry.omd]

Can I request a feature?
I was using IOrder structure, and it occurs to me that having the original placement (when I called EnterLong for example) would be helpful. Right now, I have to parse out the DateTime structure and compare against Time[0] to calculate the number of bars passed, but the answer changes depending on the bar size I use. It would be VERY convenient if NT exposed the BarsSinceOrder in the IOrder structure.

Does this make sense or am I missing something?

[NinjaTrader_Josh]

Okay. Please take a look at this reference sample. Pay attention to the code commentary in the OnBarUpdate() method. http://www.ninjatrader-support.com/vb/showthread.php?t=3917

Also have you tried BarsSinceEntry() for your suggestion?
http://www.ninjatrader-support.com/HelpGuideV6/BarsSinceEntry.html
http://www.ninjatrader-support.com/HelpGuideV6/BarsSinceExit.html

[henry.omd]

Thanks Josh, I will experiment a bit more about the necessity of cancelling the order explicitly since you seem to be saying that the example will answer my question about the necessity of cancelling the pending order even when reversing the side.

As for BarsSinceEntry(), I don't think it will help until you get IN the position, which is not the case if you want to modify a limit order that has not yet been filled. Am I wrong?

Thirdly, I am noticing a funny behavior in OnOrderUpdate(): I put in the following code in my OnOrderUpdate():

Print(ToDay(Time[0]) + ": " + order);//debug

and it seems that the Time[0] doesn't work correctly in backtest case. Checkout the output, where it is clear that in some cases, the date reported is today, rather than the historical date:

20071229: Order='NT-00000/Back101' Name='Sell short' State=PendingSubmit Instrument='$EURUSD' Action=SellShort Limit price=1.3878 Stop price=0 Quantity=1 Strategy='RSITRAD' Type=Limit Tif=Gtc Oco='' Filled=0 Fill price=0 Token='9aa163bb538f44f986c4ca4f8771ea70' Gtd='12/1/2099 12:00:00 AM'
20071229: Order='NT-00000/Back101' Name='Sell short' State=Accepted Instrument='$EURUSD' Action=SellShort Limit price=1.3878 Stop price=0 Quantity=1 Strategy='RSITRAD' Type=Limit Tif=Gtc Oco='' Filled=0 Fill price=0 Token='9aa163bb538f44f986c4ca4f8771ea70' Gtd='12/1/2099 12:00:00 AM'
20071229: Order='NT-00000/Back101' Name='Sell short' State=Working Instrument='$EURUSD' Action=SellShort Limit price=1.3878 Stop price=0 Quantity=1 Strategy='RSITRAD' Type=Limit Tif=Gtc Oco='' Filled=0 Fill price=0 Token='9aa163bb538f44f986c4ca4f8771ea70' Gtd='12/1/2099 12:00:00 AM'
20070917: Order='NT-00000/Back101' Name='Sell short' State=Filled Instrument='$EURUSD' Action=SellShort Limit price=1.3878 Stop price=0 Quantity=1 Strategy='RSITRAD' Type=Limit Tif=Gtc Oco='' Filled=1 Fill price=1.3878 Token='9aa163bb538f44f986c4ca4f8771ea70' Gtd='12/1/2099 12:00:00 AM'
20071229: Order='NT-00003/Back101' Name='Sell short' State=PendingSubmit Instrument='$EURUSD' Action=SellShort Limit price=1.41183821372071 Stop price=0 Quantity=1 Strategy='RSITRAD' Type=Limit Tif=Gtc Oco='' Filled=0 Fill price=0 Token='1335ef3a7a2c45a7bd72a2c4ed0afb83' Gtd='12/1/2099 12:00:00 AM'
20071229: Order='NT-00003/Back101' Name='Sell short' State=Accepted Instrument='$EURUSD' Action=SellShort Limit price=1.41183821372071 Stop price=0 Quantity=1 Strategy='RSITRAD' Type=Limit Tif=Gtc Oco='' Filled=0 Fill price=0 Token='1335ef3a7a2c45a7bd72a2c4ed0afb83' Gtd='12/1/2099 12:00:00 AM'
20071229: Order='NT-00003/Back101' Name='Sell short' State=Working Instrument='$EURUSD' Action=SellShort Limit price=1.41183821372071 Stop price=0 Quantity=1 Strategy='RSITRAD' Type=Limit Tif=Gtc Oco='' Filled=0 Fill price=0 Token='1335ef3a7a2c45a7bd72a2c4ed0afb83' Gtd='12/1/2099 12:00:00 AM'
20070925: Order='NT-00003/Back101' Name='Sell short' State=Filled Instrument='$EURUSD' Action=SellShort Limit price=1.41183821372071 Stop price=0 Quantity=1 Strategy='RSITRAD' Type=Limit Tif=Gtc Oco='' Filled=1 Fill price=1.41183821372071 Token='1335ef3a7a2c45a7bd72a2c4ed0afb83' Gtd='12/1/2099 12:00:00 AM'

[NinjaTrader_Josh]

When you are in the OnOrderUpdate() method you are not guaranteed to be in sync with the bars series object. Time[0] is synced with the bars series so is not effective in the OnOrderUpdate() method. You want to use the .Time property. So maybe something like order.Time

[henry.omd]

Thanks Josh, I find that the current OnOrderUpdate() lacking in 2 respects:

1. Regardless of whether OnOrderUpdate() is in sync with the bars series object, at the time OnOrderUpdate() is called, you are nevertheless in some kind of bar or tick, right? All I am asking is that the reported time is wrong with regard to the latest bar. My assertion is that even if I had run the backtest against 1990 data (if one were available), the Time[0] in OnOrderUpdate() would report today 2007--in some cases--you can see from the printout that you get the timestamp right in some cases. This appears like a bug, wouldn't you agree?

2. The order.Time is the latest time the order was modified. I need the time when the order was placed. So I once again ask you: does NT really not cancel an order when a new order is placed, and if so does the original order placement time change?

-Henry

[NinjaTrader_Ray]

1) I can't comment on this but will have development take a look at expected behaviour.

2) The question can be answered differently depending on the context. What I can says is that NT has one order object that it manages for a unique order ID. If an order is changed, we still maintain the same orderId, what the broker gateway does is likely a cancel/replace but this is transparent to NinjaTrader. If you need the time the order is placed you can best take the time property of the IOrder object you get back when placing the order and hold that in a local variable.

[NinjaTrader_Dierk]

1. Regardless of whether OnOrderUpdate() is in sync with the bars series object, at the time OnOrderUpdate() is called, you are nevertheless in some kind of bar or tick, right? All I am asking is that the reported time is wrong with regard to the latest bar. My assertion is that even if I had run the backtest against 1990 data (if one were available), the Time[0] in OnOrderUpdate() would report today 2007--in some cases--you can see from the printout that you get the timestamp right in some cases. This appears like a bug, wouldn't you agree?

Incorrect. Time[0] follows exact same logic as e.g. Close[0], meaning you would get the timestamp (or close value) of the bar being processing which is (a) backtest: the historical bar being processed and (b) live: the "rightmost" bar.

[henry.omd]

Thanks Dierk, let me see if I understand you correctly:
In backtest then, if I were testing with data from 2006/1/1 to 2006/12/31, I should never expect to see 2007/12/31 for Time[0] in OnOrderUpdate().

Did I understand you correctly?

[NinjaTrader_Ray]

Dierk is off for rest of the day but from my understanding, that is correct.

[henry.omd]

Thanks Ray, with the following output, I now fully understand what Dierk meant:

5/24/2006 12:00:00 AM Entered internal PlaceOrder() method at 5/24/2006 12:00:00 AM: Action=Buy OrderType=Limit Quantity=1 LimitPrice=1.2717 StopPrice=0 SignalName='' FromEntrySignal=''
20070101: Order='NT-00000/Back101' Name='Buy' State=PendingSubmit Instrument='$EURUSD' Action=Buy Limit price=1.2717 Stop price=0 Quantity=1 Strategy='RSITRAD' Type=Limit Tif=Gtc Oco='' Filled=0 Fill price=0 Token='e3278a1193b94d8fac2d8077efedb889' Gtd='12/1/2099 12:00:00 AM'
20070101: Order='NT-00000/Back101' Name='Buy' State=Accepted Instrument='$EURUSD'

My guess as to what is going on is that in historical backtest, the Time[0] in OnOrderUpdate() is still the right most bar. In this test, the data set is 2006. So I guess it thinks the "rightmost" data set is 2007/1/1, as you see in the output.

I at least understand that this is consistent with the live case, and maybe can even imagine that this is preferred by the developers. On the other hand, I found this confusing, because I expected--perhaps mistakenly--that Time[0] in OnOrderUpdate() would reflect the simulated order fill time in NT. I am guilty of expecting NT simulation to feel as close to the real thing as possible.

At any rate, now I understand, and will move on. Thanks for your help.
-Henry

[NinjaTrader_Dierk]

This is a bug where basically Open[0], Close[0]...Time[0] does not work as expected in the new OnOrderStatus/OnExecution etc. methods. This bug will be fixed with next 6.5 update. Thanks for reporting.