overfill cfd

[tonynt]

Hello,

I have overfill-message in my live-account and I do not understand how this can occur as there are not different conditions or trigger true the same moment.

Entry:
entryOrdermSa=EnterShort(30, "mSa");
entryOrdermSb=EnterShort(30, "mSb");
entryOrdermSc=EnterShort(30, "mSc");

Stops:
if (Position.MarketPosition == MarketPosition.Flat)
SetStopLoss("mSa", CalculationMode.Ticks, 10, false);
SetStopLoss("mSb", CalculationMode.Ticks, 10, false);
SetStopLoss("mSc", CalculationMode.Ticks, 10, false);

else if (Position.MarketPosition == MarketPosition.Short)
{ if (GetCurrentBid() <= Position.AvgPrice - (10*TickSize))
{
SetStopLoss("mSa", CalculationMode.Price, Position.AvgPrice+2*TickSize, false);
SetStopLoss("mSb", CalculationMode.Price, Position.AvgPrice+2*TickSize, false);
SetStopLoss("mSc", CalculationMode.Price, Position.AvgPrice+2*TickSize, false);
}

Why should there be an overfill?

Thank you
Tony

[NinjaTrader_ChelseaB]

Hello tonynt,

From the help guide:
An overfill is categorized as when an order returns a "Filled" or "PartFilled" state after the order was already marked for cancellation. The cancel request could have been induced by an explicit CancelOrder() call, from more implicit cancellations like those that occur when another order sharing the same OCO ID is filled, or from things like order expirations.
http://www.ninjatrader.com/support/h...reoverfill.htm

So this means that calling CancelOrder() can cause an overfill. Using multiple exits on a single entry can cause an overfill. Calling an exit order on the same bar as an entry order can cause overfills. Are you doing any of these things with this script?

The code you have does not appear likely to have caused this error. Can you add this code to an export so that we can ensure we are testing the same code?

To export your script do the following:

1. Click File -> Utilities -> Export NinjaScript
2. Enter a unique name for the file in the value for 'File name:'
3. Select the strategy from the objects list on the left -> click the right facing arrow ">" to add the strategy to the export
4. Click the 'Export' button -> click 'yes' to add any referenced indicators to the export -> click OK to clear the export location message

By default your exported file will be in the following location:

• (My) Documents/NinjaTrader 7/bin/Custom/ExportNinjaScript/<export_file_name.zip>

Below is a link to the help guide on Exporting NinjaScripts.
http://www.ninjatrader.com/support/h...nt7/export.htm

[LTWCI]

Hi Chelsea

Am I correct in thinking that a strategy set to "perEntries" in the new strategy box can cause an overfill if the strategy submits an order simultaneously from two entry conditions? I have my strategies set to "uniqueEntries."

[NinjaTrader_ChelseaB]

Hello,

Entries per direction has nothing to do with causing overfills.

Entries per direction controls how many entry orders can be placed in a direction.

With AllEntries this ignores the signal name and allows however many orders set in the Entries per direction for all orders.

With UniqueEntries this will allow however many orders are set in the Entries per direction but for each signal name.

So if you use different signal names this allows for one of these orders.


Overfills are caused when an order that has been filled or part filled is attempted to be cancelled (or modified). This is not really related to Entries per direction in anyway that I can think of.

[NinjaTrader_ChelseaB]

Hello LTWCI

No, the entries per direction will not cause an overfill if you place more orders than are set in this field. No errors will be generated, the order will just be ignored.

[LTWCI]

I'm referring to "entry handling" and I have two entry conditions in the strategy per direction. Lets say entries per direction is 1.

[NinjaTrader_ChelseaB]

Hello LTWCI,

I am also talking about entry handling. See post #4 and post #5.

[darrentate]

Chelsea -

Just want to reopen this briefly. I execute a cancelorder when price has hit my target but not been filled (I wait a bar as well to give it time). I still appear to get overfills when after executing the cancelorder the existing target is then hit. I also only execute the cancelorder if the orderstate is Filled or Part Filled to avoid attempting to cancel if there is a pending state when the target is then hit. Without using an unmanaged system what is the recommended way to avoid an overfill in this instance - i.e. what should I be checking for to avoid the overfill / executions occurring at the same moment?

Thanks,

Darren

[NinjaTrader_ChelseaB]

Hello Darren,

I'm not exactly sure what you mean.

If you are using SetProfitTarget for your target, that is submitted immediately when the entry order fills. The same is true when using SetStopLoss.

Trying to cancel a part filled order will typically always result in an overfill, so that is expected.

I think you are attempting to use multiple exits for a single entry and cancel one if the other fills, is this correct?
If this is what you are doing I would suggest against it. Instead of using multiple exits for a single entry, just use logic to control the price of a single exit.
OR if you must use two different order types, cancel the working order and detect it is cancelled, before submitting the replacement exit order.
In otherwords don't allow multiple exits to be working at the same time.

If you are planning to exit part filled orders, assume that this is not going to go well. Set the error handling to take no action so the script is not disabled, detect the overfill and then manage the position according to what was filled and what was not filled.

[darrentate]

Hi Chelsea,

To clarify I am using SetProfitTarget and only attempt to cancel the the order if it has a status "filled" (with just one order type only).

What happens on some occasions is that price get to the target but that profittarget is then not filled. At that point of time I do not want to wait for price to retreat in hope that it then goes back up and tries for the target again. Instead I want to take profit; so they system recognises that the target was reached but the profit target did not fill at that price and therefore tries to cancel the trade (otherwise it relies on the traditional exit method of filling the target(s)).

Are you saying by using logic that I don't use setprofittarget and just cancel the trade if the price is reached? The reason I haven't done this is because then the broker won't have the profit target / stop loss orders on their system so if the server crashes and my strategy stops I won't be left with an open trade.

I have already set reatimeerror handling to take no action; however I can't see a way to detect an overfill and stop the strategy from crashing out? I didn't think that was possible but if it is that would be great.

Thanks.

[NinjaTrader_ChelseaB]

Hi Darren,

No what I mean is that you have one working order. When your logic would dictate that you exit before the working order would naturally be filled, cancel this order, wait for the cancellation to be returned, then submit a market order to exit. (If your logic would simply place the same type of order, you can just modify the price of the existing order instead.)

All states of an order including rejected, cancelled, overfill, part fill, and filled are OrderStates, are part of the IOrder, and trigger OnOrderUpdate().
IOrder - http://www.ninjatrader.com/support/h...nt7/iorder.htm
OnOrderUpdate - http://www.ninjatrader.com/support/h...rderupdate.htm

Also for ignoring the part filled and keeping this from disabling the strategy, I needed to have mentioned IgnoreOverfill and not RealtimeErrorHandling. This actually has to be done in an unmanaged script.
http://www.ninjatrader.com/support/h...reoverfill.htm

[darrentate]

Hi Chelsea -

Of course. I could just exitlong / short couldn't I? That wouldn't then cause a conflict?

Other than that move up the stop behind price I suppose..

Darren

[NinjaTrader_ChelseaB]

Hello Darren,

There could be a few ways to work with this but the important thing is that two orders do not become working to close the same trade at the same time.

Trying to cancel a part filled order is almost always going to cause an overfill. If the order is part filled, its best to just let it fill. If the volume is super low and it isn't going to fill, then this would be an appropriate time to try and cancel the overfill.

But the best idea is to use one exit order and just use logic to control its position and when it closes. (or cancel it and wait for the cancellation before submitting a replacement)

[darrentate]

Got you. If the order status is filled you can issue a cancel order, then wait for the broker to confirm the cancellation with a cancel confirm in OnExecution then if required run the exit. Otherwise just run the exit.

[MicroTrends]

You might find this useful

Anything not written in unmnaged mode in NT7 is going to be a gamble in live trading -
so here is a free algorithmic trading framework which extends NinjaTrader Strategy functionality allowing realtime interaction with a chart trader style ui - it does not suffer from overfills was written many years ago and tested by 1000s of traders + comes with an SDK so you can program your own strategies in a few lines of codes and leverage all the free off the shelf features... simply edit an existing sample and save with your own code and compile... - currently being migrated to NT8

video

http://www.youtube.com/playlist?list=PLtKS2GMs9w4U5sfvbaHt8Flv99oVLBMRP

Downloads

http://www.micro-trends.co.uk/ninjatrader-downloads/

http://downloads.microtrends.co/MTDoubleShotStrategyFoundation/MTDoubleShotStrategyFoundation-Setup.exe

more details
Details:....

MicroTrends Double Shot Strategy Foundation - 100% free for Sim, testing and Development
Umanaged mode NinjaTrader Strategy API - Provides Developers with licensed access to the MTDS Strategy base classes - allowing auto trading systems to be created in just a few lines of code automatically implementing signal execution, signal filtering, custom entry rules, custom exit rules, custom breakeven stop rules, custom trailing stop rules, 1 to 2 bracket control using unmanaged mode tick by tick or on bar close real-time trading, allowing back testing and optimization.