Imported from previous forum
[ original email was from Jeffrey Croft - jeff.croft@plusmarketsgroup.com ]
If a client submits an OrderMassCancelRequest then the OrderMassCancelReport that is returned carries tag 531 which indicates the action taken. This tag does not appear to support any ‘pending’ states whereas the execution reports do. Is the OrderMassCancel request meant to be an all or nothing action? i.e. if some orders were able to be canceled immediately but some were pending cancel what should the fix engine return in the OrderMassCancelReport.
FIX 5.0 SP1 added the NotAffectedOrdersGrp block to the message. This allows you to list those orders that have not been deleted. A field to define the reason (e.g. NotAffectedReason)is still missing but is only relevant if you need to convey more than one reason. If all you need is pending cancel then your Rules of Engagement could simply define that all orders listed in that group are pending cancel and therefore not deleted yet. Individual ExecutionReports would then confirm the actual deletion, OrderCancelReject could confirm that they were ultimately not deleted.
Please also note that FIX recommends the use of the more generic OrderMassActionRequest/Report messages as of FIX 5.0 SP1. They currently allow you to cancel, suspend or release many orders with a single request.
If a client submits an OrderMassCancelRequest then the OrderMassCancelReport that is returned carries tag 531 which indicates the action taken. This tag does not appear to support any ‘pending’ states whereas the execution reports do. Is the OrderMassCancel request meant to be an all or nothing action? i.e. if some orders were able to be canceled immediately but some were pending cancel what should the fix engine return in the OrderMassCancelReport.
[ original email was from Jeffrey Croft - jeff.croft@plusmarketsgroup.com ]
Thanks Hanno
I think I was confused by the tense being used as it stated ‘action taken’ which is not correct as it has not taken that action but merely echoes back what you asked for.
FIX 5.0 SP1 added the NotAffectedOrdersGrp block to the message. This allows you to list those orders that have not been deleted. A field to define the reason (e.g. NotAffectedReason)is still missing but is only relevant if you need to convey more than one reason. If all you need is pending cancel then your Rules of Engagement could simply define that all orders listed in that group are pending cancel and therefore not deleted yet. Individual ExecutionReports would then confirm the actual deletion, OrderCancelReject could confirm that they were ultimately not deleted.
Please also note that FIX recommends the use of the more generic OrderMassActionRequest/Report messages as of FIX 5.0 SP1. They currently allow you to cancel, suspend or release many orders with a single request.If a client submits an OrderMassCancelRequest then the OrderMassCancelReport that is returned carries tag 531 which indicates the action taken. This tag does not appear to support any ‘pending’ states whereas the execution reports do. Is the OrderMassCancel request meant to be an all or nothing action? i.e. if some orders were able to be canceled immediately but some were pending cancel what should the fix engine return in the OrderMassCancelReport.