Conflicting Mutli-Bar Script Recommendations in Documentation

[Jaggy]

So I'm seeing two contradictory statements in the documentation, both from here (https://ninjatrader.com/support/help..._practices.htm). The first:

3. For advanced order methods, if you DO NOT specify a BarsInProgress , the order will be submitted to the current bars in progress updating. If the current BarsInProgress is a higher time frame, this could delay the time that the order is filled during historical backtesting. As a result, you should always submit historical orders to the most granular of time frames.

The second:

1. Should you have multiple Bars objects of the same instrument while using Set() methods in your strategy, you should only submit orders for this instrument to the first Bars context of that instrument. This is to ensure your order logic is processed correctly and any necessary order amendments are done properly.

The first suggests the only way to ensure realistic fills is to submit to the lowest timeframe. The second suggests that I may have issues with set stop loss and profit target if I submit to anything but the first bar series for the traded instrument.

In my case I believe this is causing orders to trade through stop losses in the first bar of the trade. Specifically I have a script which trades on the 15m, and loads the 1m because the order of events is important. I'm entering with limit orders, so knowing which happened first, entering or hitting the stop, is critical to the accuracy of results. In the past I've had some luck using Exit methods (ExitLongLimit etc.) additional accuracy, but that shouldn't be necessary here. Is this a known bug, what's the work around?

[NinjaTrader_Jesse]

Hello Jaggy,

Advanced order methods are not the same as the Set methods. Set methods are SetStopLoss, SetTrailStop, SetProfitTarget. Advanced order methods are methods like EnterLongLimit, ExitLongLimit.

When using Set methods if you have multiple timeframes of the same instrument for processing reasons you would need to submit those on the primary bars in progress, Set methods do not have a way to specify a BarsInProgress in their overload. Advanced methods do have a way to specify a bars in progress which the order would be submitted to.

[JGRtrader]

Jesse,

Thank you for this information. I have been puzzling over this issue too. My single instrument script has primary plus three other time frames and I run Calculate on each tick. One time frame is more granular than the Primary. Am I correct to understand that if I avoid the Set methods and submit orders with the "barsInProgressIndex" they will execute on that (more granular) time frame regardless of the Primary Time Frame?

[NinjaTrader_Jesse]

Hello JGRtrader,

If you are using OnEachTick in realtime it wouldn't matter to submit the orders to a more granular series, the primary is processing on each tick already. The only scenario where that would be needed while using OnEachTick in realtime is if you are limiting the processing for example doing the action only on the first tick of the bar. If your logic can happen for any tick then the orders can be summited at tick granularity.

For backtesting purposes yes that would help to submit the orders to the more granular series so the fills can be processed on that series.