Over Filled

[GAVETSO]

Dear fellows.
I have a strategy that works almost all the time. but sometimes "crashed" with a message: "An over fill was detected on order..." when it happens the secuence is this:
1. limit order (filled)
2. Profit - ExitLongLimit(...) ( filled)
3. Close limit order ( filled) .... OVER FILL
So, the number 3, reveals "a change in the signal", it means, the second way to close the operation (the first is the profit), and tries to exit using:
-ExitLong("Change" , "long limit");. *This is the error part. anybody can help me? thanks.
This is part of the code:

private IOrder entryOrder = null;
private IOrder stopOrderLong = null;
private IOrder targetOrderLong = null;
private IOrder mar****rder = null;


protected override void OnBarUpdate()
{
if (Position.MarketPosition == MarketPosition.Flat)
{
if (entryOrder == null && mar****rder == null && F_ppl[0] == 1 && F_ppl[1] == 0 ) entryOrder = EnterLongLimit (0, true, 1, Close[0] - TickSize, "long limit" ) ;
}

if ( Ef_o[0] == 1 && Ef_o[1] == 0 )
{
if (Position.MarketPosition == MarketPosition.Long)
{
CancelOrder(stopOrderLong);
CancelOrder(targetOrderLong);
mar****rder = ExitLong("Change" , "long limit");
if (mar****rder != null )
{
stopOrderLong = null;
targetOrderLong = null;
mar****rder = null;
}
}
}
//////////////////////////////
protectedoverridevoid OnOrderUpdate(IOrder order)
{
if (entryOrder != null && entryOrder.Token == order.Token)
{
if (order.OrderState == OrderState.Cancelled)
entryOrder = null;
}
}
////////////////////////////////
protectedoverridevoid OnExecution(IExecution execution)
{
if (entryOrder != null && entryOrder.Token == execution.Order.Token)
{

if (execution.Order.OrderState == OrderState.Filled || execution.Order.OrderState == OrderState.PartFilled || (execution.Order.OrderState == OrderState.Cancelled && execution.Order.Filled > 0))
{

stopOrderLong = ExitLongStop(0, true, 1, execution.Price - Stop * TickSize , "Stop Long" , "long limit");

targetOrderLong = ExitLongLimit(0, true, 1, execution.Price + Profit * TickSize , "Target Long", "long limit");



if (execution.Order.OrderState != OrderState.PartFilled)
entryOrder = null;

}
}
}

[NinjaTrader_Joydeep]

Hello GAVETSO,
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.

From your code I can see you are trying to cancel the orders. Could it be the case that the codes are conflicting with each other.

[MicroTrends]

Maybe you could work in NinjaTrader unmanaged order mode - and save time and increase your control of the system you are using - you can in this mode elect to turn off overfill handling and make code that handles it. You sound as if you could handle that ok to me.

Or consider add a generic reusable signal execution order workflow which can be event driven and jogged/monitored by a timer on the same thread as the strategy main with a windows forms timer. So then you can perform a workflow that checks there are no order overlaps and waits for working orders to be cancelled or partfilled/ teminated - then adjusts position size to flatten where neccessary - until yuou are flat and ready to go again:

ie cancel orders, wait for confirmation, flatten ,then reverse etc

Long 1, stop and targets working

cancel all orders
wait n (3) seconds - or until an event tells you are confimed as all terminated - clear to move to next step

(any overfills will stop you here with the managed mode you are using)

flatten positions if any

wait n(seconds) or use the execute event/position update to check you are flat

enter next trade

on enter fill - place stops/targets


NOTE: For backtesting you would only use the event driven workflow - also for Replay you would not wait for validtion as this does not follow the same event chain - so consider it executed...

So you would have 3 variations backtest, replay and realtime scenarios to code for.

So in affect start again: engineer something to fit what goes on and then code it etc