[This message was posted by John Prewett of Lava Trading <[EMAIL PROTECTED]> to the "General Q/A" discussion forum at http://fixprotocol.org/discuss/22. You can reply to it on-line at http://fixprotocol.org/discuss/read/d20bda07 - PLEASE DO NOT REPLY BY MAIL.]
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 [You can unsubscribe from this discussion group by sending a message to mailto:[EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/FIX-Protocol?hl=en -~----------~----~----~----~------~----~------~--~---
