Can i assume that an order is guaranteed to reach the either one of the following four status finally under all circumstances , irrespective of the intermediate states that they traverse: OPEN, COMPLETE, CANCELLED, and REJECTED
Please confirm that this is true under all circumstances like you have a OMS error,data-center failure etc.
No really. I have seen sometimes during issues... "NOT CANCELLED" , etc.
Sometimes, even "TRIGGER PENDING" and "OPEN" , when the pending stale legs of BO gets stucked and doesnt get cancelled by API as well as manually... I just hope, these issue is resolved. Else, all these will also have to be taken into account...
The above statuses can be seen in successful cases. In addition, stop-loss orders will sit in TRIGGER PENDING state. If something goes wrong then the order will sit in one of the statuses which is not in the above-mentioned statuses.
What happens when market closes at 3.30 pm ? Do you move all status to CANCELLED if they are still open and could not be closed. FYI, It is difficult to develop our system to know all your intermediate states (which your designers might add more in the future) , so we need a few set of definite macro states which it will eventually reach (like is it open, is it rejected,is it cancelled , is it closed) . Ability to look at the status at tell when the order has come to end of life-cycle at your end is important to consolidate my local order book and fund balances.
FYI, explaining here why i am asking just in case it helps appreciate the requirement : I am asking this is because i need to have my "consolidate" my "local order book" with your "order book" and be sure to capture these orders in my "portfolio" or nullify/purge orders that are failed , And also match my fund balances with yours . This i can do only if i know when the order came to life-cycle end at your end . This way i can develop my system to consolidate and cross-verify itself and request my manual intervention only in cases of rare exceptions.
@sudhirshettyk as I have experienced that is no guarantees here.. after 3:30 pm you cant get details of the order ids that 'didnt' go anywhere.. I guess it gets all purged I suppose.. no traces left behind... a simpler way to sync ur details is through trade book (open positions) rather than order book.. final positions is what you use to sync up your local data if wrong.. @sujith maybe you can throw some more light!
yes @razcads , using trades at the end of trading session is one good option i can consider , Thanks @sujith , however i will need to know if the order is open (i.e alive at zerodha end) or closed (end of the life cycle at zerodha ,and no further state change will occur. These being asynchronous system , i will have to design by product to maintain data-integrity and build ability to flag discrepencies , while considering that multiple failures can occur like i place an order , you generated an orderid but my network failed just while receiving the response with order id, oms down, exchange down etc. So i am planning the following algorithm of status check and check points of consolidation , please let me if this is true for your system -
if (status ==CANCELLED) then //order reached end of life at zerodha //check filled_qty for partial filled orders //match fund balances available for trading
else if (status == REJECTED ) then //order reached end of life at zerodha //filled_qty will always be zero //match fund balances available for trading
else if (status == COMPLETE) then //order reached end of life at zerodha //check filled_qty //match fund balances available for trading else 1) for all other cases , consider order is "alive" at zerodha and zerodha is "acting" on it.
2) wait for order to change to one of the state above (CANCELLED/REJECTED/COMPLETE) or wait for trading session to end and check against "trades" for these orders that didn't reach one of the above states by end of trading session and consolidate. (or may be consolidate only using holdings next day since trades may still not reflect the correct status if oms/exchange is not responding for zerodha)
3) can issue modify/cancel order anytime while in this stage if we have got order-id for the order request (that means order is registered with zerodha) .
4) anticipate that the order could be waiting on a failed oms, failed nse exchange etc , but order is still "alive" in zerodha .
Sometimes, even "TRIGGER PENDING" and "OPEN" , when the pending stale legs of BO gets stucked and doesnt get cancelled by API as well as manually... I just hope, these issue is resolved. Else, all these will also have to be taken into account...
Let the zerodha guys confirm.
Shaha , thanks for insight, is helpful.
If something goes wrong then the order will sit in one of the statuses which is not in the above-mentioned statuses.
For AMO orders statuses will be different.
FYI, It is difficult to develop our system to know all your intermediate states (which your designers might add more in the future) , so we need a few set of definite macro states which it will eventually reach (like is it open, is it rejected,is it cancelled , is it closed) . Ability to look at the status at tell when the order has come to end of life-cycle at your end is important to consolidate my local order book and fund balances.
FYI, explaining here why i am asking just in case it helps appreciate the requirement : I am asking this is because i need to have my "consolidate" my "local order book" with your "order book" and be sure to capture these orders in my "portfolio" or nullify/purge orders that are failed , And also match my fund balances with yours . This i can do only if i know when the order came to life-cycle end at your end . This way i can develop my system to consolidate and cross-verify itself and request my manual intervention only in cases of rare exceptions.
@sujith maybe you can throw some more light!
@sujith , however i will need to know if the order is open (i.e alive at zerodha end) or closed (end of the life cycle at zerodha ,and no further state change will occur. These being asynchronous system , i will have to design by product to maintain data-integrity and build ability to flag discrepencies , while considering that multiple failures can occur like i place an order , you generated an orderid but my network failed just while receiving the response with order id, oms down, exchange down etc.
So i am planning the following algorithm of status check and check points of consolidation , please let me if this is true for your system -
if (status ==CANCELLED) then
//order reached end of life at zerodha
//check filled_qty for partial filled orders
//match fund balances available for trading
else if (status == REJECTED ) then
//order reached end of life at zerodha
//filled_qty will always be zero
//match fund balances available for trading
else if (status == COMPLETE) then
//order reached end of life at zerodha
//check filled_qty
//match fund balances available for trading
else
1) for all other cases , consider order is "alive" at zerodha and zerodha is "acting" on it.
2) wait for order to change to one of the state above (CANCELLED/REJECTED/COMPLETE) or wait for trading session to end and check against "trades" for these orders that didn't reach one of the above states by end of trading session and consolidate. (or may be consolidate only using holdings next day since trades may still not reflect the correct status if oms/exchange is not responding for zerodha)
3) can issue modify/cancel order anytime while in this stage if we have got order-id for the order request (that means order is registered with zerodha) .
4) anticipate that the order could be waiting on a failed oms, failed nse exchange etc , but order is still "alive" in zerodha .
end if