Imported from previous forum
As of FIX.4.3 on of fields from the OrderQty component block (either OrderQty or CashOrderQty)is now required. Prior to FIX.4.2 the OrderQty is not required. A previous post: http://fixprotocol.org/discuss/read/c10aec99 indicates that the OrderQty should be validated but the cancel remainder action should be performed anyway.
We made the change for a reason, I just can’t remember why. It seems like OrderQty should not be required since the behavior of OrderCancelRequest(35=F) is to cancel any remaining unfilled quantity. OrderCancelRequest cannot be used for partial cancellations.
[ original email was from John Prewett - jprewett@lavatrading.com ]
Hi Jim,
The only field you should really need to clearly identify an order to be canceled on a CancelRequest is OrigClOrdID. FIX.4.2 already mandated Symbol, Side and (either OrderQty or CashOrderQty) were required to allow for an extra level of order identity validation as people sometimes make mistakes.
So when the OrderQty & CashOrderQty were moved into the OrderQtyData block in FIX.4.3, it made very good sense to make the OrderQtyData block mandatory as it makes it much more explicit that either OrderQty or CashOrderQty are required.
I therefore declare that, in this respect, there was no appreciable change in required fields between FIX.4.2 and FIX.4.3. The requirement of either OrderQty or CashOrderQty was just better documented with FIX.4.3.
As to whether you choose to CancelReject the CancelRequest if OrderQty doesn’t match the original order, I’ll leave that up to someone else to decide. In a liberal environment, your application should at least alert support staff to the discrepancy and continue to cancel the order. In a strict “by-the-book” environment you should probably issue a CancelReject.
See you in 20 days 
Regards,
JohnP
I agree that OrderQty should be optional for cancellations but that deviations of expected values should be made visible if this feature is used. There is a mandatory field CxlQty (84) in the ListStatus message today. However, the ExecutionReport does not carry this information explicitly and I wonder whether CxlQty might be a good field in this message, conditionally required for cancellations. LeavesQty can be set to zero and thus might not carry this information. A discrepancy can then be resolved by only flagging an error if outstanding Execution Reports (for the additional fills crossing the cancel request on the wire) do not arrive within a certain time frame. Only then a manual intervention is needed.
Regards,
Hanno.
As of FIX.4.3 on of fields from the OrderQty component block (either
OrderQty or CashOrderQty)is now required. Prior to FIX.4.2 the OrderQty
is not required. A previous post:
http://fixprotocol.org/discuss/read/c10aec99 indicates that the
OrderQty should be validated but the cancel remainder action should be
performed anyway.We made the change for a reason, I just can’t remember why. It seems
like OrderQty should not be required since the behavior of
OrderCancelRequest(35=F) is to cancel any remaining unfilled quantity.
OrderCancelRequest cannot be used for partial cancellations.